I was asked to review this I-D a while ago, so here are my comments.
I'm not a routing expert, but know a thing or two about DHCP, so that's
where the focus of my review is.
The I-D could use some extra work before requesting adoption or broader
feedback.
DHC folks are not enthusiastic about defining new DHCPv4 options, except
for the transition technologies and that's exactly what this I-D is
proposing.
Specific comments:
1. This draft attempts to standardize a new option. Why is it
experimental and not standards track? IANA page says the "BOOTP Vendor
Extensions and DHCP Options" registry needs to pass IETF review.
RFC2026, Section 4.2.1 states the Experimental spec is subject only to
editorial considerations. So while it is generally easier to progress
with experimental I-D, you might hit a wall at the IANA assignment
phase. So I would suggest to check up with IANA or DHC chairs, if
assigning option code in experimental is OK or not. Having said that, in
the early days, lots of DHCPv4 options were assigned more generously,
but the process has tightened over the years.
2. While this is not strictly sanctioned, using DHCP in v4/v6 migration
context is ambiguous and confusing. To avoid that, I'd suggest to use
DHCPv4 (and DHCPv6 if you need to reference it).
3. Section 3: "Hosts that do not support this function MUST ignore the
option described in this document and behave as before.". I'm not sure
this normative language is necessary. Hosts that don't support it, will
simply not request the option and the server will never send the option.
The less normative language the better.
4. This is the most important comment. As specified in -00, the option
syntax is very bad. The conditional formatting is something that is
to be avoid. RFC7227 (DHCPv6 Options guidelines), Section 6 is
specifically making that recommendation. The RFC is about DHCPv6
options, but great majority of its text also applies to DHCPv4. Back
when it was being specified, the DHC felt it's too late for DHCPv4.
Still, as a DHCP implementor, I strongly suggest to avoid conditional
formatting. If you choose one of the primitives (or option consisting of
primitives), that's something you can do in Kea (and many other
implementations) with just a configuration. Most (all?) server
implementations allow some way of defining custom options, but I'm not
aware of any that allows conditional formatting of the options.
So if you want the option to be easily deployable, it's much better
to define an empty top level option, basically a container and a
number of suboptions, each with simple format. If you go the option +
suboptions, you'd need to ask IANA to create new registry, but that's
easy to do. Let me know if you need any help and I'll be happy to
assist.
And you can probably go down to just two suboptions. For the T=0 case
you might want to do something similar to what RFC6221, Section 6.1
does. Setting a field to :: (or 0.0.0.0) would mean to use link local
address.
I would take out the YANG model definitions out to a separate I-D. These
are two independent things and it makes easier for implementors to just
do the DHCP option if they're unable or unwilling to support YANG.
Nits:
Some polishing would be useful. A link to github is not something the
abstract should start with. There are MANY drafts out there. Most
readers start with an abstract and if don't get their attention, they
often move to another draft.
Finally, once this draft is a bit more mature, it wouldn't hurt to send
a request to DHC WG to ask for feedback.
Tomek
_______________________________________________
Int-area mailing list -- int-area@ietf.org
To unsubscribe send an email to int-area-le...@ietf.org
