Subject Key Identifier (SKI) SEcure Neighbor Discovery (SEND) Name Type Fields
draft-ietf-csi-send-name-type-registry-06

[Ballot comment]
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.

[Ballot comment]
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)

[Ballot discuss]
We obviously need to add the SKI option to the name types.

However, the document claims to create a registry for the name types
in SEND. This is incorrect for two reasons:

1. It was already created in RFC 3971, Section 11:

  "This document defines a new name space for the Name Type field in the
  Trust Anchor option.  Future values of this field can be allocated by
  using Standards Action [3].  The current values for this field are

      1  DER Encoded X.501 Name

      2  FQDN"

  Even if IANA might possibly have missed the creation of the actual
  registry, the right remedy is not to write another RFC, it would be
  to correct the IANA registry.

2. The registry actually already exists:

  http://www.iana.org/assignments/icmpv6-parameters

  which says:

  "Registry Name: Trust Anchor option (Type 15) Name Type field
  Reference: [RFC3971]
  Registration Procedures: Standards Action

  Registry:
  Value  Description                              Reference
  -----  ------------------------------------    ---------
  1  DER Encoded X.501 Name                  [RFC3971]
  2  FQDN                                    [RFC3971]"

As a result, the current draft should be updated to merely extend the
registry with new values, not to define the registry policy or create
the registry.

I would like the registry update to add reserved and experimental
values, though. It would also be useful if text from, say, RFC 5494
on the use of experimental code points would be included.

I would also like to change the registration policy from Standards
Action to Standards Action or IESG Approval. We have had multiple
cases where it was useful to be able to grant an exception through
IESG decision.

[Ballot discuss]
We obviously need to add the SKI option to the name types.

However, the document claims to create a registry for the name types
in SEND. This is incorrect for two reasons:

1. It was already created in RFC 3971, Section 11:

  "This document defines a new name space for the Name Type field in the
  Trust Anchor option.  Future values of this field can be allocated by
  using Standards Action [3].  The current values for this field are

      1  DER Encoded X.501 Name

      2  FQDN"

  Even if IANA might possibly have missed the creation of the actual
  registry, the right remedy is not to write another RFC, it would be
  to correct the IANA registry.

2. The registry actually already exists:

  http://www.iana.org/assignments/icmpv6-parameters

  which says:

  "Registry Name: Trust Anchor option (Type 15) Name Type field
  Reference: [RFC3971]
  Registration Procedures: Standards Action

  Registry:
  Value  Description                              Reference
  -----  ------------------------------------    ---------
  1  DER Encoded X.501 Name                  [RFC3971]
  2  FQDN                                    [RFC3971]"

As a result, the current draft should be updated to merely extend the
registry with new values, not to define the registry policy or create
the registry.

[Ballot comment]
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.

[Ballot discuss]
I sent these during IETF LC.  I believe the author is going to make changes, and I will clear these DISCUSS positions once a new version or RFC editor note has been submitted.  I renumbered them because some other comments were addressed.

#1) Sec 2: Add the following to the final paragraph:

Consequently, this document updates section 6.4.3 and 6.4.5 of [RFC3971].

#2) Sec 3: I was kind of expecting to see something like the following (so it looks a lot like RFC 3971 and you don't have to repeat what's in RFC 3971):

3.  SEND SKI trust anchor option Name Type field

3.1 Updates to 6.4.3 of RFC 3971

Add the following under Name Type:

    3 SHA-1 Subject Key Identifier (SKI)

Add the following under Name:

    When the Name Type field is set to 3, the Name field contains a
    160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit
    string of the subject public key, as described in Section
    4.2.1.2 of [RFC5280].

3.2 Updates to 6.4.5 of RFC 3971

Add the following to the penultimate paragraph as the penultimate
sentence:

  If the TA option is represented as a SHA-1 SKI, then the SKI must
  be equal to the SKI extension in the trust anchor's certificate
  calculated as described in [draft-ietf-sidr-res-certs-17].

IANA comments:

Upon approval of this document, IANA will create the following registry
at http://www.iana.org/assignments/TBD

Registry Name: SEND Name Type field in ICMP TA option
Registration Procedure: Standards Action

Initial contents of this registry will be:

Value | Description | Reference |
---------+------------------------------------------------+-----------+
0 | Reserved | [RFC-csi-send-name-type-registry-03]
1 | DER Encoded X.501 Name (RFC 3971) | [RFC-csi-send-name-type-registry-03]
2 | FQDN (RFC 3971) | [RFC-csi-send-name-type-registry-03]
3 | SHA-1 Subject Key Identifier (SKI) (Section 3) |
[RFC-csi-send-name-type-registry-03]
4-252 | Unassigned |
253-254 | Experimental use | [RFC-csi-send-name-type-registry-03]
255 | Reserved | [RFC-csi-send-name-type-registry-03]

Document Shepherd Write-up for draft-ietf-csi-send-name-type-registry-03

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

          The document shepherd is Marcelo Bagnulo who has reviewed
          this version of the document and believes that us ready for
          forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

          The document is a very simple document that mostly creates
          a registry that was not created in RFC3971. We went through the
          WGLC and we have a couple of reviews, mostly editorial.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

          No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

          No special concerns or issues.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

          The document creates a registry that is missing from the original
          SEND spec. We identified the need for it working in the cert profile
          as covered by our charter.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

          No conflicts.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

          I have verified the ID nits and no issues were found.

          No MIB Doctor, media type nor UR type reviews are needed for
          this document.

          The document intended status is STD. It is intended to update
          RFC3971 if approved.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

          The references are split into normative and informative.
          There are two normative references that are in draft status.
          draft-ietf-csi-send-cert will be submitted to the IESG along
          with this draft and they can both progress jointly.
          draft-ietf-sidr-res-certs-17 is being done by the sidr WG,
          which we hope will be submitted to the IESG at some point in time.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

          The whole purpose of the document is mostly the IANA considerations
          section. The content of the IANA considerations is consistent
          with the body of the document. The document creates a IANA
          registry and it is properly identified. Initial allocations for
          the registry are properly identified. The allocation procedure is
          also properly identified. The name for the registry is reasonable.
          No expert review is needed.
 
  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

          The document does no contain any section written in a formal
          language.
 
  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  SEcure Neighbor Discovery (SEND) defines the Name Type field in the
  Trust Anchor option.  This document requests 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).



          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

          Nothing special that worth noting. Not a controversial document.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          The document is the creation of a registry that was missing on RFC3971.
          The need for it was identified as part of the work on SEND cert profiles.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

        Document shepherd: Marcelo Bagnulo
        Area Director: Ralf Droms