DHCPv6 Options for Home Network Naming Authority
draft-ietf-homenet-naming-architecture-dhc-options-24

This document was put on hold until draft-ietf-homenet-front-end-naming-delegation was approved by the IESG. The downref to draft-ietf-homenet-front-end-naming-delegation was also approved by the IESG during the IESG telechat of 2023-01-26.

# Document Shepherd Writeup

*This version is dated 16 January 2023. Only change is to intended status.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

# Document Shepherd Writeup

*This version is dated 16 January 2023. Only change is to intended status.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Experimental. (Following IETF LC and IEST discussion.)

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

[Ballot comment]
My DISCUSS was resolved. There is AXFR using mutual TLS.

OLD DISCUSS:

This might be my misunderstanding of homenet, so hopefully easy to resolve.

The HNA (hidden primary?) to DM (primary) DNS communication using DNS Update needs some kind of authentication, TSIG or SIG0 ? While TLS gives you privacy, the DNS Update cannot be done with only TLS (as far as I understand it). I don't see any DHCP options to relay authentication information for automatic deployment? So I don't understand how this would startup and be able to setup a secure DNS update channel ?

There was also talk about using ACME for TLS certificates, but wouldn't that require that the HNA already has a provisioned and working homenet domain ? (possibly more a question for the other draft, but just adding it here in case the hidden primary to primary is an "almost DNS Update" protocol that uses TLS instead f TSIG/SIG0.

[Ballot comment]
# GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY).

## Comments

I still think it is shortsighted to not include port numbers in the
Supported Transport field, but the current text at least makes it clear
that out-of-band agreement is needed because of this limitation.

### IANA

The IANA review of this document seems to not have concluded yet.

### 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 `her`; alternatives might be `they`, `them`, `their`

## 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 3
```
-    to.  ISPs may leverage such infrastructure and provide the homenet
+    to.  ISPs may leverage such infrastructure and provide the home network
+                                                                  +  ++++
```

### Outdated references

Document references `draft-sury-dnsext-cname-dname-00`, but `-01` is the latest
available revision.

### Grammar/style

#### Paragraph 1
```
s document defines DHCPv6 options so an Homenet Naming Authority (HNA) can a
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 3, paragraph 4
```
6 options provide the necessary non optional parameters described in Appendi
                                ^^^^^^^^^^^^
```
This expression is usually spelled with a hyphen.

#### Section 4.3, paragraph 2
```
represents a supported transport, and a RDM MAY indicate the support of multi
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.3, paragraph 6
```
FC8415] govern server operation in regards to option assignment. As a conveni
                                ^^^^^^^^^^^^^
```
Use "in regard to", "with regard to", or more simply "regarding".

#### "A.3.", paragraph 4
```
cribed in Appendix A.2, the HNA is expect to be able to handle multiple Home
                                  ^^^^^^
```
Consider using either the past participle "expected" or the present participle
"expecting" here.

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

[Ballot comment]
Thanks for working on this document. I am supporting Lars's discuss to clarify the implication of a non standard port usage.

I also think this paragraph

  It is worth noticing that the Supported Transport field does not enable to specify a port and the used port is defined by a standard. In the case of DNS over TLS [RFC7858], the port is defined by [RFC7858] to be 853. The need for such flexibility has been balanced with the difficulty of handling a list of tuples ( transport, port ) as well as the possibility to use a dedicated IP address for the DM.

should be moved to section 4.4 if this consideration is also true for section 4.3.

[Ballot discuss]
# GEN AD review of draft-ietf-homenet-naming-architecture-dhc-options-22

CC @larseggert

Thanks to Maria Ines Robles for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/uld2ipgAwbN-LgVg9X1VjFAPUYY).

## Discuss

