Automated Certificate Management Environment (ACME) for Subdomains
draft-ietf-acme-subdomains-07

# Internet AD comments for draft-ietf-acme-subdomains-06
CC @ekline

## Comments

### S4.3

* At the end of this section discussion switches from "ancestorDomain" to
  "parentDomain".  I think this makes sense in the context of the 2nd
  example (foo.bar.example.org and {bar.,}example.org) where the parent
  domain is not necessarily the same as the ancestor domain. Nevertheless,
  some text highlighting the distinction between ancestor and parent domains
  might be helpful.  (Or just describe it in the context of the example;
  I assume bar.example.org is the parent in the case where example.org is
  the ancestor?)

Thank you for the work on this document.

Many thanks to Carsten Bormann for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/dk8yWKSWxxvVu0CfpuDFzaEVNYA/, and to the authors for addressing Carsten's comments.

Thanks for this clearly written document. I noticed one nit, “indiciated” should be “indicated”.

I support Paul Wouters' DISCUSS points.

I'd like to thank the authors for this document -- as a user of Acme, I'm always happy to see enhancements, etc.
I'd also like to thank Bo Wu for the thoughtful and detailed OpsDir review, and the authors for opening issues, working through them and then closing these.

# GEN AD review of draft-ietf-acme-subdomains-06

CC @larseggert

Thanks to Theresa Enghardt for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/ZBP6EEClZDyPV5IPFb3tTZWKjC8).

## 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 4.3, paragraph 11
```
-    indiciated identifier, there is no need for the server to include the
-         -
```

### Grammar/style

#### Section 5, paragraph 23
```
ecurity Considerations This document documents enhancements to ACME [RFC8555]
                            ^^^^^^^^^^^^^^^^^^
```
You repeated a verb. Please check.

## 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

Hi,

Thanks for this document.

One minor nit on the definition of subdomain and ancestor domain:

Subdomain has been clarified in this document to remove the ambiguity of whether a given domain is a subdomain of itself.

However, looking at the definition of ancestor domain:

   *  Ancestor Domain: a domain is an ancestor domain of a subdomain if
      it contains that subdomain, as per the [RFC8499] definition of
      subdomain.  For example, for the host name "nnn.mmm.example.com",
      both "mmm.example.com" and "example.com" are ancestor domains of
      "nnn.mmm.example.com".  Note that the comparisons here are done on
      whole labels; that is, "oo.example.com" is not an ancestor domain
      of "ooo.example.com"

It specifically references the RFC8499 definition of subdomain rather than the one clarified in the document, raising the question whether a domain is also an ancestor of itself, and whether that ambiguity is intentional for some reason.  Hence, I would propose that the definition of ancestor domain is tied back to the definition of subdomain in this document rather than RFC8499.

Regards,
Rob