Re: [stir] [Acme] Authority Token WGLC

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 <debcooley1@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