### Section 4.2, paragraph 8
```
    It is worth noticing that the Supported Transport field does not
    enable to specify a port and the used port is defined by a standard.
    In the case of DNS over TLS [RFC7858], the port is defined by
    [RFC7858] to be 853.  The need for such flexibility has been balanced
    with the difficulty of handling a list of tuples ( transport, port )
    as well as the possibility to use a dedicated IP address for the DM.
```
7858 actually says

  By default, a DNS server that supports DNS over TLS MUST listen for
  and accept TCP connections on port 853, unless it has mutual
  agreement with its clients to use a port other than 853 for DNS over
  TLS.

So it is fully permissible for a DoT server to run on a different port under
such a mutual agreement. In general, for other possible transports, just because
a port is assigned for use does not mean a deployment is obligated to run on it.

[Ballot comment]
## Comments

### IANA

The IANA review of this document seems to not have concluded yet.

### 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 `her`; alternatives might be `they`, `them`, `their`

## 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 3
```
-    to.  ISPs may leverage such infrastructure and provide the homenet
+    to.  ISPs may leverage such infrastructure and provide the home network
+                                                                  +  ++++
```

### Outdated references

Document references `draft-sury-dnsext-cname-dname-00`, but `-01` is the latest
available revision.

### Grammar/style

#### Paragraph 1
```
s document defines DHCPv6 options so an Homenet Naming Authority (HNA) can a
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 3, paragraph 4
```
6 options provide the necessary non optional parameters described in Appendi
                                ^^^^^^^^^^^^
```
This expression is usually spelled with a hyphen.

#### Section 4.3, paragraph 2
```
represents a supported transport, and a RDM MAY indicate the support of multi
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

#### Section 4.3, paragraph 6
```
FC8415] govern server operation in regards to option assignment. As a conveni
                                ^^^^^^^^^^^^^
```
Use "in regard to", "with regard to", or more simply "regarding".

#### "A.3.", paragraph 4
```
cribed in Appendix A.2, the HNA is expect to be able to handle multiple Home
                                  ^^^^^^
```
Consider using either the past participle "expected" or the present participle
"expecting" here.

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

[Ballot comment]
I agree with the Discusses and Comments on this document - this simply isn't implementable as described.

My main reason for abstaining is something else though. This document has been worked on for almost ten years. While in the beginning, we might have expected or at least hoped that a solution in the shape that this document tries to describe would see adoption, it's become very clear that dynamic DNS services as described in Section 4 have won out here. These services are far from perfect, but at least some of the limitations in Section 4 have been addressed, and others are arguably a feature and not a limitation.

[Ballot comment]
# Internet AD comments for {draft-ietf-homenet-naming-architecture-dhc-options-22}
CC @ekline

## Comments

* I wonder if it's possible to include some mention that when a prefix
  (IA_PD) is changed and the OPTION_REVERSE_DIST_MANAGER has changed (perhaps
  because a region is being split into smaller units and the infrastructure
  is shifting) that the OPTION_REVERSE_DIST_MANAGER option SHOULD be sent
  along with the new IA_PD.

[Ballot discuss]
# Internet AD comments for {draft-ietf-homenet-naming-architecture-dhc-options-22}
CC @ekline

## Discuss

* I'll go one further than John and just hold a DISCUSS until DISCUSSes on
  I-D.ietf-homenet-front-end-naming-delegation are all cleared.

[Ballot discuss]
This might be my misunderstanding of homenet, so hopefully easy to resolve.

The HNA (hidden primary?) to DM (primary) DNS communication using DNS Update needs some kind of authentication, TSIG or SIG0 ? While TLS gives you privacy, the DNS Update cannot be done with only TLS (as far as I understand it). I don't see any DHCP options to relay authentication information for automatic deployment? So I don't understand how this would startup and be able to setup a secure DNS update channel ?

There was also talk about using ACME for TLS certificates, but wouldn't that require that the HNA already has a provisioned and working homenet domain ? (possibly more a question for the other draft, but just adding it here in case the hidden primary to primary is an "almost DNS Update" protocol that uses TLS instead f TSIG/SIG0.

