Hi Daniel, Thanks for the updates, they look good, I will clear my DISCUSS. One further comment, below.
> On Oct 19, 2022, at 11:47 PM, Daniel Migault <[email protected]> wrote: [… snip …] > 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. > ~~~ [… snip…] > 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. What I was getting at is, if the anticipated way of adding these in the future (if needed) would be to define new options, then perhaps the sentence could be something like “the HNA may complement the configurations with additional parameters using new options not yet defined” (so replace “via means” with “using new options”). I don’t insist on this change, but as it currently stands it might be seen as a subtle hint that further extending DHCPv6 is not necessarily the preferred way to introduce additional extensions. $0.02, —John _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
