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

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] RE: Gen-Art Review: draft-ietf-msec-newtype-keyid-01.txt

Attachment: draft-ietf-msec-newtype-keyid-04.txt