Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request
draft-ietf-netconf-sztp-csr-14

[Ballot comment]
I concur with Zahed's DISCUSS: The media types in the examples should be "application/yang-data+json", I believe.  There's currently "yang.data" instead of "yang-data".

[Ballot comment]
Reference [I-D.ietf-netconf-crypto-types] from this Proposed Standard to
draft-ietf-netconf-crypto-types of unknown standards level. That should be
fixed in the datatracker for draft-ietf-netconf-crypto-types...

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD
License".

Thanks to Meral Shirazipour for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/4XKQuQMRJ3xEca_Le-NpYcF-RYI).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 4.1.1. , paragraph 5, nit:
-    private key and associated identity certificates and reexecution of
+    private key and associated identity certificates and re-execution of
+                                                          +

Section 2.1. , paragraph 5, nit:
> ver that it supports the ability the generate CSRs. This parameter conveys if
>                                  ^^^^^^^^^^^^
After "the", the verb "generate" doesn't fit. Is "generate" spelled correctly?
If "generate" is the first word in a compound adjective, use a hyphen between
the two words. Using the verb "generate" as a noun may be non-standard.

Section 2.1. , paragraph 5, nit:
>  the SZTP-client is able to generate an new asymmetric key and, if so, which
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Section 3.2. , paragraph 20, nit:
>  the TaggedCertificationRequest and it a bodyPartId and the certificateReque
>                                    ^^^^
A verb may be missing between "it" and "a", or a word may be misspelled.

Section 3.2. , paragraph 20, nit:
>  the TaggedCertificationRequest and it a bodyPartId and the certificateReque
>                                    ^^^^
A verb may be missing between "it" and "a", or a word may be misspelled.

Section 3.2. , paragraph 21, nit:
>  the TaggedCertificationRequest and it a bodyPartId and the certificateReque
>                                    ^^^^
A verb may be missing between "it" and "a", or a word may be misspelled.

Section 4.1.5. , paragraph 7, nit:
> in Wu. Contributors Special thanks goes to David von Oheimb and Hendrik Broc
>                                    ^^^^
It seems that the correct verb form here is "go".

Document references draft-ietf-netmod-factory-default, but that has been
published as RFC8808.

Document references draft-ietf-netconf-keystore-22, but -23 is the latest
available revision.

Document references draft-ietf-netconf-trust-anchors-15, but -16 is the latest
available revision.

These URLs point to tools.ietf.org, which is being deprecated:
* http://tools.ietf.org/wg/netconf

These URLs in the document did not return content:
* http://standards.ieee.org/findstds/standard/802.1AR-2018.html

[Ballot comment]
Thank you to Yaron Sheffer for the SECDIR review.

** Section 4.1.1. 

For instance, an NMS controller/orchestrator
  application could periodically prompt the SZTP-client to generate a
  new private key and provide a certificate signing request (CSR) or,
  alternatively, push both the key and an identity certificate to the
  SZTP-client using

I don’t have a sense of the classes of endpoints that would rely on SZTP.  Would it include highly constrained or battery powered devices for which this re-keying would be too expensive?

** Editorial nits:
-- Section 2.1.  s/an new/a new/
-- Section 2.2.  Typo. s/Following are/The following are/
-- Section 4.1.1.  s/forever contain/contain/

[Ballot comment]
A quick note to say thanks to the WG for this document, and also to Dan, Rob, the authors for the OpsDir review thread.

[Ballot comment]
Thanks for this document; it seems useful to have the flexibility to
specify a CSR and get an LDevID during enrollment.

I had a similar concern as Zahed's Discuss point (though I'm not sure
I can really express my concerns very well yet), and will attempt to follow
the discussion thereof.

Section 2.1

Why do we need the "sztp-csr" namespace prefix on the new nodes in the
get-bootstrapping-data example, but not need the "ietf-sztp-csr" prefix
on the nodes in the ietf-restconf/errors example?

Section 2.3

          description
            "Provides the CSR generated by the SZTP-client.

              When present, the SZTP-server SHOULD respond with
              an SZTP onboarding information message containing
              a signed certificate for the conveyed CSR.  The
              SZTP-server MAY alternatively respond with another
              HTTP error containing another 'csr-request', in
              which case the SZTP-client MUST invalidate the
              previously generated CSR.";

