Hi Joel, Thanks for forwarding the below - it helps me in understanding the process. I am not sure whether I am supposed to respond or not on the comments you provided, but it cannot hurt - so I will do my best. If I need to provide those comments to a larger forum, or in a different forum - please advise. On the 1st comments, regarding IETF consensus, this may be something that others (e.g. Dan Romascanu maybe) can help with - I am not sure I am familiar enough with the IETF processes to suggest any changes. As per the 2nd comment - indeed there are no additional security concerns with respect to the use of the Diameter protocol for the PEEM specification. What may help understanding why this is the case, is the overall approach in OMA specifications. OMA develops granular specifications, not end-to-end service specifications or solution specifications. However, there are separate security specifications that any vendor can bundle with any other enabler specifications, in order to ensure any security concerns are addressed when a product is built. One such mechanism is the use of security policies applied in a proxy pattern (i.e. BEFORE any request reaches its target). Such security poclieis (e.g. for authentication or authorization) may be applied on the call carrying the PEM-1 request. A second mechanism is to use specifications produced by another OMA group (OMA SECurity Working Group) which produced a set of sepcifications called SECurity Common Functions, that are used at different protocol layers to ensure authentication, confidentiality, integrity of the exchange. OMA does this on purpose to avoid the development of silo-specifications (i.e. specifications where each functionality also addresses in a silo-approach all security aspects). The reason why we have honored the Diameter base protocol security requirements is simply because we want to take advantage of client-server implementations that vendors have produced so far, to simlify adoption of the PEEM application. Any other security needs would therefore be addressed in addition to, and outside the scope of the Diameter application. They have therefore nothing to do with the submitted IETF draft, and are not to be part of it. I'll be glad to provide any additional clarifications, or point to additional security specifications - although none of the latter will give any indication of how one would integrate additional security with PEEM specifications - that is on purpose left to vendors and service providers, to allow for differentiation (again - OMA is NOT in the business to provide specifications of end-to-end services or solutions). Best regards, Michael -----Original Message----- From: Joel M. Halpern [mailto:jmh@xxxxxxxxxxxxxxx] Sent: Sunday, January 06, 2008 4:33 PM To: gen-art@xxxxxxxx Cc: Mary Barnes; ietf@xxxxxxxx; Brenner, Michael Ralf (Michael); dromasca@xxxxxxxxx Subject: Re: LC reviews: draft-brenner-dime-peem I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: Diameter Polic Processing Application Reviewer: Joel M. Halpern Review Date: 6-January-2008 IETF LC End Date: 17-January-2008 IESG Telechat date: N/A Summary: This document is nearly ready for publication as an information RFC. The first of the two comments below is probably primarily the IESG's concern, although it affects the IETF last call. The second comment is a more general issue. Comments: This document requests assignment of a Diameter Command Code. As this requires "IETF Consensus" additional care may be needed to ensure that the Last Call produces clarity on the required consensus. It would seem appropriate for the last call announcement to have indicated this requirement. It is difficult to claim "IETF Consensus" from the typical non-response to IETF last call for informational documents. It seems exceedingly unlikely that the protocol exchanges to support a separate policy processing application introduce no new security issues compared with the Diameter base protocol in the assumed Diameter deployment. Obviously, as I am not performing a full review of the PEM-1 protocol, I can not assert that there are or are not security implications, but it would seem that there are likely to be such. I would be less concerned, but examination of the PEM-1 specification did not show the existence of a security discussion which could be taken to serve in lieu of such a section. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf