TNAuthList Profile of Automated Certificate Management Environment (ACME) Authority Token
draft-ietf-acme-authority-token-tnauthlist-13

Nothing useful to add.

Thank you Paul for picking up my DISCUSS.

Francesca

What Warren said.

Thank you to Sean Turner for the ARTART review.

I support Francesca's DISCUSS.

The shepherd writeup appears to be confused with the one for draft-ietf-acme-authority-token.  This one has the abstract for that one, for example.

Thanks for addressing my DISCUSS position.  However, the paragraph containing the new reference to RFC 4686 seems a bit jumbled.  You might want to take another run at it before sending it to the RFC Editor.

The last typo was fixed in -23

I'm balloting No Objection in the "This is outside my area of expertise" / "I read the protocol action, and I trust the sponsoring AD so have no problem" sense of the term.

I fully agree with Eric's "Feel free to ignore but a small ASCII ART / SVG describing the interactions between all components would help the reader to understand the whole process." comment -- I'm assuming that the audience / implementers will be able to parse this document, but I was fairly lost...

I haven't noted any transport related issues. 

I, however, support Murray Kucherawy's discuss.

Thank you for the work put into this document and addressing my blocking DISCUSS comment of November 2021: 
https://mailarchive.ietf.org/arch/msg/acme/wN7QIYzrDfZ1dBj8M5yXLRQAWDU/

Therefore, my DISCUSS ballot is now cleared.

A reply and action on the comments below will be appreciated, this is completely optional of course.

Best regards

-éric

== COMMENTS ==

Feel free to ignore but a small ASCII ART / SVG describing the interactions between all components would help the reader to understand the whole process.

-- Section 3 --
Is "TN" a well-known acronym ? Please expand it at first use (even if I guess that "TN" stands for telephone number).

-- Section 5.4 --
s/which shall be 'SHA256'/which MUST be 'SHA256'/ ?

-- Section 5.7 --
Please expand "SPC", "OCN" on first use. As "SPID" is in https://www.rfc-editor.org/materials/abbrev.expansion.txt, its expansion is not mandatory but would be welcome.

-- Section 6 --
In "then the CA MUST set the challenge object "status" to "valid"", isn't it up to the ACME server to do this action ?

This document uses the RFC2119 keywords "REQUIRED", "SHOULD NOT", "OPTIONAL",
"RECOMMENDED", "MAY", "SHALL", "MUST NOT", "SHOULD", "MUST, and "SHALL NOT",
but does not contain the recommended RFC8174 boilerplate. (It contains a
variant of the RFC2119 boilerplate.)

Thanks to Pete Resnick for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/pvVWaHcMESMTsLWBOgdjocQgi_Y).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5.1. , paragraph 2, nit:
>  "ca" is an optional key, if it not included the "ca" value is considered fa
>                                 ^^^^^^^^^^^^
A verb ("be" or "have") is missing before the past participle.

Section 6. , paragraph 3, nit:
> t of telephone numbers represented by a SPC. The creation, transport, and any
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Document references draft-ietf-stir-cert-delegation, but that has been
published as RFC9060.

Document references draft-ietf-acme-authority-token-05, but -07 is the latest
available revision.

Please expand SP, CSP, and CA on first use.

+1 to Warren's comments.