While [BRSKI] reads better, the mix of 8995 in other contexts confuses, replace with [RFC8995]

consistently reference CBOR, omit section reference to STD

Author: mcr

draft-ietf-anima-rfc8366bis.md

@@ -83,7 +83,7 @@ normative:
     seriesinfo:
       ITU-T Recommendation X.690,: ISO/IEC 8825-1
   ZERO-TOUCH: RFC8572
-  BRSKI: RFC8995
+  RFC8995:
   PRM: I-D.ietf-anima-brski-prm
   CLOUD: I-D.ietf-anima-brski-cloud
   IDEVID:
@@ -147,7 +147,7 @@ the Pledge's manufacturer (i.e., the Manufacturer Authorized Signing
 Authority (MASA)).
 
 This document obsoletes RFC8366: it includes a number of desired extensions into the YANG module.
-The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of BRSKI/RFC8995.
+The Voucher Request YANG module defined in RFC8995 is also updated and now included in this document, as well as other YANG extensions needed for variants of RFC8995.
 
 --- middle
 
@@ -177,8 +177,8 @@ The collection of all these actors is collectively known as the Domain.
 A Voucher may be useful in several contexts, but the driving motivation herein is to support secure Onboarding mechanisms.
 This is accomplished by assigning an Owner to the Pledge, enabling it to authenticate the network that it is connected to.
 
-{{RFC8366}} originally defined the Voucher as the only Voucher Artifact, leaving the Voucher Request that is used in BRSKI to be defined in {{BRSKI}}.
-This document includes both Voucher and Voucher Request obsoleting {{RFC8366}}, and updating {{BRSKI}}.
+{{RFC8366}} originally defined the Voucher as the only Voucher Artifact, leaving the Voucher Request that is used in BRSKI to be defined in {{RFC8995}}.
+This document includes both Voucher and Voucher Request obsoleting {{RFC8366}}, and updating {{RFC8995}}.
 
 YANG is not easily extended except by updating the YANG module definition.
 Since {{RFC8366}} was written, the common pattern is to publish YANG modules as two documents: one with only the YANG module, and the other one with usage, motivation and further explanation.
@@ -194,7 +194,7 @@ indicated lifetime.
 In order to support long lifetimes, this document recommends using short lifetimes with programmatic renewal, see {{renewal-over-revocation}}.
 
 Some Onboarding protocols using the Voucher Artifact defined in
-this document include: {{ZERO-TOUCH}}, {{SECUREJOIN}}, {{BRSKI}} and {{cBRSKI}}.
+this document include: {{ZERO-TOUCH}}, {{SECUREJOIN}}, {{RFC8995}} and {{cBRSKI}}.
 
 # Terminology
 
@@ -412,23 +412,23 @@ This document obsoletes {{RFC8366}}.
 
 ## Attempts and motivation to extend RFC8366 {#extendfail}
 
-{{RFC8366}} was published in 2018 during the development of {{BRSKI}},
+{{RFC8366}} was published in 2018 during the development of {{RFC8995}},
 {{ZERO-TOUCH}} and other work-in-progress efforts.
 Since then the industry has matured significantly, and the in-the-field activity which this document supports has become known as _Onboarding_ rather than _Bootstrapping_.
 
-The focus of {{BRSKI}} was Onboarding of ISP and Enterprise owned wired routing and switching equipment, with IoT devices being a less important aspect.
+The focus of {{RFC8995}} was Onboarding of ISP and Enterprise owned wired routing and switching equipment, with IoT devices being a less important aspect.
 {{ZERO-TOUCH}} has focused upon Onboarding of CPE equipment like cable modems and other larger IoT devices, again with smaller IoT devices being of lesser importance.
 
