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.