Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields
RFC 6495
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
Lars Eggert No Objection
Section 4., paragraph 3: > | 253-254 | Experimental use | It would be good to add some guidance about how these experimental values are envisioned to be used.
(Jari Arkko; former steering group member) (was Discuss) Yes
(Ralph Droms; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
The document should have an Informative reference to RFC 5226 from the IANA Considerations section.
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) (was Discuss) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
I support Jari's discuss about the registry already existing.
(Peter Saint-Andre; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (was Discuss) No Objection
I sent these during IETF LC. #1) Abstract: r/This document request to IANA the creation and management of a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI)./This document requests that IANA create and maintain a registry for this field. This document also specifies a new Name Type field based on a certificate Subject Key Identifier (SKI). #2) Sec 2: r/This document request to IANA the creation and management of a registry for this field./This document requests that IANA create and maintain a registry for this field. #3) Sec 3: You point to both RFC 5280 and sidr-res-certs for how to compute the SKI. Shouldn't you just be point to one (i.e., sid-res-certs)? That is r/Section 4.2.1.2 of [RFC5280]/[draft-ietf-sidr-res-certs-17] #4) Sec 3.1 (or wherever it ends up): r/then the SKI must be equal/then the SKI MUST be equal #5) To future proof this document it would be good if it just registered values for SHA-224, SHA-256, SHA-384, and SHA-512.
(Stewart Bryant; former steering group member) No Objection
Abstract "This document request to IANA the creation and management of a registry for this field." is grammatically incorrect ====== In Section3 the table fragment Name Type 3 SHA-1 Subject Key Identifier (SKI) Should have the same table headings as the table in the IANA section ====== In the IANA considerations section "New assignments of Name Type field Is through Standards Action." is not grammatically correct, and "Name Type field" should surely be "SEND Name Type field ICMP TA option", though an SLA may be appropriate. In the table: "SHA-1 Subject Key Identifier (SKI) (Section 3)" should probably be SHA-1 Subject Key Identifier (SKI) (Section 3 of RFCxxx)
(Tim Polk; former steering group member) No Objection
I support jari's discuss position on registry existence.