-Since {{BRSKI}} was published there is now a mature effort to do application-level Onboarding of constrained IoT devices defined by the Thread Group and the Fairhair Alliance (now OCF) {{fairhair}}.
-The {{cBRSKI}} document has defined a version of {{BRSKI}} that is usable over constrained IEEE 802.15.4 6LoWPAN networks using CoAP and DTLS, while {{?I-D.ietf-lake-authz}} provides for using CoAP and EDHOC on even more constrained devices with very constrained networks.
+Since {{RFC8995}} was published there is now a mature effort to do application-level Onboarding of constrained IoT devices defined by the Thread Group and the Fairhair Alliance (now OCF) {{fairhair}}.
+The {{cBRSKI}} document has defined a version of {{RFC8995}} that is usable over constrained IEEE 802.15.4 6LoWPAN networks using CoAP and DTLS, while {{?I-D.ietf-lake-authz}} provides for using CoAP and EDHOC on even more constrained devices with very constrained networks.
 
 {{PRM}} has created a new methodology for Onboarding that does not depend upon a synchronous connection between the Pledge and the Registrar.
 This mechanism uses a mobile Registrar agent that works to collect and transfer signed artifacts via physical travel from one network to another.
 
 Both {{cBRSKI}} and {{PRM}} require extensions to the Voucher Request and the resulting Voucher. The new Attributes are required to carry the additional data and describe the extended semantics.
 In addition {{cBRSKI}} uses the serialization mechanism described in {{RFC9254}} to produce significantly more compact artifacts.
 
-When the process to define {{cBRSKI}} and {{PRM}} was started, there was a belief that the appropriate process was to use the {{RFC7950}} _augment_ mechanism to further extend both the Voucher Request {{BRSKI}} and Voucher {{RFC8366}} artifacts.
+When the process to define {{cBRSKI}} and {{PRM}} was started, there was a belief that the appropriate process was to use the {{RFC7950}} _augment_ mechanism to further extend both the Voucher Request {{RFC8995}} and Voucher {{RFC8366}} artifacts.
 However, {{PRM}} needs to extend an enumerated type with additional values and _augment_ can not do this, so that was initially the impetus for this document.
 
 An attempt was then made to determine what would happen if one wanted to have a constrained version of the {{PRM}} Voucher Artifact.
@@ -440,12 +440,12 @@ After significant discussion the decision was made to simply roll all of the nee
 
 # Updates to RFC8995
 
-This document represents a merge of YANG definitions of the Voucher from {{RFC8366}}, the Voucher Request from {{BRSKI}}, and extensions to each of these from {{cBRSKI}}, {{CLOUD}} and {{PRM}}.
+This document represents a merge of YANG definitions of the Voucher from {{RFC8366}}, the Voucher Request from {{RFC8995}}, and extensions to each of these from {{cBRSKI}}, {{CLOUD}} and {{PRM}}.
 The difficulty with this approach is that the semantics of the definitions needed for the other documents are not included in this document, but rather in the respective other documents.
 
 ## Updates to the use of `idevid-issuer` {#updates-idevid-issuer}
 
-The `voucher-request` module definition that was in {{BRSKI}} Sections 3.2 (tree diagram) and 3.4 (YANG module) is now included in this document.
+The `voucher-request` module definition that was in {{RFC8995}} Sections 3.2 (tree diagram) and 3.4 (YANG module) is now included in this document.
 There is a change to it: the '`idevid-issuer`' Attribute MUST be included in a Registrar Voucher Request (RVR).
 Like the '`serial-number`' value in the RVR, the '`idevid-issuer`' value in the RVR is to be taken from the Pledge's (IDevID) client certificate.
 In some variations of BRSKI, such as {{PRM}}, there is no direct TLS connection between Pledge and Registrar.  Therefore the Pledge's IDevID certificate cannot be extracted from the TLS connection, so those variations define a different channel binding process and may deviate from the above requirement.
@@ -460,11 +460,11 @@ A Registrar MUST apply the following rules for the value of the '`idevid-issuer`
 
 ## Clarifications on the use of `idevid-issuer`
 
-{{RFC8366}} and {{BRSKI}} define the '`idevid-issuer`' attribute for the '`voucher`' and '`voucher-request`' modules (respectively), but they summarily explain when to use it, and why it is used.
+{{RFC8366}} and {{RFC8995}} define the '`idevid-issuer`' attribute for the '`voucher`' and '`voucher-request`' modules (respectively), but they summarily explain when to use it, and why it is used.
 
 The '`idevid-issuer`' Attribute is provided so that the serial number to which the issued Voucher pertains can be relative to the entity that issued the Pledge's IDevID.
 In most cases there is a one to one relationship between the trust anchor that signs Vouchers (and is trusted by the Pledge), and the Certification Authority that signs the IDevID.
