Ballot for draft-ietf-acme-integrations
Discuss
Yes
No Objection
No Record
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
# John Scudder, RTG AD, comments for draft-ietf-acme-integrations-13 CC @jgscudder ## DISCUSS This is an informational document but is using RFC 2119 keywords as though it were standards track. Most of these uses are in Section 8, but there are two in Sections 4 and 5. For example, If the CSR includes an identifier that the EST RA does not control, the RA MUST respond with a 4xx HTTP [RFC9110] error code. That reads as though you are imposing the requirement de novo. I assume that is not correct, and what you're actually doing is describing what the underlying standards track document mandates. If that's the case, here and in other places you use 2119-style requirement keywords, it seems to me that you should reword to make it clear you're describing the consequences of an existing requirement, not creating a new one. On the other hand, if you're creating a new requirement, then shouldn't this be a standards track document? An example of the former approach, with the quoted sentence, might be to reword it like If the CSR includes an identifier that the EST RA does not control, the RA will respond with a 4xx HTTP [RFC9110] error code. I just changed "MUST" to "will", or if you want to be more specific could interpolate something like, If the CSR includes an identifier that the EST RA does not control, an RA that follows the requirements of RFC XXXX Sec YY will respond with a 4xx HTTP [RFC9110] error code. The uses in Section 8 are more difficult for me; not being at all expert in this area I'm unable to reliably tell which if any of the MUSTs (and SHOULDs and so on) you're imposing are actually new requirements. If you think there really are new requirements being imposed here that don't exist in the base document, but that this document really is only informational, please help me understand how to resolve this seeming contradiction. Thanks in advance. (As an aside to the shepherd, I had hoped that item 11 of the shepherd writeup would help me understand how to resolve this question, but sadly the "why is this the proper type of RFC" portion was left unanswered. Maybe the shepherd was also bamboozled.)
## NITS "defintions" -> "definitions" "Using graph theory" -> perhaps, "in the terminology of graph theory" or "to use the terminology of graph theory"? "Roots CAs" -> "Root CAs"? "The EST Registration Authority (RA) is configured with the DNS domain which it will issue certificates." That should be "for which", right? ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
I Support John's discuss points on this one.
# Internet AD comments for draft-ietf-acme-integrations-13 CC @ekline ## Comments ### S4, etc * I guess there's no validation that client.example.com has not been delegated to an entity for which the EST RA does NOT have DNS update abilities.
Thank you for the work on this document. Many thanks to John Levine for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/efQ6-4iasbvkX8lCcXKANlxaq4E/ I would encourage the authors to take a look at John's comments, which provide good input for clarification for non-expert readers.
# GEN AD review of draft-ietf-acme-integrations-13 CC @larseggert Thanks to Tim Evens for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/Sxu_T3P5jpR7uj3s6Pfak2f6Jes). ## Comments ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `traditionally`; alternatives might be `classic`, `classical`, `common`, `conventional`, `customary`, `fixed`, `habitual`, `historic`, `long-established`, `popular`, `prescribed`, `regular`, `rooted`, `time-honored`, `universal`, `widely used`, `widespread` ## Nits 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. ### Typos #### Section 2, paragraph 2 ``` - defintions: + definitions: + + ``` ### Outdated references Document references `draft-ietf-uta-use-san-00`, but `-10` is the latest available revision. ### Grammar/style #### Section 4, paragraph 7 ``` RFC9110] error code. Refer to section Section 8.5 for further details on err ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5, paragraph 1 ``` he /simpleenroll API. Refer to section Section 8.2 for more details. If the C ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 5, paragraph 2 ``` RFC9110] error code. Refer to section Section 8.5 for further details on err ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 8.2, paragraph 2 ``` 5272] response, or may return a human readable error in the response body. If ^^^^^^^^^^^^^^ ``` This word is normally spelled with a hyphen. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool
I support John's DISCUSS, especially as it relates to BCP 14 keywords. Moreover, the shepherd writeup doesn't explain the choice of status for this document, which might be relevant to this.
The document is a good read, and the figures in it make the process very clear. Thanks for that work.
Just some minor comments:
| | Publish DNS TXT | |
| | "example.com" | |
| | Delete DNS TXT | |
| | "example.com" | |
This reads a little as if a TXT record with the content "example.com"
needs to be published and deleted. Maybe use 'Publish ACME DNS challange
in "example.com"' ?
This ownership proof could have been by fulfilling an
authorization challenge against the explicit identifier
"pledge.example.com",
Where does "pledge" come from? Is this a normative reference to something?
If it is made up here, add some "for example" text to clarify this. And
use at least "_pledge" to avoid clashing with potential real hostnames
called pledge ?
NITS:
which it will issue certificates.
s/\.$/ for./
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've been called for jury duty, and so am relying heavily on Bo Wu's OpsDir (https://datatracker.ietf.org/doc/review-ietf-acme-integrations-12-opsdir-lc-wu-2023-01-20/) and Ted Lemon's DNSDIR (https://datatracker.ietf.org/doc/review-ietf-acme-integrations-13-dnsdir-telechat-lemon-2023-03-01/) reviews to help guide me. Thank you very much, Bo and Ted. While Ted does say that "at this point that the concerns I raised have been addressed and the document is ready to go", I'd strongly encourage the authors to reconsider addressing the comments in the first two paragraphs of his review; I think that they would further improve the document...
# Éric Vyncke, INT AD, comments for draft-ietf-acme-integrations-13 CC @evyncke Thank you for the work put into this document. As usual on this topic, I support John Scudder's DISCUSS about the use BCP14 uppercase terms in an informational document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Deb Cooley for the shepherd's detailed write-up including the WG consensus **albeit** it lacks the justification of the intended status. Other thanks to Ted Lemon, the DNS directorate reviewer, please consider this int-dir review as if it was mine: https://datatracker.ietf.org/doc/review-ietf-acme-integrations-13-dnsdir-telechat-lemon-2023-03-01/ (it is dated of yesterday, but I still have to read authors' reply) Please note that Bob Halley is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/reviewrequest/17100/ I hope that this review helps to improve the document, Regards, -éric ## COMMENTS ### Abstract Should the abstract add references to relevant RFC and/or expand the acronyms ? This would help readers to find this document. They are only expanded in section 2. ### Section 1 In this section, please expand EST, BRSKI, and TEAP. `enable automated certificate enrollment for devices` should devices be qualified ? I.e., devices w/o a UI ? ### Section 2 `portion of the graph of all possible domain names` AFAIK the graph of all possible domain names is actually a tree (i.e., a restricted graph). ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments