Hi Sean, Thanks, i have incorporated the text changes you suggested into new release of the tnauthlist document that incorporates Richard’s suggestions as well.
-Chris > On Sep 6, 2022, at 10:40 PM, Sean Turner <[email protected]> wrote: > > 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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
