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 < nore...@ietf.org> 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 > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet > -- Daniel Migault Ericsson
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet