added reference for RFC9911, close #146

draft-ietf-anima-rfc8366bis.md

@@ -92,7 +92,6 @@ normative:
     date: 2021-02
     seriesinfo:
       ITU-T Recommendation X.690,: ISO/IEC 8825-1
-  SZTP: RFC8572
   RFC8995:
   PRM: I-D.ietf-anima-brski-prm
   CLOUD: I-D.ietf-anima-brski-cloud
@@ -103,19 +102,17 @@ normative:
     - org: IEEE Standard
     date: 2018
   RFC8791:
-  eid7263:
-    target: "https://www.rfc-editor.org/errata/eid7263"
-    title: "Errata 7263, RFC8995"
 
 informative:
   RFC3688:
-  RFC8446:
+  RFC9846:
   RFC6125:
   RFC6241:
   RFC7435:
   RFC8040:
   RFC8340:
   RFC8366:
+  SZTP: RFC8572
   RFC8792:
   RFC9525:
   COSE: STD96
@@ -141,6 +138,9 @@ informative:
     author:
     - org: Open Connectivity Foundation
     date: 2019-11-01
+  eid7263:
+    target: "https://www.rfc-editor.org/errata/eid7263"
+    title: "Errata 7263, RFC8995"
 
 --- abstract
 
@@ -486,17 +486,17 @@ Another situation occurs when multiple manufacturers share a common MASA.
 In this case, any given serial number in the IDevID certificate may not be unique across all manufacturers.
 
 It is not possible for the Pledge or the Registrar to know which situation applies.
-And because one the above situations may apply, or may occur in the future, there needs to be a contingency to allow uniquely identifying a Pledge regardless of the current or future situation.
+And because one of the above situations may apply, or may occur in the future, there needs to be a contingency to allow uniquely identifying a Pledge regardless of the current or future situation.
 This is realized by the '`idevid-issuer`' Attribute.
 
 It is clarified next, whether or not to include the '`idevid-issuer`' in the PVR, in the RVR and in the Voucher.
 
 Analysis of the situation shows that the Pledge never needs to include '`idevid-issuer`' Attribute in its PVR, because the Pledge's IDevID certificate is available to the Registrar, and the Authority Key Identifier needed to fill this Attribute is contained within that IDevID certificate.
 The Pledge therefore has no need to repeat this.
 
-For the RVR, {{updates-idevid-issuer}} now normatively requires that the '`idevid-issuer`' Attribute must be included.
+For the RVR, {{updates-idevid-issuer}} now normatively requires that the '`idevid-issuer`' Attribute be included.
 
-For the Voucher, {{voucher-yang-module}} normatively requires ("must") that the '`idevid-issuer`' Attribute must be included by a MASA in case the MASA issues a Voucher with a serial number that is known to be not unique within the scope of all the serial numbers represented by the MASA.
+For the Voucher, as detailed in {{voucher-yang-module}}, the '`idevid-issuer`' Attribute MUST be included by a MASA in case the MASA issues a Voucher with a serial number that is known to be not unique within the scope of all the serial numbers represented by the MASA.
 If this rule does not apply, the MASA SHOULD NOT include the '`idevid-issuer`' Attribute in order to achieve a smaller Voucher size.
 
 ## Clarifications on the format of `idevid-issuer` {#idevid-issuer-format}
@@ -974,22 +974,21 @@ security decision.
 
 This document defines a Voucher format that contains time values
 for expirations, which require an accurate clock
-in order to be processed correctly.  Vendors planning on
-issuing Vouchers with expiration values must ensure that devices
-have an accurate clock when shipped from manufacturing
+in order to be processed correctly.
+Vendors planning on
+issuing Vouchers with expiration values need to ensure that
+the devices targetted have an accurate clock when shipped from manufacturing
 facilities and take steps to prevent clock tampering.
 If it is not possible to ensure clock accuracy, then
-Vouchers with time values for expirations should not be issued.
+the expiration time values in Vouchers will have no meaning.
 
 
 ## Protect MASA Signing Key in HSM
 
-Pursuant to the recommendation made in Section 6.1 for the MASA to be
-deployed as an online Voucher signing service, it is RECOMMENDED that
-the MASA's private key used for signing Vouchers is protected by
+As the MASA needs to be able to respond to voucher signing requests,
+it is RECOMMENDED that the MASA's private key used for signing Vouchers is protected by
 a hardware security module (HSM).
 
-
 ## Test Domain Certificate Validity When Signing
 
 If a Domain certificate is compromised, then any outstanding
@@ -1020,7 +1019,7 @@ and which CRL Distribution Point and/or OCSP Responder URLs are
 accessed to validate the Vouchers.  When privacy is important,
 the CMS signed-data content type SHOULD be encrypted, either by
 conveying it via a mutually authenticated secure transport protocol
-(e.g., TLS {{RFC8446}}) or by encapsulating the signed-data
+(e.g., TLS {{RFC9846}}) or by encapsulating the signed-data
 content type with an enveloped-data content type (Section 6
 of {{RFC5652}}), though details for how to do this are outside
 the scope of this document.
@@ -1038,127 +1037,24 @@ by Section 3.7 of {{YANG-GUIDE}}.
 
 ## The IETF XML Registry
 
