[Acme] Lars Eggert's Discuss on draft-ietf-acme-star-delegation-07: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-acme-star-delegation-07: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-star-delegation/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5.1, paragraph 4, discuss:
>    This document requests that IANA create the following new registry
>    under the Automated Certificate Management Environment (ACME)
>    Protocol:
>
>    *  ACME Identifier Object Fields
>
>    This registry is administered under a Specification Required policy
>    [RFC8126].

RFC8126 strongly suggests that guidance needs to be given to expert reviewers
that are supposed to review and approve requests for "Expert Review" and
"Specification Required" registries. This guidance is missing here. What's also
missing are designated contact persons and a change controller.

Section 5.6, paragraph 2, discuss:
> 5.6.  CSR Template Extensions
>
>    IANA is requested to establish a registry "STAR Delegation CSR
>    Template Extensions", with "Expert Review" as its registration
>    procedure.

Same as above.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1, paragraph 8, comment:
>    We note that other ongoing efforts address the problem of certificate
>    delegation for TLS connections, specifically [I-D.ietf-tls-subcerts]
>    and [I-D.mglt-lurk-tls13].  Compared to these other solutions, the
>    current document does not introduce additional latency to the TLS
>    connection, nor does it require changes to the TLS network stack of
>    either the client or the server.

This paragraph should probably be removed upon publication as an RFC?

-------------------------------------------------------------------------------
All comments below are very minor change suggestions that you may choose to
incorporate in some way (or ignore), as you see fit. There is no need to let me
know what you did with these suggestions.

Section 3.1, paragraph 10, nit:
-    e.g. by restricting field lengths.  In this regard, note that a
+    e.g., by restricting field lengths.  In this regard, note that a
+        +

Section 4.1, paragraph 3, nit:
-    This section uses specifically CDNI terminology, e.g. "uCDN" and
+    This section uses specifically CDNI terminology, e.g., "uCDN" and
+                                                         +

Section 4.1.2.1, paragraph 5, nit:
-    Unlike HTTP based redirection, where the original URL is supplanted
-               ^
+    Unlike HTTP-based redirection, where the original URL is supplanted
+               ^