Subject: [Gen-art] GenArt review: draft-dondeti-msec-mikey-genext-oma-02.txt (was Genart LC review of draft-dondeti-msec-mikey-genext-oma-01.txt)

From: Robert Sparks <[email-masked]>
Date: Mon, 11 Sep 2006 13:51:00 -0500

This version addresses my nit and I have no new concerns.
Pending the outcome of the reference discussion already noted on the  
tracker, this document is ready for for publication.

RjS

On Aug 28, 2006, at 2:57 PM, Robert Sparks wrote:

> 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-masked]
https://www1.ietf.org/mailman/listinfo/gen-art