I am the assigned Gen-ART reviewer for draft-dondeti-msec-mikey-
genext-oma-01.txt
For background on Gen-ART, please see the FAQ at <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.
--------------
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)
Thanks,
RjS
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
