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
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.
Ietf mailing list