Thanks Bron for the review, that is well appreciated. I like your suggestion and we will check with the RFC Editor and IANA what is the best way to handle this and avoid repeating the values assigned by IANA.
Yours,
Daniel
Daniel
On Wed, Oct 5, 2022 at 2:39 AM Bron Gondwana via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Bron Gondwana
Review result: Ready with Nits
Thanks to the authors for this, and apologies for a slightly delayed review.
I read this document and skim-read the linked
draft-ietf-homenet-front-end-naming-delegation which describes why these fields
might want to be provided by DHCPv6.
I found this document clear and easy to read - there were no nits that stood
out to me other than the double-definition of the "Supported Transport" field.
While there is a chicken-and-egg problem, the RFC editor and IANA could be
instructed to link things up such that section 4 immediately named the registry
to look up the values in rather than hard-coding an initial table into this
document, and having future readers reach this section without finding the
pointer to IANA in the natural place.
Likewise once the values are assigned by IANA for the DHCP option codes,
putting them directly into this document in the spots where a reader would
naturally be looking would help implementations.
Overall - this document has a very long history - well done for sticking with
it. I hope one day to buy a product which uses the end result of this work and
transparently configures MY home network!
_______________________________________________
homenet mailing list
homenet@xxxxxxxx
https://www.ietf.org/mailman/listinfo/homenet
Daniel Migault
Ericsson
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
