Hi, Roland, please respond. Otherwise this draft is unlikely to be approved on tomorrow's telechat.
Thanks, Lars On 2010-9-1, at 15:13, Jukka Manner wrote: > Hi, > > Thank you for the good review, this was very helpful. > > Roland Bless is our editor, I'll let him take charge of the edits and > propose fixes as needed. > > regards, > Jukka > > On 09/01/2010 01:55 AM, Ben Campbell wrote: >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ >> at<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> Please resolve these comments along with any other Last Call comments you >> may receive. >> >> Document: draft-ietf-nsis-nslp-auth-06.txt >> Reviewer: Ben Campbell >> Review Date: 2010-08-31 >> IETF LC End Date: 2010-08-31 >> IESG Telechat date: (if known) >> >> Summary: >> >> This draft is almost ready for publication as an experimental RFC. There are >> some minor issues that should be considered first, and a few editorial >> comments. >> >> -Major issues: None >> >> -Minor issues: >> >> -- section 3.2.7, 2nd paragraph: "The creator of this attribute lists every >> NSLP object..." >> >> Is there an order requirement? At least, the order in this list must match >> the order in the signature, right? >> >> -- section 4.1.1, 2nd paragraph: >> >> Is HMAC-MD5 still a reasonable choice for a single mandatory-to-implement >> algorithm these days? >> >> -- Section 6.4, 1st paragraph: >> >> This paragraph seems to conflate authentication with authorization. >> Integrity protection provides authentication, from which one can apply >> authorization policy. But it's not authorization policy in itself. >> >> -- Section 7, 3rd paragraph: >> >> This seems to conflict with 3.2.7 and 3.2.8, which only conditionally >> require AUTHENTICATION_DATA to be included. >> >> >> -Nits/editorial comments: >> >> -- section 2, paragraph 2, 2nd sentence: >> >> s/chose/choose >> >> -- section 2, 5th paragraph, 1st sentence: "...operation of the >> authorization is to add one authorization policy object" >> >> Does this mean "... operation of the authorization layer..."? >> >> -- section 4.2, 2nd paragraph: "The ticket can be presented to the NSLP node >> via Kerberos by sending a KRB_CRED message to the NSLP node..." >> >> Who presents it? >> >> "...must be known in advance..." >> >> Who must know it? >> >> -- section 4.3.1.1, 1st paragraph: "...X509_V3_CERT, AUTHENTICATION_DATA >> MUST be generated following these steps" >> >> Who must generate it? >> >> -- section 4.3.1.1, 2nd paragraph: "...verification MUST be done following >> these steps:" >> >> Who must do the verification? >> >> -- section 4.3.1.1, 7th paragraph: " ... the public key of the authorizing >> entity can be extracted from the certificate." >> >> I assume this step is not intended to be optional, but the language "can be" >> implies that it is. >> >> -- section 4.3.1.2, 1st paragraph: "...AUTHENTICATION_DATA MUST be generated >> following these steps:" >> >> Who must generate it? >> >> -- section 4.3.1.2, first bullet in list of steps: >> >> That's not really a step. >> >> --... Third bullet >> >> Who signs it? >> >> -- ... First paragraph after first bullet list: "verification MUST be done" >> >> Who must do the verification? >> >> -- section 4.4, 1st paragraph after bullet list: The Key-ID in the >> AUTHENTICATION_DATA allows to refer" >> >> "allows" is a transitive verb in this context. I suggest "... allows [some >> actor] to refer", or "...allows the reference..." >> >> -- section 6.2.3, general: >> >> It's not clear to me if you mean for QNE/PDP to refer to one or the other, >> or the combination of the QNE and PDP. >> >> > > -- > Jukka MJ Manner, Professor, PhD. Phone: +358+(0)9+451 2481 > Aalto University Mobile: +358+(0)50+5112973 > Department of Communications Fax: +358+(0)9+451 2474 > and Networking (Comnet) Office: G320a (Otakaari 5A) > P.O. Box 13000, FIN-00076 Aalto E-mail: [email protected] > Finland WWW: www.comnet.tkk.fi _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
