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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