-This document updates two URIs in the "IETF XML Registry" {{RFC3688}}.
-
-IANA is requested to register the following, updating the registration to point to this document:
+This document updates two URIs in the "IETF XML Registry" {{RFC3688}}: `urn:ietf:params:xml:ns:yang:ietf-voucher` and
+`urn:ietf:params:xml:ns:yang:ietf-voucher-request`:
 
-> {:compact}
->    URI:
->    : urn:ietf:params:xml:ns:yang:ietf-voucher
->
->    Registrant Contact:
->    : The ANIMA WG of the IETF.
->
->    XML:
->    : N/A, the requested URI is an XML namespace.
-
-> {:compact}
->    URI:
->    : urn:ietf:params:xml:ns:yang:ietf-voucher-request
->
->    Registrant Contact:
->    : The ANIMA WG of the IETF.
->
->    XML:
->    : N/A, the requested URI is an XML namespace.
+IANA is requested to update this registration to point to THIS DOCUMENT.
 
 ## The YANG Module Names Registry
 
-IANA is requested to register the following YANG module in the "YANG Module Names" registry {{RFC6020}} {{RFC9890}} within the "YANG Parameters" registry group.
-
-> {:compact}
->   name:
->   : ietf-voucher
->
->   namespace:
->   : urn:ietf:params:xml:ns:yang:ietf-voucher
->
->   prefix:
->   : vch
->
->   reference:
->   : RFC 8366
-
-
-
-> {:compact}
->   name:
->   : ietf-voucher-request
->
->   namespace:
->   : urn:ietf:params:xml:ns:yang:ietf-voucher-request
->
->   prefix:
->   : vcr
->
->   reference:
->   : RFC 8995
-
-(Please note the change to the "prefix" field)
+IANA is requested to update the `ietf-voucher` and `ietf-voucher-request` registrations
+in the "YANG  Module Names" registry {{RFC6020}} {{RFC9890}} within the "YANG Parameters" registry group to point to this document.
+For the `ietf-voucher-request` entry, the prefix should be updated to "vcr".
 
 ## The Media Types Registry {#vcj}
 
-IANA is requested to register the media type: `application/voucher-cms+json`, and this registration should be updated to point to this document.
-
-> {:compact}
->   Type name:
->   : application
->
->   Subtype name:
->   : voucher-cms+json
->
->   Required parameters:
->   : none
->
->   Optional parameters:
->   : none
->
->   Encoding considerations:
->   : CMS-signed JSON vouchers are ASN.1/DER  encoded.
->
->   Security considerations:
->   : See {{sec-con}}
->
->   Interoperability considerations:  The format is designed to be
->      broadly interoperable.
->
->   Published specification:
->   : THISDOCUMENT
->
->   Applications that use this media type:
->   : ANIMA, 6tisch, and NETCONF zero-touch imprinting systems.
->
->   Fragment identifier considerations:
->   : none
->
->   Additional information:
->   : Deprecated alias names for this type:  none
->   : Magic number(s):  None
->   : File extension(s):  .vcj
->   : Macintosh file type code(s):  none
->
->
->   Person and email address to contact for further information:
->   : IETF ANIMA WG
->
->   Intended usage:
->   : LIMITED
->
->   Restrictions on usage:
->   : NONE
->
->   Author:
->   : ANIMA WG
->
->   Change controller:
->   : IETF
->
->   Provisional registration? (standards tree only):
->   : NO
+IANA is requested to update the registration of media type: `application/voucher-cms+json` to change the Published Specification to THIS-DOCUMENT.
 
 ## The SMI Security for S/MIME CMS Content Type Registry {#iana-contenttype}
 
-IANA is requested to register the OID 1.2.840.113549.1.9.16.1.40, '`id-ct-animaJSONVoucher`'.
+IANA is requested to update the registration for the OID 1.2.840.113549.1.9.16.1.40, '`id-ct-animaJSONVoucher`'.
 This registration should be updated to point to this document.
 
 ## The Voucher Extensions Registry {#voucher-ext-reg}
@@ -1233,6 +1129,8 @@ and also the following YANG module:
 RFC-editor, please remove.
 This section just lists references present in YANG modules which otherwise do not get included in the references, like {{!RFC7250}}.
 
+Also {{!RFC9911}}, Common YANG Data Types, and {{RFC8791}} is SX:Structure.
+
 --- back
 
 # Examples

ietf-voucher-request.yang

@@ -73,7 +73,7 @@ module ietf-voucher-request {
     description
      "Updates and additions described by RFC XXXX";
     reference
-     "RFC XXXX: A Voucher Artifact for Bootstrapping Protocols";
+     "RFC XXXX: A Voucher Request Artifact for Bootstrapping Protocols";
   }
 
   revision 2021-05-20 {

ietf-voucher.yang

@@ -68,7 +68,7 @@ module ietf-voucher {
     description
       "Updates and additions described by RFC XXXX";
     reference
-      "RFC XXXX: A Voucher Profile for Bootstrapping Protocols";
+      "RFC XXXX: A Voucher Artifact for Bootstrapping Protocols";
   }
 
   revision 2018-05-09 {