Re: [Gen-art] RE: Gen-Art Review: draft-ietf-msec-newtype-keyid-01.txt

[Russ Housley <[e-mail]>]

This is my fault.  I thought -04 had already been posted, but it got 
delayed. Please look at -04.

Russ


At 05:36 AM 2/14/2006, Brian E Carpenter wrote:
>I'm a bit confused. The version on the IESG agenda this week is -03,
>but you attached -04 on January 27. Which should we be looking at?
>
>    Brian
>
>Karl Norrman (KI/EAB) wrote:
>>Hello!
>>Thank you very much for your review.
>>Please see the attached updated draft and inline.
>>[SNIP]
>>
>>>Summary:
>>>[I understand from Laksminath Dondeti that this draft maybe 
>>>withdrawn, but FWIW, here is my review.] This document has some 
>>>minor issues with the IANA considerations and needs some editorial tidying up.
>>>
>>>The 'empty map' option worries me, but I am not sufficiently much 
>>>of security expert to determine if this is justified.
>>>If this is cleared the draft could go forward (but it sounds like 
>>>there will be another revision pass to go through).
>>>
>>>Detailed Review:
>>>
>>>Issues:
>>>I am not sure that I fully understand what is going on the 
>>>justification of the need for an empty map(last para of s2).
>>>'... required parameters are signalled in-band.' => in what protocol?
>>>I think a slightly less opaque explanation would help here.
>>
>>An example is now given (the OMA DRM Content Format used for download).
>>
>>>Associated with this there should be an explicit statement in s4 
>>>that no equivalent of SRTP_ID would be needed in this case.
>>
>>Such a statement is now added (Please note that there is a new Section
>>3, so
>>this text is now in Section 5).
>>
>>>IANA considerations:
>>>This section should refer to the IANA process setup in RFC3380 for 
>>>the payload type and the CS ID map type.
>>>It needs to define a new process for the Key ID Type registry.
>>
>>A process is now set up in the IANA considerations section.
>>
>>>Security Considerations:
>>>Are those that understand these things absolutely convinced that 
>>>creating keys without attaching them to an SA in the process does 
>>>not create some sort of opportunity to create mayhem?
>>
>>The security considerations section is now expanded.
>>
>>>Editorial Nits
>>>
>>>You should run idnits: there are non ascii characters in the 
>>>document, e.g. bullet point marks in s2.
>>
>>This version passed idnits.
>>Thanks and regards,
>>Karl
>>
>>>s1: 3rd para: s/possibility/ability/
>>>s1: 3rd para: (I take it that we are trying to make it easier 
>>>rather than more difficult) s/should be/would be/
>>>s1: 4th para: s/involved/keys/keys involved/
>>>s2: 1st para: s/the MBMS/MBMS/
>>>s2: 2nd para: s/athree level/three level/
>>>s2 10th para: s/involved keys in the/keys being carried in a/
>>>s3: Tables and figures should have captions
>>>s3: s/bytes/octets/ (2 places)
>>>s3: last para: Actually I think (2^16 -1), but I hope I never have 
>>>that many keys ;-)
>>>s5: s/This memo is not foreseen to introduce security 
>>>implications./It is not a anticipated that this memo will have any 
>>>additional security implications beyond those already identified 
>>>for the MIKEY protocol./
>>
>>------------------------------------------------------------------------
>>_______________________________________________
>>Gen-art mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/gen-art
>


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art