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

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

Thanks for addressing my DISCUSS and comments.

https://mailarchive.ietf.org/arch/msg/homenet/-VwL5Qzxn-nc2_Tf70vAjjUuOtM/

# 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

Thanks to Bron Gondwana for his ARTART review.

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.

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].

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.