Ben, thanks for the review. Editors, please respond to the points Ben raised, and see if you can improve the text.
Thanks, Lars On 2010-9-1, at 1:55, 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. > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
