change abstract and instroduction to explain merging better

draft-ietf-anima-rfc8366bis.md

@@ -123,8 +123,8 @@ The voucher artifact is normally generated by
 the pledge's manufacturer (i.e., the Manufacturer Authorized Signing
 Authority (MASA)).
 
-This document updates RFC8366, merging a number of extensions into the YANG.
-The RFC8995 voucher request is also merged into this document.
+This document updates RFC8366, includes a number of desired extensions into the YANG.
+The voucher request defined in RFC8995 is also now included in this document, as well as other YANG extensions needed for variants of BRSKI/RFC8995.
 
 --- middle
 
@@ -141,22 +141,27 @@ It may also be serialized to CBOR {{CBOR}}.
 It is encoded using the rules defined in {{!RFC7951}}, and
 is signed using (by default) a CMS structure {{RFC5652}}.
 
-The primary purpose of a voucher is to securely convey a
-certificate, the "pinned-domain-cert" (and constrained variations), that a pledge can
-use to authenticate subsequent interactions.
+The primary purpose of a voucher is to securely convey a trust anchor
+that a pledge can use to authenticate subsequent interactions.
+The trust anchor may be in the form of a certificate, the "pinned-domain-cert", a hash of a certificate, or it might be a raw public key (in constrained variations).
 A voucher may be useful in several contexts, but the driving motivation
 herein is to support secure onboarding mechanisms.
 Assigning ownership is important to device onboarding mechanisms so that the pledge
-can authenticate the network that is trying to take control of it.
+can authenticate the network that will control it.
 
-The lifetimes of vouchers may vary. In some onboarding protocols,
-the vouchers may include a nonce restricting them to a single use,
-whereas the vouchers in other onboarding protocols may have an
+{{RFC8366}} originally defined just the voucher artifact, leaving the Voucher Request artifiact that is important to BRSKI to be defined in {{BRSKI}}.
+This document includes both Voucher and Voucher-Request, and therefore updates {{BRSKI}}.
+
+YANG is not easily extended except by updating the YANG definition.
+Since {{RFC8366}} was written, the 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.
+This allows the YANG module to be updated without replacing all of the context.
+This document does not follow that pattern, but future updates are may update only the YANG.
+
+The lifetimes of vouchers may vary.
+In some onboarding protocols, the vouchers may include a nonce restricting them to a single use,  whereas the vouchers in other onboarding protocols may have an
 indicated lifetime.
 In order to support long lifetimes, this document recommends using short lifetimes with programmatic renewal, see {{renewal-over-revocation}}.
 
-This document only defines the voucher artifact, leaving it to other
-documents to describe specialized protocols for accessing it.
 Some onboarding protocols using the voucher artifact defined in
 this document include: {{ZERO-TOUCH}}, {{SECUREJOIN}}, and {{BRSKI}}.
 
@@ -388,8 +393,8 @@ There are some difficulties with this approach: this document does not attempt t
 
 Three signature systems have been defined for vouchers and voucher-requests.
 
-{{!cBRSKI}} defines a mechanism that uses COSE {{RFC9052}}, with the voucher data encoded using {{I-D.ietf-core-sid}}.
-However, as the SID processe requires up-to-date YANG, the SID values for this mechanism are presented in this document.
+{{!cBRSKI}} defines a mechanism that uses COSE {{RFC9052}}, with the voucher data encoded using {{?RFC9254}}.
+However, as the SID process requires up-to-date YANG, the SID values for this mechanism are presented in this document.
 
 {{!jBRSKI}} defines a mechanism that uses JSON {{RFC8259}} and {{JWS}}.