Hi, Ted,
On 2/18/2012 7:29 AM, Ted Lemon wrote:
> On Feb 17, 2012, at 5:47 PM, Joe Touch wrote:
>> Thanks. In this case, it's important to suggest why others should not
>> add conventional DHCP query support to the TCP port.
>
> The idea of doing DHCP stateful autoconfiguration over TCP is
> nonsensical: DHCP clients start out with no IP address, so it is not
> possible for them to do TCP.
That's true for the initial request, but not for lease renewal.
> The reason for sharing option codes is to avoid confusion: since
> existing DHCPLEASEQUERY option codes come out of the same namespace as
> DHCP options,
Which doesn't need to happen if this is a completely different service...
> if we were to propose that options in this documentation
> come out of a different namespace, we would have to declare that new
> namespace, which would have some options and option codes in common with
> the existing namespace. This doesn't add value.
It avoids misrepresenting this as related.
> Historically, we have never said that when an option code is added, that
> updates RFC2131 (really, it would make more sense to say it updated
> RFC2132 if we were to go there, since RFC2132 is the document that
> describes DHCP options).
Fair enough - 2132.
> So it would be surprising and unconventional if
> this document were said to update either RFC2131 or RFC2132 simply
> because it defined one or more new option codes.
OK, so although I disagree that this is the correct procedure, if it's
typical for DHCP then that's reasonable.
Joe
_______________________________________________
dhcwg mailing list
dhcwg@...
https://www.ietf.org/mailman/listinfo/dhcwg
