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
