I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document:draft-ietf-csi-send-name-type-registry-03.txt Reviewer: Elwyn Davies Review Date: 14 May 2010 IETF LC End Date: 14 May 2010 IESG Telechat date: (if known) - Summary: Probably not ready. There seems to be a conflict or confusion between the prescriptive specification of a single algorithm for how the Subject Key Identifier has to be created in this document and the permissive specification in RFC 5280 that allows any suitable algorithm. Either this specification will only deal with certificates that use the chosen SHA-1 hash or this specification is unnecessarily restrictive. There are also a a few (related) minor issues and nits. Major issues: s3/s3.1: There seems to be some confusion here. Section 4.2.1.2 of RFC 5280 does not specify a unique method for encoding the Subject Key Identifier extension and there doesn't appear to be any method of finding out what method was (allegedly) used to generate the Subject Key Identifier. S3 specifies that the SEND TA option has to carry the Key identifier in a specific one of those forms (#1 in RFC 5280). S3.1 specifies that the TA option carries the value from the SKI extension (without knowing whether that field is the SHA-1 form or some other). It appears that this document is placing a restriction on the algorithm used to generate the SKI extension value, but without saying this explicitly. This all seems a bit of a mess.. or am I missing something? Presumably the reason for the DER-encoding cruft is to facilitate simple comparison. Minor issues: s3/s3.1: Is the 'Key Identifier' described here sent as the value of the 'Name' field in the TA option? If so, say so. Otherwise explain what is in the Name field in this case and where the Key Identifier fits in. s3: Needs a reference to specify how to do DER-encoding of ASN.1 (and DER needs expanding). Nits/editorial comments: Abstract: s/This document request to IANA/This document is a request to IANA for the/ s2, para 1: s/to certify a router authority/to certify a router's authority/. s/for NDP/for the NDP/, s/This document request to IANA/This document is a request to IANA for the/ s2, para 2: s/the certificates are declared/the certificates ia declared/ s3: It would be clearer if the line starting '3 SHA-1' was indented a bit and the description separated so that it doesn't sit under the 'Name Type' header. Something like: Name Type Description 3 SHA-1 Subject Key Identifier (SKI) s4, last para: s/is through/require/; there should be a reference to RFC 5226. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf