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