[Ballot comment]
Thank you to Hilarie Orman for the SECDIR review.  This review has a list of actionable comments the authors should consider.  In particular, see the feedback on the framing of the Security Considerations language.

** Section 2.
  In addition, ISPs often identify the line of the home network with a
  name. 

Is the referenced “line” here talking about the physical cable?  Should this language generalized to capture fixed wireless technology?

** Section 2.

  Such name is used for their internal network management
  operations and is not a name the home network owner has registered
  to. 

Could this be rephrased to explain the idea of a name “that the home network owner hasn’t registered.”

** Section 3.

Note also that this is not
  mandatory and the DHCPv6 client may instruct remotely the HNA and the
  DHCPv6 either with a proprietary protocol or a protocol that will be
  defined in the future.

I had trouble parsing this sentence.  What is the proprietary protocol related to DHCPv6?

** Section 3.

  This scenario is believed to be the most popular scenario

Is this statement based on deployment experience or speculative about how deployments will be configured?  If the latter, this text should likely read: “This scenario is believe to be the most popular scenario”?

** Section 3.  The steps in the scenario are numbered 1, 2, 1.  Is that an error?  Maybe, 1, 2, 3.

** Section 3.
The HNA is authenticated (see Section 4.6 of
      [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the
      RDM. 

As pointed out in the draft-ietf-homenet-front-end-naming-delegation ballot, this authentication is not mandatory.

** Section 4.2.  Editorial.  Sentence doesn’t parse.

OLD
  It is worth noticing that the Supported Transport field does not
  enable to specify a port and the used port is defined by standard.
  In the case of DNS over TLS [RFC7858], the port is defined by
  [RFC7858] to be 853. 

NEW
Note that the Supported Transport field does not enable the specification of a port. The default port for the protocol identified by the Supported Transport field is assumed.  In the case of DNS over TLS [RFC7858], the default port is 853 [RFC7858].

[Ballot comment]
# John Scudder, RTG AD comments for draft-ietf-homenet-naming-architecture-dhc-options-21

CC @jgscudder

## COMMENTS

Thanks for your work on this document. I had difficulty making sense out of some parts of it, but mostly with explanatory text and not with the normative parts, so I'm content to let these be comments and not part of my DISCUSS. I hope they help.

### Section 3

~~~
  Note also that this is not
  mandatory and the DHCPv6 client may instruct remotely the HNA and the
  DHCPv6 either with a proprietary protocol or a protocol that will be
  defined in the future.
~~~

This didn't scan right for me, for several reasons. First, a "protocol that will be defined in the future" could easily enough be a proprietary one, so the two things aren't actually non-overlapping -- maybe you meant "a protocol that will be standardized in the future" or something. But really, I think if you want to say the protocol to do this is beyond the scope of this document, you should say exactly that, and no more (no need to go into guessing about whether it will be proprietary or not).

But after I started writing this comment, I realized I have a bigger problem with the quoted text, which is I don't actually know what it means. :-( What does it mean for the DHCPv6 client to "instruct remotely the DHCPv6"? AFAICT "DHCPv6" is either an adjective (as when applied to "client" or "server") or it's a noun that names the abstract entity which is the DHCPv6 protocol. But the client isn't instructing the abstract protocol definition, and it's not instructing an adjective either. So I'm just confused. Maybe the words "and the DHCPv6" just need to be removed??

I think this needs a rewrite.

### Section 3

Continuing immediately after the previous, we have

~~~
  In addition, this section assumes the
  responsible entity for the DHCPv6 server is configured with the DM
  and RDM.
~~~

By any chance did you mean "colocated" where you wrote "configured"? If not, then I don't understand what you're getting at here.

### Section 3

And again continuing on, we have

~~~
  This means a Registered Homenet Domain can be associated to
  the DHCPv6 client.
~~~

I think you probably mean "associated with" and aren't using "associated to" in some technical way? If so I would say to use the more idiomatic "associated with" (and the same in your later use of "associated to" in Section 4.1)... except maybe "identified with" might be more accurate here, in the sense of there existing a 1:1 mapping between a Registered Homenet Domain and the DHCPv6 client?

### Section 3

~~~
  2.  The DHCPv6 server responds to the HNA with the requested DHCPv6
      options based on the identified homenet.  The DHCPv6 client
      passes the information to the HNA.
~~~

Wouldn't it be more accurate to say "... responds to the DHCPv6 client with the requested ..."? I get the point (I think) but as written it doesn't follow cleanly.

### Section 3

Later in the section we have

~~~
  1.  The HNA is authenticated (see Section 4.6 of
      [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the
      RDM.  The HNA builds the Homenet Zone (or the Homenet Reverse
      Zone) and proceed as described in
      [I-D.ietf-homenet-front-end-naming-delegation].  The DHCPv6
      options provide the necessary non optional parameters described
      in Appendix B of [I-D.ietf-homenet-front-end-naming-delegation].
      The HNA may complement the configurations with additional
      parameters via means not yet defined.  Appendix B of
      [I-D.ietf-homenet-front-end-naming-delegation] describes such
      parameters that MAY take some specific non default value.
~~~

(As an aside, this is the third item in the list but is numbered 1, I guess a glitch in the document source.)

The final sentence has an RFC 2119 "MAY", this seems out of place since you're describing a requirement imposed in a different specification, not imposing the requirement yourself. I think you should use the common lower-case "may" here, or "can", or similar. Or you could say "... describes optional parameters that can take some..."

Also a question, are the "means not yet defined" going to be additional DHCPv6 options? If so, maybe say that specifically? Or are you intentionally leaving it completely open?

### Section 4.1

As mentioned earlier, I suggest the more idiomatic "associated with" rather than "associated to".

### Section 4.2

I don't understand this text:

~~~
  Then the FQDN can reasonably be seen as a more stable identifier as
  well as a pointer to additional information than the IP addresses may
  be useful to in the future to establish the communication between the
  HNA and the DM.
~~~

I can take some guesses, but I can't unambiguously parse it. I think it needs a rewrite for grammar and clarity. (Or remove, if you don't feel it's needed -- I can't tell.)

### Section 4.4

Please be explicit about bit positions -- are you counting from the left, or right? Please also update Section 6 with this information.

### Section 5.2

I'm not a DHCPv6 (or DHCP) expert so please help me out -- am I correct that there's no concept of a lease that applies to the options defined in this document? 

My concern comes from musing about whether there's a need to talk about what must happen if a client retrieves a set of parameters, does things based on them, later retrieves the parameters again and the new ones don't match the old ones. If the parameters were subject to lease expiration, this would be an expected part of the lifecycle of the protocol and would probably merit discussion. But, if they aren't subject to expiration, then I think it's OK as it stands.

## NITS

### Appendix B

It looks like this should really be A.1, not a new major heading/appendix of its own, probably a glitch in your document source?

### Appendix B.2

Where you say "CE router" do you really mean "CPE router"?

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

[Ballot discuss]
I have one blocking DISCUSS point, which should be easily taken care of -- it seems like [I-D.ietf-homenet-front-end-naming-delegation] needs to be Normative, not Informative.  (For one thing, Section 1 tells us that "The reader should be familiar with [I-D.ietf-homenet-front-end-naming-delegation]".)

[Ballot comment]
# John Scudder, RTG AD comments for draft-ietf-homenet-naming-architecture-dhc-options-21
CC @jgscudder

## COMMENTS

Thanks for your work on this document. I had difficulty making sense out of some parts of it, but mostly with explanatory text and not with the normative parts, so I'm content to let these be comments and not part of my DISCUSS. I hope they help.

### Section 3

~~~
  Note also that this is not
  mandatory and the DHCPv6 client may instruct remotely the HNA and the
  DHCPv6 either with a proprietary protocol or a protocol that will be
  defined in the future.
~~~

This didn't scan right for me, for several reasons. First, a "protocol that will be defined in the future" could easily enough be a proprietary one, so the two things aren't actually non-overlapping -- maybe you meant "a protocol that will be standardized in the future" or something. But really, I think if you want to say the protocol to do this is beyond the scope of this document, you should say exactly that, and no more (no need to go into guessing about whether it will be proprietary or not).

But after I started writing this comment, I realized I have a bigger problem with the quoted text, which is I don't actually know what it means. :-( What does it mean for the DHCPv6 client to "instruct remotely the DHCPv6"? AFAICT "DHCPv6" is either an adjective (as when applied to "client" or "server") or it's a noun that names the abstract entity which is the DHCPv6 protocol. But the client isn't instructing the abstract protocol definition, and it's not instructing an adjective either. So I'm just confused. Maybe the words "and the DHCPv6" just need to be removed??

I think this needs a rewrite.

### Section 3

Continuing immediately after the previous, we have

~~~
  In addition, this section assumes the
  responsible entity for the DHCPv6 server is configured with the DM
  and RDM.
~~~

By any chance did you mean "colocated" where you wrote "configured"? If not, then I don't understand what you're getting at here.

### Section 3

And again continuing on, we have

~~~
  This means a Registered Homenet Domain can be associated to
  the DHCPv6 client.
~~~

I think you probably mean "associated with" and aren't using "associated to" in some technical way? If so I would say to use the more idiomatic "associated with" (and the same in your later use of "associated to" in Section 4.1)... except maybe "identified with" might be more accurate here, in the sense of there existing a 1:1 mapping between a Registered Homenet Domain and the DHCPv6 client?

### Section 3

~~~
  2.  The DHCPv6 server responds to the HNA with the requested DHCPv6
      options based on the identified homenet.  The DHCPv6 client
      passes the information to the HNA.
~~~

Wouldn't it be more accurate to say "... responds to the DHCPv6 client with the requested ..."? I get the point (I think) but as written it doesn't follow cleanly.

### Section 3

Later in the section we have

~~~
  1.  The HNA is authenticated (see Section 4.6 of
      [I-D.ietf-homenet-front-end-naming-delegation]) by the DM and the
      RDM.  The HNA builds the Homenet Zone (or the Homenet Reverse
      Zone) and proceed as described in
      [I-D.ietf-homenet-front-end-naming-delegation].  The DHCPv6
      options provide the necessary non optional parameters described
      in Appendix B of [I-D.ietf-homenet-front-end-naming-delegation].
      The HNA may complement the configurations with additional
      parameters via means not yet defined.  Appendix B of
      [I-D.ietf-homenet-front-end-naming-delegation] describes such
      parameters that MAY take some specific non default value.
~~~

(As an aside, this is the third item in the list but is numbered 1, I guess a glitch in the document source.)

The final sentence has an RFC 2119 "MAY", this seems out of place since you're describing a requirement imposed in a different specification, not imposing the requirement yourself. I think you should use the common lower-case "may" here, or "can", or similar. Or you could say "... describes optional parameters that can take some..."

Also a question, are the "means not yet defined" going to be additional DHCPv6 options? If so, maybe say that specifically? Or are you intentionally leaving it completely open?

### Section 4.1

As mentioned earlier, I suggest the more idiomatic "associated with" rather than "associated to".

### Section 4.2

I don't understand this text:

~~~
  Then the FQDN can reasonably be seen as a more stable identifier as
  well as a pointer to additional information than the IP addresses may
  be useful to in the future to establish the communication between the
  HNA and the DM.
~~~

I can take some guesses, but I can't unambiguously parse it. I think it needs a rewrite for grammar and clarity. (Or remove, if you don't feel it's needed -- I can't tell.)

### Section 4.4

Please be explicit about bit positions -- are you counting from the left, or right? Please also update Section 6 with this information.

### Section 5.2

I'm not a DHCPv6 (or DHCP) expert so please help me out -- am I correct that there's no concept of a lease that applies to the options defined in this document? 

My concern comes from musing about whether there's a need to talk about what must happen if a client retrieves a set of parameters, does things based on them, later retrieves the parameters again and the new ones don't match the old ones. If the parameters were subject to lease expiration, this would be an expected part of the lifecycle of the protocol and would probably merit discussion. But, if they aren't subject to expiration, then I think it's OK as it stands.

## NITS

### Appendix B

It looks like this should really be A.1, not a new major heading/appendix of its own, probably a glitch in your document source?

### Appendix B.2

Where you say "CE router" do you really mean "CPE router"?

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-homenet-naming-architecture-dhc-options-20. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Option Codes registry on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

three new option codes will be registered as follows:

Value: [ TBD-at-Registration ]
Description: OPTION_REGISTERED_DOMAIN
Client ORO: Yes
Singleton Option: No
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_FORWARD_DIST_MANAGER
Client ORO: Yes
Singleton Option: Yes
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: OPTION_REVERSE_DIST_MANAGER
Client ORO: Yes
Singleton Option: Yes
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, a new registry is to be created called the Supported Transport parameter registry.

NOTE: In accordance with current practice, IANA prefers to leave the string "Parameters" out of the name of a new registry grouping, unless doing so will cause confusion. Please let us know if there will be any issues with using the term "Supported Transport" instead of "Supported Transport Parameters."

The new registry will be located on the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry page located at:

https://www.iana.org/assignments/dhcpv6-parameters/

The description for the new registry will be:

"The Supported Transport field of the DHCPv6 option is a two byte field that indicates the supported transport protocols. Each bit represents a specific transport mechanism."

The registration policy for the new registry is RFC Required as defined in RFC 8126. There is an initial registration in the new registry as follows:

Bit Position | Transport Protocol Description | Mnemonic | Reference
-------------+--------------------------------+-----------+--------------
0 | DNS over TLS | DoT | [ RFC-to-be ]
1-15 | unallocated | - | -

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-10-04):

From: The IESG
To: IETF-Announce
CC: draft-ietf-homenet-naming-architecture-dhc-options@ietf.org, evyncke@cisco.com, homenet-chairs@ietf.org, homenet@ietf.org, stephen.farrell@cs.tcd.ie
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (DHCPv6 Options for Home Network Naming Authority) to Proposed Standard


The IESG has received a request from the Home Networking WG (homenet) to
consider the following document: - 'DHCPv6 Options for Home Network Naming
Authority'
  as Proposed
  Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines DHCPv6 options so an Homenet Naming Authority
  (HNA) can automatically proceed to the appropriate configuration and
  outsource the authoritative naming service for the home network.  In
  most cases, the outsourcing mechanism is transparent for the end
  user.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/



No IPR declarations have been submitted directly on this I-D.

Stephen, as the doc shepherd, can you check whether Tomek still agrees to be listed as author ? Can you also justify the intended status of "PS" ? The IANA section should also mention the expert review required by https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2
;-)
Thank you
-éric

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.

# Document Shepherd Writeup

*This version is dated 8 April 2022.*

The most important thing to note about these drafts (this one and its
companion) is that they are the last items for the homenet WG - the WG has been
moribund for some time but the authors and AD are keen to get these drafts
published, for the record and so they could be a basis for further work and
possible deployment. While the activity level of the WG is such that one can't
claim a broad consensus, over the years this work has been in progress, the
drafts have gotten sufficient review and there was no objection to the plan to
publish them when the AD proposed doing so on the WG list in April 2022.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

Bit of both. The author team have dilligently progressed
the work, with review from WG participants over the years.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

No. (but CHECK)

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

Perhaps the DHC WG should take a look? Hasn't been requested yet.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The document is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

PS.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

No known IPR issues.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

In progress: DM and RW responded so far.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

idnits is happy.

15. Should any informative references be normative or vice-versa?

No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

N/A

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

N/A, other than the companion draft being progressed alongside this.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

All good.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A.