WIP: partial update based upon WGLC review

Author: mcr

draft-ietf-anima-rfc8366bis.md

@@ -303,8 +303,8 @@ Assertion Basis:
   protects the voucher itself). Methods include
   manufacturer-asserted ownership verification, assured
   logging operations, or reliance on Pledge behavior
-  such as secure root of trust
-  of measurement. The join registrar uses this information to make a determination as to whether to accept the Pledge into the network.
+  such as secure or measured boot.
+  The join registrar uses this information to make a determination as to whether to accept the Pledge into the network.
   Only some methods are normatively defined in this
   document. Other methods are left for future work.
 
@@ -356,7 +356,7 @@ Audit Voucher:
   An advantage is that actual ownership knowledge (i.e., sales integration providing an indication of who purchased the device) is not required on the MASA service.
 
 Nonceless Audit Voucher:
-: An Audit Voucher without a validity period statement. Fundamentally,
+: An Audit Voucher with a validity period statement, but no guarantee of freshness. Fundamentally,
   it is the same as an Audit Voucher except that it can be issued in
   advance to support network partitions or to provide a permanent
   voucher for remote deployments.
@@ -459,7 +459,6 @@ signature generated over the content using a private key
 trusted by the recipient.
 Normally, the recipient is the Pledge and the signer is the MASA.
 In the Voucher Request, the signer is the Pledge, or the Registrar.
-Within this document, the signer is assumed to be the MASA.
 
 Note that Section 5.1 of {{RFC5652}} includes a
 discussion about how to validate a CMS object, which is really a
@@ -631,7 +630,7 @@ The processes which were anticipated to be useful, (the "augment" mechanism) tur
 Instead, a process similiar to what was done by {{?RFC8520}} has been adopted.
 In this, extensions are listed in a leaf named "extensions".
 In JSON serialization, these extensions require a unique name, and this MUST be allocated by IANA.
-The name MUST be the same as the YANG module name.
+The name MUST be the same as the YANG extension module name.
 The "extensions" list attribute definied in this model allows for new standard extensions to be defined.
 Items within that list are strings (in JSON serialization), or integers (in CBOR serialization), as defined by the Voucher Extension Registry.
 

ietf-voucher-request-sid.txt

@@ -1,6 +1,5 @@
-           
       SID Assigned to
---------- -------------------------------------------------- 
+--------- --------------------------------------------------
      2501 data /ietf-voucher-request:voucher/voucher
      2502 data /ietf-voucher-request:voucher/voucher/assertion
      2503 data /ietf-voucher-request:voucher/voucher/created-on
@@ -25,4 +24,4 @@
      2522 data /ietf-voucher-request:voucher/expires-on
      2523 data /ietf-voucher-request:voucher/voucher/extensions
      2524 data .../manufacturer-private
-           
+

ietf-voucher-request.yang

@@ -84,10 +84,6 @@ RFCEDITOR: please replace XXXX with the RFC number assigned.
       "Grouping to allow reuse/extensions in future work.";
 
     uses vch:voucher-artifact-grouping {
-      refine "voucher/created-on" {
-        mandatory false;
-      }
-
       refine "voucher/last-renewal-date" {
         description "A last-renewal-date field
                      is not valid in a voucher request, and
@@ -101,7 +97,6 @@ RFCEDITOR: please replace XXXX with the RFC number assigned.
       }
 
       refine "voucher/assertion" {
-        mandatory false;
         description "Any assertion included in registrar voucher
               requests SHOULD be ignored by the MASA.";
       }
@@ -114,7 +109,7 @@ RFCEDITOR: please replace XXXX with the RFC number assigned.
           type binary;
           description
            "If it is necessary to change a voucher, or re-sign and
-            forward a voucher that was previously provided along a
+            forward a voucher request that was previously provided along a
             protocol path, then the previously signed voucher SHOULD
             be included in this field.
 
@@ -127,17 +122,16 @@ RFCEDITOR: please replace XXXX with the RFC number assigned.
 
             The Registrar and MASA MAY examine the prior signed
             voucher information for the
-            purposes of policy decisions. For example this
-            information could be useful to a MASA to determine
-            that both pledge and registrar agree on proximity
-            assertions. The MASA SHOULD remove all
+            purposes of policy decisions. The MASA SHOULD remove all
             prior-signed-voucher-request information when
             signing a voucher for imprinting so as to minimize
             the final voucher size.";
         }
 
         choice registrar-identity {
-          description "One of these three attributes will be used to pin the registrar identity";
+          description "One of these attributes will be used by a
+                       Pledge to specify the proximity to, and the
+                       identity of, a Registrar it is communicating with"
           leaf proximity-registrar-cert {
             type binary;
             description

ietf-voucher.yang

@@ -74,7 +74,7 @@ RFCEDITOR: please replace XXXX with the RFC number assigned.
     container voucher {
       description
         "A voucher assigns a pledge to an owner using
-         the (pinned-domain-cert) value.";
+         one of the (pinned-domain-*) value.";
 
       leaf created-on {
         type yang:date-and-time;
@@ -179,9 +179,8 @@ RFCEDITOR: please replace XXXX with the RFC number assigned.
            otherwise unique within the scope of the MASA.";
       }
       choice pinning {
-        description "One of these attributes is used by the pledge to
-                     specify the registrar, and how the pledge would like
-                     the registrar's identity to be pinned";
+        description "One of these attributes is used by the
+                     MASA to pin the registrar identity";
         leaf pinned-domain-cert {
           type binary;
           description