Hi! I had a read of these two I-Ds. Comments follow:
# -authority-token tl;dr: editorial and nits 0) s8: I-D Nits complains about "Authority Tokens SHOULD not”. So s/SHOULD not/SHOULD NOT 1) s9.1: I-D Nits complains about dancing references to RFCs 3986 and 4648. I guess you could work them in, but if not then just drop them. 2) s3: Expand CAs on first use: s/CAs/Certification Authorities (CAs) 3) s3.1: Consider adding a reference to 8126, where Specification Required is defined: s/The IANA will maintain a registry of tkauth-types under a policy of Specification Required./The IANA will maintain a registry of tkauth-types under a policy of Specification Required [RFC8126]. 4) s3.1: Wording tweak - requirements just kind of hangs there: s/In order to register a new tkauth-type, specifications must address the following requirements; in cases where a tkauth-type admits of its own subtypes, subtypes inherit these requirements./s/In order to register a new tkauth-type, specifications must address the requirements in this section; in cases where a tkauth-type admits of its own subtypes, subtypes inherit these requirements. 5) s.3.1: 2119 it: s/Therefore, in defining tkauth-types, future specifications must indicate/Therefore, in defining tkauth-types, future specifications MUST indicate 6) s8: 2119 it: s/ … HTTPS REST client and the Token Authority must also exist … /… HTTPS REST client and the Token Authority MUST also exist … s/Implementations should follow the best practices identified in [RFC8725]. /Implementations SHOULD follow the best practices identified in [RFC8725]. 7) s8: dangling ) s/Section 4)./Section 4. 8) s8: algorithms for keys: s/permit other keys/permit other algorithms s/define new keys/define new algorithms # -authority-token-tnnauthlist (note I also did the ARTART review) tl;dr: looks like -09 fixed my ARTART review comments and now I have but one new nit: 1) algorithms for keys: s/permit other keys/permit other algorithms s/define new keys/define new algorithms Cheers, spt > On Aug 23, 2022, at 15:58, Deb Cooley <debcool...@gmail.com> wrote: > > As we agreed at the acme session at IETF 114, this is a limited WGLC for both: > > https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/ > https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-tnauthlist/ > > I've added stir to the to line for good measure (and to broaden the pool of > reviewers a bit). We need to see if we can push these forward again. > > The review deadline is 6 Sep 2022. > > Deb Cooley > acme co-chair > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
