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

[Daniel Migault <[e-mail]>]

Hi John,

Thanks for the feed backs and the careful review. I guess I have addressed
all the comments. You can these addressed in the text below.
https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/commit/ec075d76c45705814799ba44fd3118025e8e25f5

I also provided some responses inline below.

Yours,
Daniel


On Tue, Oct 18, 2022 at 6:36 PM John Scudder via Datatracker <
[e-mail]> wrote:

> 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]".)
>
>
> We had this information as it was not perceived as essential to implement
the dhcp options. I do not minded having it normative. We changed it to
normative.


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

We assume for simplicity that the HNA and the DHCPv6 client are colocated,
but this is not necessary, in which case, the two entities need to be able
to communicate. Such a protocol has not been defined yet.

You are correct there is something wrong in the text.

OLD:
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.

NEW:
Note also that this is not mandatory and the DHCPv6 client may instruct
remotely the  HNA with a protocol that
will be standardized in the future.


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

maybe provisioned is better than configured. The server needs to be able to
return the information associated to the DM and RDM.  I think the text here
addresses your concern:
In addition, this section assumes the responsible entity for the DHCPv6
server is provis
ioned with the DM and RDM information - associated with the requested
Registered Homenet D
omain .


> ### 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?
>
> changed associated to to associated with in all the document.

### 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.
>
> since they are colocated.... but yes it makes sense. changed.


> ### 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.)
>
> It should appear 3 now. THere was a comment in the source and so the
converter interpreted it as a new list.


> 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..."
>
> using the lower case is fine. changed.


> 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?
>
> Currently we use the minim set of options / parameters. If there is a need
for a more complex use case, it is likely that new options will be needed.
The reason to have the simplest options as possible is to avoid
unnecessary complexity.

> ### Section 4.1
>
> As mentioned earlier, I suggest the more idiomatic "associated with" rather
> than "associated to".
>
> changed.


> ### 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.)
>
> You are correct, thanks.

OLD:
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 establis
h the communication between the HNA and the DM

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

### 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.
>
> specified with left most and left to right in section 6.


> ### 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?
>
> There is no lease, you are correct.


> 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?
>
> correct I missed a #

> ### Appendix B.2
>
> Where you say "CE router" do you really mean "CPE router"?
>
> yes changed.

> ## 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
>
>
>
> _______________________________________________
> homenet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/homenet
>


-- 
Daniel Migault
Ericsson