-In that case, the '`serial-number`' in the Voucher Data must refer to the same device as the serial number that is in the IDevID certificate (in the '`serialNumber`' element of type '`X520SerialNumber`' per {{Section 2.3.1 of BRSKI}}).
+In that case, the '`serial-number`' in the Voucher Data must refer to the same device as the serial number that is in the IDevID certificate (in the '`serialNumber`' element of type '`X520SerialNumber`' per {{Section 2.3.1 of RFC8995}}).
 
 However, there are situations where the one to one relationship may be broken.
 This occurs whenever a manufacturer has a common MASA, but different products (on different assembly lines) are produced with identical serial numbers.
@@ -490,7 +490,7 @@ If this rule does not apply, the MASA SHOULD NOT include the '`idevid-issuer`' A
 
 ## Clarifications on the format of `idevid-issuer` {#idevid-issuer-format}
 
-{{RFC8366}} and {{BRSKI}} were not fully clear on the required binary format of the '`idevid-issuer`' Attribute.
+{{RFC8366}} and {{RFC8995}} were not fully clear on the required binary format of the '`idevid-issuer`' Attribute.
 This gave rise to incompatible implementations.
 
 This section clarifies the format of the '`idevid-issuer`' Attribute, which contains the full Authority Key Identifier from an IDevID certificate.
@@ -502,7 +502,7 @@ However, because of the above requirement to include the full '`extnValue`' OCTE
 
 ## Errata closed
 
-The above updates to {{BRSKI}} addresses errata {{eid7263}}.
+The above updates to {{RFC8995}} addresses errata {{eid7263}}.
 
 # Signature mechanisms
 
@@ -543,7 +543,7 @@ In the Voucher Request, the signer is the Pledge (in the PVR), or the Registrar
 Note that Section 5.1 of {{RFC5652}} includes a
 discussion about how to validate a CMS object, which is really a
 PKCS7 object (cmsVersion=1).  Intermediate systems (such as the
-Bootstrapping Remote Secure Key Infrastructures {{BRSKI}} Registrar)
+Bootstrapping Remote Secure Key Infrastructures {{RFC8995}} Registrar)
 that might need to evaluate the Voucher in flight MUST be prepared for
 such an older format.
 No signaling of the format version is necessary, as the manufacturer knows the capabilities
@@ -789,13 +789,13 @@ Note that {{RFC9254}} does not strictly require use of SIDs: instead of a SID va
 be used. But this would significantly increase the size of the Voucher Data.
 
 Instead, a manufacturer MAY use the '`manufacturer-private`' Attribute to put any content they wish.
-In CBOR serialization, if a plain CBOR map would be used, it would be subject to delta encoding: so use of this Attribute requires that the contents are bstr-encoded {{CBOR}} {{RFC8949, Section 3.1}} (Major type 2).
+In CBOR serialization, if a plain CBOR map would be used, it would be subject to delta encoding: so use of this Attribute requires that the contents are bstr-encoded (Major type 2).
 In JSON serialization, delta encoding does not get in the way, and the manufacturer MAY use any encoding that is convenient for them, but base64URL encoding {{?RFC4648, Section 5}} is RECOMMENDED.
 
 
 # Voucher Request Artifact {#voucher-request}
 
-{{BRSKI, Section 3}} defined a "voucher-request" Artifact as an augmented Artifact from the "voucher" Artifact originally defined in {{RFC8366}}.
+{{RFC8995, Section 3}} defined a "voucher-request" Artifact as an augmented Artifact from the "voucher" Artifact originally defined in {{RFC8366}}.
 That definition has been moved to this document, and translated from the "yang-data" extension {{RFC8040}} to the "sx:structure" extension {{RFC8791}}.
 
 ## Tree Diagram {#voucher-request-tree-diagram}
@@ -972,7 +972,7 @@ by Section 3.7 of {{YANG-GUIDE}}.
 
 This document updates two URIs in the "IETF XML Registry" {{RFC3688}}.
 
-IANA has registered the following based on {{RFC8366}} and {{BRSKI}} respectively:
+IANA has registered the following based on {{RFC8366}} and {{RFC8995}} respectively:
 
 > {:compact}
 >    URI:
@@ -1019,7 +1019,7 @@ IANA has registered the following based on {{RFC8366}}:
 This reference should be updated to point to this document and the "File" entry should be updated to point to the
 new module revision in {{voucher-yang-module}}.
 
-IANA has registered the following based on {{BRSKI}}:
+IANA has registered the following based on {{RFC8995}}:
 
 > {:compact}
 >   name: