[homenet] John Scudder's Discuss on draft-ietf-homenet-naming-architecture-dhc-options-21: (with DISCUSS and COMMENT)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-homenet-naming-architecture-dhc-options-21: 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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-naming-architecture-dhc-options/



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


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