Draft: draft-ietf-msec-newtype-keyid-01.txt Reviewer: Elwyn Davies Review Date: Thursday 7/14/2005 8:37 AM LC Date: 8 July 2005 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. Associated with this there should be an explicit statement in s4 that no equivalent of SRTP_ID would be needed in this case. 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. 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? Editorial Nits You should run idnits: there are non ascii characters in the document, e.g. bullet point marks in s2. 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./