Last Call Review of draft-ietf-netconf-sztp-csr-11
review-ietf-netconf-sztp-csr-11-opsdir-lc-romascanu-2021-11-19-00

This document is Ready from an OPS-DIR  perspective.

This document 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. It proides the ability to provision an identity certificate that is
purpose-built for a production environment during the bootstrapping process
removing the reliance on the manufacturer CA, and enabling the bootstraped
device to join the production environment with an appropriate identity. It's a
clear and useful document, which needs to be read and understood by operators
of IOT networks using the respective technologies.

From an operator perspective, the most relevant sections are 2 and 3. Section 
2 refers to the ietf-sztp-csr  module. It includes a Data Model Overview as
well as hints about how the augmentation and structure defined by the
"ietf-sztp-csr" module are used, including two additional tree diagrams showing
the nodes placed where they are used. I found the example usage in Section 2.2
very useful. Section 2.3 contains the YANG module. Section 3 contains the
description of the data model and the ietf-ztp-types YANG module.

I have one question related to the type of certificates that are supported.
Section 3.2 includes the following:

        The terms 'IDevID' and 'LDevID' are used herein to
        mean 'initial device identifier' and 'local device
        identifer'.  These terms are defined consistent with
        the IEEE 802.1AR specification, though there is no
        requirement that a ZTP-client's identity certificate
        conform to IEEE 802.1AR.

If my understanding is correct, the mechanism described in this document is
generic. However, all the examples and the definitions in the modules refer to
certification conform to IEEE 802.1AR. This is some kind of contradiction.
Maybe some text speaking about other types of certificates should be added. Or
maybe the scope should be defined more narrow to refer to IEEE 802.1AR. In any
case it seems to me that Std-802.1AR-2018 needs to be a Normative Reference -
one cannot understand this document without reading and understanding the IEEE
standards.