Subject: [Acme] Barry Leiba's No Objection on draft-ietf-acme-ip-06: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Thu, 26 Sep 2019 15:23:32 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-acme-ip-06: No Objection

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-ip/

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

I have only editorial comments below.  No response is needed — please just
consider incorporating these, as I think they’ll help make the document clearer.

— Introduction —

   The Automatic Certificate Management Environment (ACME) [RFC8555]
   only defines challenges for validating control of DNS host name
   identifiers which limits its use to being used for issuing
   certificates for DNS identifiers.

This needs a comma before “which”.

— Section 2 —
Please use the new BCP 14 boilerplate and references (see RFC 8174).

— Section 3 —

   [RFC8555] only defines the identifier type "dns" which is used to
   refer to fully qualified domain names.

Similarly: needs a comma before “which”.

— Section 4 —

   IP identifiers MAY be used with the existing "http-01" and "tls-alpn-
   01" challenges from [RFC8555] Section 8.3 and
   [I-D.ietf-acme-tls-alpn] Section 3 respectively.

This is OK as it is, so take this or leave it as you will, but to my eyes the
citations are needlessly separated from their anchors.  I would re-order it
this way:

NEW
   IP identifiers MAY be used with the existing challenges
   "http-01" (see Section 8.3 of [RFC8555]) and "tls-alpn-01"
   (see Section 3 of [I-D.ietf-acme-tls-alpn]).
END

— Section 5 —

   The textual form of
   this address MUST be those defined in [RFC1123] Section 2.1 for IPv4
   and in [RFC5952] Section 4 for IPv6.

The subject is singular, so “those” doesn’t work.  An easy fix is to use “as
defined”.

— Section 6 —

   For the "tls-alpn-01" challenge the subjectAltName extension in the
   validation certificate MUST contain a single iPAddress which matches
   the address being validated.

This needs “which” changed to “that”, to make it a restrictive clause.