Draft: draft-dondeti-msec-mikey-genext-oma-01.txt Reviewer: Robert Sparks [rjsparks@estacado.net] Review Date: Monday 8/28/2006 2:58 PM CST IETF LC Date: 9/04/2006 Summary: This is an AD-sponsored individual submission for consideration as an informational RFC. This draft is basically ready for publication but has one nit that could be fixed before publication. -------------- The document's primary point is to request a new number the IANA registry for the MIKEY General Extensions payload name spaces. The document is concise, well constructed, and easy to read. Thanks! The draft explicitly does not define what payloads with this number mean or how they will be used, but does point to an OMA document that provides that information. It does capture, for instance, the security constraints that the MIKEY extensibility mechanism places on extensions in its security considerations section. If the IESG agrees this is an appropriate way to divide the responsibility of specifying how the bits in the extension payload get used, I have only one nit. I suggest replacing > The data field is opaque to the IETF and is specified in the OMA > BCAST Service and Content > Protection specification [2]. with something like: The contents of this data field are neither defined nor constrained by any IETF specification other than those captured in the Security Considerations section. The definition of the contents of this data field is specified in the OMA BCAST Service and Content Protection specification [2]. (The motivation for the the comment is that I don't know what "opaque to the IETF" will mean to most readers)