WARNING: This server is unstable and will be retired in the next days.
If you want to keep this forum available, please request immediately a migration
on the Nabble Support forum.
Forums that don't receive any migration request will be deleted forever.
> Joe, Kim...
> On Feb 17, 2012, at 5:47 PM 2/17/12, Joe Touch wrote:
>> Hi, Kim,
>> First, thank you for your detailed response to my quite lengthy review.
>> Some further clarifications and confirmations appear below.
>> On 2/17/2012 12:09 PM, Kim Kinnear wrote:
>>> Thank you for your review.
>>> My responses are indented, below...
>>> On Feb 13, 2012, at 5:00 PM, Joe Touch wrote:
>>>> Hi, all,
>>>> I've reviewed this document as part of the transport area
>>>> directorate's ongoing effort to review key IETF documents. These
>>>> comments were written primarily for the transport area directors,
>>>> but are copied to the document's authors for their information and
>>>> to allow them to address any issues raised. The authors should
>>>> consider this review together with any other last-call comments
>>>> they receive. Please always CC tsv-dir@... if you reply to or
>>>> forward this review.
>>>> This request was received Feb. 2, 2012.
>>>> This document describes an extension to DHCPv4 for the bulk query
>>>> andtransfer of current lease status over TCP.
>>>> The following transport issues were noted, and are significant:
>>>> UPDATES- The document updates DHCP with support for TCP, and as
>>>> suchthis document seems like it should UPDATE RFC2131
>>> While this document clearly builds on RFC 2131, it
>>> doesn't actually change anything that anyone is doing
>>> that is currently based on RFC 2131. My understanding of
>>> "updates" is that, in order to understand the first RFC
>>> (in this case, RFC 2131), you need to read all of the
>>> RFC's that "update" it. That isn't the case here -- you
>>> can be very happy reading and implementing DHCPv4 by
>>> reading RFC 2131 and never have to know that DHCPv4 Bulk
>>> Leasequery exists. In general, in the DHC WG, we seem to
>>> set a pretty high bar for what "udpates" another RFC. I
>>> don't see that this document has met those requirements.
>>> But this isn't really my call. I'll let Ralph Droms and
>>> the DHC WG chairs decide on this one, and I'll do
>>> whatever they tell me to do.
>> Agreed. FWIW, my "bar" for that is whether implementing DHCPv4 as
>> per RFC 2131 is changed by this doc. If DHCP fundamentally starts
>> requiring TCP port support, then this doc then changes the spec as
>> described in 2131 IMO.
> Joe - I don't see that this document fundamentally requires TCP port
> support for DHCP operation as described in RFC 2131. This document
> describes a protocol that is closely related to but independent of RFC
> 2131, and a server based on RFC 2131 can perform all the DHCP functions
> in RFC 2131 without considering this document. So, I can see your point
> but I disagree that this document updates RFC 2131.
Fair enough, but then I'll put on my IANA hat and note that this then is
no longer the complementary TCP protocol to DHCP. By your argument, it's
a new service, and should have a separate TCP port and service name.