I'm curious what is intended by "invalidate the [...] CSR".  My
background on CSR usage hasn't really encountered a sense of "validity"
for them that would need cancellation, since it's not really a important
piece of information in its on right (just a way to ask a CA to do
something).  The interesting bit is whether the CA actually issued
anything, but I'm not sure how much harm a stale CSR would actually
cause.

Section 3.2

    identity cmp-csr {
      base certificate-request-format;
      description
        "Indicates that the ZTP-client supports generating
          requests using a constrained version of the PKIMessage
          containing a p10cr structure defined in RFC 4210.";

I'd probably spend a few more words to indicate the nature of the
constraints that cause us to say "constrained version".
(Likewise for the cmc-csr.)

            Enables the ZTP-server to provide a fully-populated
            CertificationRequestInfo structure that the ZTP-client
            only needs to sign in order to generate the complete
            'CertificationRequest' structure to send to ZTP-server
            in its next 'get-bootstrapping-data' request message.

            When provided, the ZTP-client SHOULD use this structure
            to generate its CSR; failure to do so MAY result in a
            400 Bad Request response containing another 'csr-request'
            structure.

This guidance seems to risk running afoul of the first rule of PKIs:
know what you sign.  While I understand that the context for this
protocol exchange is a relatively "dumb" device getting onboarded into
the owner's deployment, and that the owner may in fact require some
things in the LDevID that were not coded into the device by its
implementors, I don't think we should stand mute on the security
considerations of asking for a certificate that contains
attributes/restrictions/etc. that are not understood.

          leaf cmc-csr {
            type binary;
            description
              "A constrained version of the 'Full PKI Request'
                message defined in RFC 5272, encoded using ASN.1

(Same comment about "constrained version" as above.)

                For asymmetric key-based origin authentication based on
                the initial device identity certificate's private key
                that signs the encapsulated CSR signed by the local
                device identity certificate's private key, the PKIData
                contains one cmsSequence element and no
                otherMsgSequence element.  The cmsSequence is the

This part says nothing about whether there is a reqSequence element in
the toplevel PKIData...

                TaggedContentInfo and it includes a bodyPartID element
                and a contentInfo.  The contentInfo is a SignedData
                encapsulating a PKIData with one reqSequence element
                and no cmsSequence or otherMsgSequence elements. The
                reqSequence is the TaggedRequest and it is the tcr
                CHOICE. The tcr is the TaggedCertificationRequest and
                it a bodyPartId and the certificateRequest elements.
                [...]

... since this reqSequence seems to refer to the PKIData inside the
SignedData in the contentInfo in the cmsSequence.  Should we say
anything about the presence/absence of reqSequence in the toplevel
PKIData (since we do in the other two cases)?

        case cmp-csr {
          leaf cmp-csr {
            type binary;
            description
              [...]
                For asymmetric key-based origin authentication of a
                CSR based on the initial device identity certificate's
                private key for the associated initial device identity
                certificate's public key, PKIMessages contains one
                PKIMessage with the header and body elements, no
                protection element, and should contain the extraCerts
                element. [...]

Is this a "should" or a "SHOULD"?

                For asymmetric key-based origin authentication based on
                the initial device identity certificate's private key
                that signs the encapsulated CSR signed by the local
                device identity certificate's private key, PKIMessages
                contains one PKIMessage with the header, body, and
                protection elements, and should contain the extraCerts
                element. [...]

(ditto)

Section 4

I'd consider also mentioning the CMC, CMP, and PKCS#10 security
considerations as being applicable to the relevant CSR choices.

Section 4.1.1

  The security of this private key is essential in order to ensure the
  associated identity certificate can be used as a root of trust.

"root of trust" is something of a loaded term (see the ongoing
discussion in the RATS WG for differing interpretations of what it
means).  I'd suggest using a different phrasing, like "can be used to
authenticate the device it is issued to".

Section 4.1.3

Should we mention the "nonce" parameter to get-bootstrapping-data
here?

  When a public/private key pair associated with the manufacturer-
  generated identity certificate (e.g., IDevID) is used for the
  request, there may not be confirmation to the SZTP-client that the
  response has not been replayed; however, the worst case result is a
  lost certificate that is associated to the private key known only to
  the SZTP-client.

That's only the worse-case result if we assume that the private key is
not compromised.  We might want to reiterate that assumption and/or
mention the scope of consequences for the case where the private key is
compromised.

Section 4.2.2

  When a new asymmetric key is used, with the CMP or CMC formats, the
  parent ASN.1 structure of the CSR provides origin authentication
  using either the manufacturer-generated private key or a shared
  secret.  In this way the proof-of-possession of the CSR is directly
  linked to the proof-or-origin provided by the parent ASN.1 structure.

I think this section would be a good place to talk about how in the "raw
PKCS#10" case, there needs to be a level of trust in the bootstrapping
server roughly analogous to how an RA would be trusted, in that they are
the only entity that has verified the client identity and the
bootstrapping server's assertion of the client identity is a key step in
the certificate issuance process.

Such discussion might also contrast use of the IDevID at the TLS layer
with HTTP-layer authentication of the client.

Section 4.4

Though our "identity" and "grouping" statements (as noted) to not appear
in any protocol-accessible nodes as-is, we might still feel empowered to
discuss any considerations that would apply when they actually are
instantiated in other modules.  However, it seems that there would not
be anything new to say other than what's in RFCs 2986, 4210, and 5272,
and if we take my suggestion to reference them from the toplevel
section 4, there would be no need to do so again here.

NITS

Abstract, Introduction

I'd consider clarifying that when we "extend" the get-bootstrapping-data
RPC to include a CSR, that's as the input to the RPC, not the output.
(I initially misread it when reading the abstract.)

Section 2.2

You may want to use more-recent dates than 2015 for the examples.

I suggest using different "BASE64VALUE="s for the different public
keys in the two-asymmetric-key example.

Section 3.2

            leaf-list algorithm-identifier {
              type binary;
              min-elements 1;
              description
                "An AlgorithmIdentifier, as defined in RFC 2986,
                  encoded using ASN.1 distinguished encoding rules
                  (DER), as specified in ITU-T X.690.";

At risk of excessive pedanticism, I see RFC 2986 discuss the
parametrized AlgorithmIdentifier{}, which compares it to the
unparameterized AlgorithmIdentifier in the ensuing discussion.
AlgorithmIdentifier is (also) defined in, e.g., RFC 5280 if we didn't
want to get into the parameterization here.  (Any change made here
should be made throughout, of course.)

    grouping csr-grouping {
      description
        "Enables a ZTP-client to convey a certificate signing
          request, using the encoding format selected by a
          ZTP-server's 'csr-request' response to the ZTP-client's
          previously sent 'get-bootstrapping-data' request
          containing the 'csr-support' node.";

(nit) Since we're (now) in just the ztp-types module, we can't
necessarily assume there will be a "get-bootstrapping-data" request
involved.

                For asymmetric key-based origin authentication of a
                CSR based on the initial device identity certificate's
                private key for the associated identity certificate's
                public key, the PKIData contains one reqSequence

(nit) I think the "associated identity certificate's public key"
phrasing here is a bit confusing.  I think that we're trying to cover
the case where the key from the IDevID is reused for the LDevID, so
we're using the LDevID private key to authenticate the CSR and it's
sigining "it's own" public key", but in the context of this YANG
grouping we've mostly lost the context of the "associated identity
certificate".
(A similar comment applies to the CMP case.)

                elements. The reqSequence is the TaggedRequest and it
                is the tcr CHOICE. The tcr is the

(nit) should we have another word after "CHOICE", like "arm" or
"branch"?

                TaggedCertificationRequest and it a bodyPartId and the

(nit) also, I'd maybe s/the/a/ for these two "the  is the "
constructions since they seem to just be describing the type of a given
ASN.1 element.
Also, s/it/it is/.

Section 4.1.1

  private keys.  For instance, an NMS controller/orchestrator
  application could periodically prompt the SZTP-client to generate a
  new private key and provide a certificate signing request (CSR) or,
  alternatively, push both the key and an identity certificate to the
  SZTP-client using, e.g., a PKCS #12 [RFC7292].  [...]

maybe "a PKCS #12 message"?

Section 4.1.5

  The CMP and CMC certificate request formats defined in this document
  support origin authentication.  A raw PKCS#10 does not support origin
  authentication.

"PKCS#10 CSR"

[Ballot discuss]
I would like to discuss two points -

  - as this specification add more detailed response for HTTP 400 Bad Request error code. I would like to know if RFC7807 has been considered for such usage.

  - is this specification defining new media type "application/yang.data+json"? and would ask why? It could very well use "application/problem+json" or "application/problem+xml" from RFC7807 or even "application/yang-data+json".

[Ballot discuss]
I would like to discuss two points -

  - as this specification add more detailed response for HTTP 400 Bad Request error code. I would like to know if RFC7807 has been considered for such usage.
  - is this specification defining new media type "application/yang.data+json"? and would ask why? It could very well use "application/problem+json" or "application/problem+xml" from RFC7807 or even "application/yang-data+json".

[Ballot comment]
Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Mahesh Jethanandani for the shepherd's write-up even if the section about the WG consensus does not give any information about the WG consensus...

I hope that this helps to improve the document,

Regards,

-éric
== COMMENTS ==

-- Section 1.2 --
Just wondering why the terms of SZTP-client/server have to be defined in the document rather than using the previously defined bootstrap server.

-- Section 1.4 --
Even if the base64 content is rather long, why not providing examples in appendix ?

-- Section 2.1 --
I am not a YANG expert, but it seems that the lines "module: ietf-sztp-csr" should only appear once in the tree view ?

In "generate an new asymmetric key", should it rather be a "key pair" ? Of course, being asymmetric requires two keys so this may be implicit.

-- Section 2.2 --
As P10 is not previously defined (guessing it is PKCS#10 though), suggest s/P10-based/PCKS#10-based/

In the example for the algorithm leaves, are the base64 values really too long to be represented in the examples ?

== NITS ==
In section 3, "This module is defines independently" ?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-netconf-sztp-csr-11. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

two, new namespaces will be registered as follows:

ID: yang:ietf-sztp-csr
URI: urn:ietf:params:xml:ns:yang:ietf-sztp-csr
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-ztp-types
URI: urn:ietf:params:xml:ns:yang:ietf-ztp-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.  This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

two, new YANG modules will be registered as follows:

Name: ietf-sztp-csr
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-sztp-csr
Prefix: sztp-csr
Module:
Reference: [ RFC-to-be ]

Name: ietf-ztp-types
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ztp-types
Prefix: ztp-types
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
IANA Services

The following Last Call announcement was sent out (ends 2021-11-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netconf-sztp-csr@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, rwilton@cisco.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Conveying a Certificate Signing Request (CSR) in a Secure Zero Touch Provisioning (SZTP) Bootstrapping Request) to Proposed Standard


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'Conveying a Certificate Signing
Request (CSR) in a Secure Zero Touch
  Provisioning (SZTP) Bootstrapping Request'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-11-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This draft extends the "get-bootstrapping-data" RPC defined in RFC
  8572 to include an optional certificate signing request (CSR),
  enabling a bootstrapping device to additionally obtain an identity
  certificate (e.g., an LDevID, from IEEE 802.1AR) as part of the
  "onboarding information" response provided in the RPC-reply.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netconf-sztp-csr/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-netconf-crypto-types: YANG Data Types and Groupings for Cryptography (None - Internet Engineering Task Force (IETF))

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This draft is requesting a Proposed Standard and it indicates it as such in the title.

(2) 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.

This draft extends the "get-bootstrapping-data" RPC defined in
[RFC8572] to include an optional certificate signing request (CSR)
[RFC2986], enabling a bootstrapping device to additionally obtain an
identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of
the "onboarding information" response provided in the RPC-reply.

Working Group Summary:

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

This document was reviewed in both IETF meeting (physical and virtual), and on the NETCONF WG mailing list. A YANG doctors review has been requested, and any comments received from that review will be incorporated into the 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?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

The document shepherd is Mahesh Jethanandani and the AD is Rob Wilton.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the progression of the document through the WG and has reviewed the document. As this time, the document has addressed all outstanding comments and as a document shepherd I believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document has been presented to the WG a few times, but it did not receive many comments during those presentations or as it went through WGLC. That could be a reflection of the fact that the authors are authorities and therefore well versed of the topic while presenting a high quality document. It could also be a reflection of the fact that the document has a lot of security aspects, and the WG does not have many experts in the security field.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document shepherd has requested a YANG doctors review for the YANG module in the draft. The document shepherd contemplated getting a security review done on the document. The authors are security experts, and a review request would probably result in the authors reviewing their own document. Therefore the review was skipped.

(6) Describe any specific concerns or issues that the Document Shepherd has 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.

The document shepherd does not have any specific concerns or issues that needs the attention of the Responsible Area Director and/or the IESG beyond what has already been identified in (5).

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, all the authors have confirmed that they are not aware of any IPRs related to the document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed against this document.

(9) 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 has been discussed both on the mailing list and in the WG meetings. The number of people who have contributed actively to the document has been small (mostly the authors) with ample opportunity given for folks to comment on the changes in the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

A run of idnits outputs these errors/warnings, though they are not unprecedented.

  -- The draft header indicates that this document updates RFC8572, but
    the abstract doesn't seem to directly say this.  It does mention
    RFC8572 though, so this could be OK.

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'ITU.X690.2015'

  ** Downref: Normative reference to an Informational RFC: RFC 2986


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

A yang doctors review has been requested and should be forthcoming.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) 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 plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

As identified by idnits, there are two references to downward normative references.

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'ITU.X690.2015'

  ** Downref: Normative reference to an Informational RFC: RFC 2986

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC 8572, and it indicates it so in the title page, in the abstract and in the introduction section of the document.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document registers one URI and one YANG module. The URI registry is for the "ns" sub registry of the IETF XML Registry maintained at https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. The YANG Module registry request is for the YANG Module Names Registry maintained at https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The document shepherd has run pyang/yanglint to validate the model. He has also validated the JSON examples extracted from the draft against the module defined in the document. He has run idnits to identify some issues that the tool has identified.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This draft is requesting a Proposed Standard and it indicates it as such in the title.

(2) 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.

This draft extends the "get-bootstrapping-data" RPC defined in
[RFC8572] to include an optional certificate signing request (CSR)
[RFC2986], enabling a bootstrapping device to additionally obtain an
identity certificate (e.g., an LDevID [Std-802.1AR-2018]) as part of
the "onboarding information" response provided in the RPC-reply.

Working Group Summary:

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

This document was reviewed in both IETF meeting (physical and virtual), and on the NETCONF WG mailing list. A YANG doctors review has been requested, and any comments received from that review will be incorporated into the 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?

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

The document shepherd is Mahesh Jethanandani and the AD is Rob Wilton.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has followed the progression of the document through the WG and has reviewed the document. As this time, the document has addressed all outstanding comments and as a document shepherd I believe the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

The document has been presented to the WG a few times, but it did not receive many comments during those presentations or as it went through WGLC. That could be a reflection of the fact that the authors are authorities and therefore well versed of the topic while presenting a high quality document. It could also be a reflection of the fact that the document has a lot of security aspects, and the WG does not have many experts in the security field.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

The document shepherd has requested a YANG doctors review for the YANG module in the draft. The document shepherd contemplated getting a security review done on the document. The authors are security experts, and a review request would probably result in the authors reviewing their own document. Therefore the review was skipped.

(6) Describe any specific concerns or issues that the Document Shepherd has 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.

The document shepherd does not have any specific concerns or issues that needs the attention of the Responsible Area Director and/or the IESG beyond what has already been identified in (5).

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, all the authors have confirmed that they are not aware of any IPRs related to the document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures have been filed against this document.

(9) 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 has been discussed both on the mailing list and in the WG meetings. The number of people who have contributed actively to the document has been small (mostly the authors) with ample opportunity given for folks to comment on the changes in the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

A run of idnits outputs these errors/warnings, though they are not unprecedented.

  -- The draft header indicates that this document updates RFC8572, but
    the abstract doesn't seem to directly say this.  It does mention
    RFC8572 though, so this could be OK.

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'ITU.X690.2015'

  ** Downref: Normative reference to an Informational RFC: RFC 2986


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

A yang doctors review has been requested and should be forthcoming.

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) 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 plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

As identified by idnits, there are two references to downward normative references.

  -- Possible downref: Non-RFC (?) normative reference: ref.
    'ITU.X690.2015'

  ** Downref: Normative reference to an Informational RFC: RFC 2986

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

This document updates RFC 8572, and it indicates it so in the title page, in the abstract and in the introduction section of the document.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

This document registers one URI and one YANG module. The URI registry is for the "ns" sub registry of the IETF XML Registry maintained at https://www.iana.org/assignments/xml-registry/xml-registry.xhtml#ns. The YANG Module registry request is for the YANG Module Names Registry maintained at https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

The document shepherd has run pyang/yanglint to validate the model. He has also validated the JSON examples extracted from the draft against the module defined in the document. He has run idnits to identify some issues that the tool has identified.