Skip to main content

Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields
RFC 6495

Yes

(Jari Arkko)
(Ralph Droms)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(David Harrington)
(Peter Saint-Andre)
(Ron Bonica)
(Russ Housley)

Note: This ballot was opened for revision 06 and is now closed.

Lars Eggert No Objection

Comment (2010-05-20)
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

Yes ()

                            

(Ralph Droms; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (2010-05-09)
The document should have an Informative reference to RFC 5226 from the IANA Considerations section.

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(David Harrington; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (2010-05-20)
I support Jari's discuss about the registry already existing.

(Peter Saint-Andre; former steering group member) No Objection

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2010-05-17)
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

No Objection (2010-05-19)
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

No Objection (2010-05-20)
I support jari's discuss position on registry existence.