[Acme] John Scudder's Discuss on draft-ietf-acme-integrations-13: (with DISCUSS and COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Wed, 01 March 2023 22:10 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: acme@ietf.org
Delivered-To: acme@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 766FBC14F749; Wed, 1 Mar 2023 14:10:28 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-acme-integrations@ietf.org, acme-chairs@ietf.org, acme@ietf.org, decoole@radium.ncsc.mil, decoole@radium.ncsc.mil
X-Test-IDTracker: no
X-IETF-IDTracker: 9.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <167770862847.43522.7262152395383498024@ietfa.amsl.com>
Date: Wed, 01 Mar 2023 14:10:28 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/89pCY_PTA5hJT21f0b3CXQUpP70>
Subject: [Acme] John Scudder's Discuss on draft-ietf-acme-integrations-13: (with DISCUSS and COMMENT)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Mar 2023 22:10:28 -0000
John Scudder has entered the following ballot position for draft-ietf-acme-integrations-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-integrations/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # 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.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## 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
- [Acme] John Scudder's Discuss on draft-ietf-acme-… John Scudder via Datatracker
- Re: [Acme] John Scudder's Discuss on draft-ietf-a… Michael Richardson