[email protected] wrote: > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-anima-constrained-voucher-15.html
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-voucher-15
This version is the result of a lot of work and pull requests.
Here is my attempt to capture a high-level view.... the diff is worth
reading. A list of pull requests that went into this document is at:
https://github.com/anima-wg/constrained-voucher/pulls?q=is%3Apr+created%3A%3E2021-08-01
We mostly think we are done. We'd appreciate some additional review of the
document.
We think that WGLC in January might be appropriate.
We expect to do additional online interop testing.
We have cancelled the Thursday "morning" design team meetings until Jan, but
likely we'll continue to edit and merge some pull requests. Your review
would help. We have dealt with all review comments that we have received.
1) rewrote abstract
new abstract proposal
https://github.com/anima-wg/constrained-voucher/pull/198
2) We added Appendix D about different kinds of pledges that we think can be
created. They differ in host many network round trips are required, and
how much code (mostly PKIX code) is required.
We also are considering a section:
https://github.com/anima-wg/constrained-voucher/pull/202
that goes more into the no-PKIX operational consideration, but we have not
yet decided to include it.
It seems that we could make this a new document if the WG preferred.
I think as a group, the authors are undecided.
3) We have a section 14.2, which was about IDevID security, and we think that
actually there isn't anything to say, and we'll remove this section.
4) Many editorial fixes, many updates to make the IANA sections correct.
5) Clarified that constrained vouchers can be sent over HTTPS.
(Also that non-constrained-vouchers could travel over CoAP, but we
think that is a stupid thing to do)
6) section added on consequences of no certificate operations #202
7) one reviewer challenged our claims about code size reduction.
We have agreed and decided to remove that claim from the text where it was
really about network transmission savings.
8) we have added some text about discovery and applicability in different
deployment scenarios (section 10)
9) add text explaining when to look for new trust anchor CA via /crts #186
10) clarify that the Registrar certificate can be self-signed #181
11) clarification of RFC4210 Root CA key change, close #163 issue-for-wg
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
