Subject: RE: [dhcwg] draft-ietf-dhc-server-override-03.txt returned todhcWG for review (2nd call for review)

From: "Woundy, Richard" <[email-masked]>
Date: Sun, 19 Mar 2006 17:28:03 -0500

I'm sorry you chose to ignore this part:
 
>I would strongly urge folks to focus on technical issues (e.g. perceived conflicts with prior specifications)
 
I did not say there was not a legitimate debate about whether the DHCP server can reply to a renewal with a NAK.
 
As a minor point of data, my company has probably sent NAKs to just about every current customer's computer (well, their DHCP client) in reply to a DHCP renewal request at some point in time. That's how our bottoms-up process works for getting folks online with our Internet over cable service. That data point also represents around 10 million computers, of various makes and models. I realize this isn't authoritative for a spec, but sometimes it's worth knowing what happens in the real world.
 
-- Rich
 
________________________________

From: David W. Hankins [mailto:[email-masked]]
Sent: Sat 3/18/2006 10:36 PM
To: Woundy, Richard
Cc: Margaret Wasserman; Stig Venaas; Ralph Droms; Ted Lemon; Mark Townsley (townsley); [email-masked]
Subject: Re: [dhcwg] draft-ietf-dhc-server-override-03.txt returned todhcWG for review (2nd call for review)

On Sat, Mar 18, 2006 at 08:34:44PM -0500, Woundy, Richard wrote:
> I think it sets a very VERY BAD precedent to debate the technical validity and viability of an internet-draft, based *solely* on whether an individual software developer, or even multiple software developers from one company, are permitted to implement the specification.

If you believe that to be the case ("*solely*"), then I am afraid you
have very poorly read my missives on the subject.

--
David W. Hankins                "If you don't do it right the first time,
Software Engineer                       you'll just have to do it again."
Internet Systems Consortium, Inc.               -- Jack T. Hankins

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 20 Mar 2006 14:05:22 +0000

> I'm sorry you chose to ignore this part:

I didn't.

> >I would strongly urge folks to focus on technical issues (e.g. perceived conflicts with prior specifications)

It's my belief that this is precisely what I'm focusing on.

Perceived problems with the current specification.

> I did not say there was not a legitimate debate about whether the DHCP server can reply to a renewal with a NAK.

You did.  "*solely*".

> As a minor point of data, my company has probably sent NAKs to just about every current customer's computer (well, their DHCP client) in reply to a DHCP renewal request at some point in time. That'…

I wonder why you now supply data that has not been in contest since
last November.

Do you harbor a belief that I am unaware of it?

Sir, this draft changes server behaviour.  The obvious way it does
that is contained within its pages:  It sets server-identifier to
what would be giaddr (or whatever address the relay likes).

What is not contained within those pages is that servers will now
NAK clients in RENEW based upon their network connection (and any
other reason we've already been doing this is irrelevant).

I submit the current text in the draft, "In effect, this makes a
RENEWAL into a REBINDING." is neither sufficient analysis for this
to become standard behaviour, nor is it a genuine reflection of
the changes in server behaviour we're proposing.

That is:  It's ok to have consensus to adopt this behaviour in DHCP
servers, so long as the entire WG is aware that's what we're doing.

That awareness is what I believe to be lacking.

---

From: Mark Stapp <[email-masked]>
Date: Mon, 20 Mar 2006 11:11:47 -0500

David,
this extended exchange does now seem to have made your issue clearer, 
and that's been useful. we need to add some text to communicate the 
issue. I think an outline goes something like this:

If server-id-override is being used, additional information is available 
to the dhcp server when it receives client messages. In particular, the 
relay whose address has been supplied to the client may be adding the 
relay-agent-info option to all of the client's messages, including 
unicast renews. Servers that support server-id-override need to account 
for this in their decision-making. The presence of the relay-agent 
option and a value in the client message's giaddr field does not mean 
that the client in in the REBINDING state. [I think Kim will be 
proposing adding info that will make it possible to determine this.]

In addition, it becomes important whether a client can send unicast dhcp 
messages to the relay address that is being used in the 
server-id-override suboption. When the client is in the RENEWING state, 
it will be sending its unicast RENEW messages to the relay address that 
was substituted into the server-id option. If the client's messages 
cannot reach that relay address - because the client has moved and no 
longer has a route to that address, for example - the client will be 
forced into the REBINDING state when it reaches the T2 time.

Is that broad enough - too broad? What's missing? I'm leaving out the 
discussion about whether or not servers are allowed to NAK in response 
to RENEWs. That's emerged as a separable issue better suited to a 
clarifications document of some kind.

-- Mark