Subject: [dhcwg] RE: Changes for draft-ietf-dhc-implementation-02.txt

From: "Barr Hibbs" <[email-masked]>
Date: Wed, 12 Jul 2006 09:40:16 -0700

Thanks for your comments, Andre...  I've copied the entire
message to the mailing list in this reply to stimulate
discussion.

--Barr

> -----Original Message-----
> From: Andre Kostur [mailto:[email-masked]]
> Sent: Wednesday, July 12, 2006 07:39
>
> I've got some comments/errata on the
> Implementation Issues document
> (draft-ietf-dhc-implementation-02.txt):
>
>
> Page 6, Section 4.2.3, Bullet point 2:
>
> This talks about Table 4 and Figure 5 not
> including the INFORM message.
> a) The replacement for Table 4 still doesn't
> include the INFORM
> b) I don't think either item should include the
> INFORM.  Table 4 is
> really talking about how to distinguish between
> the various DHCPREQUESTs
> in the various states.  And DHCPINFORM doesn't
> modify the client state
> machine as it isn't a state-modifying operation.
> An INFORM could
> theoretically be sent from any state.
>
.....[rbh] I think this fell through the cracks...  at one
point, I was trying to reconcile the non-stateful behavior
of the INFORM message and its REPLY with the stateful
behavior of address assignment.  Obviously, the client MUST
have acquired an IP address (either through discovery or
static assignment) prior to using INFORM, but I've not been
able to find a good way to represent this requirement
graphically.  When I revisit the text, I'll see if I can add
the specific assumption that INFORMs may only be used when
the client IP address is in place.

>
>
> Page 10, Section 4.6.2, first paragraph:
>
> The document suggests a retry for ping.  Are we
> going to make the client
> wait for a DHCP address until we've retried the
> ping a few times?
>
.....[rbh] personally, I think that PINGs SHOULD BE retried,
but I believe the correct statement for the RFC is that it
is an implementation decision.  The parallel discussions
about Duplicate Address Detection have a bearing on the use
of both ICMP ECHO and ARP, but for DHCP the use of PING and
ARP ought to be "SHOULDs" and probably specifically
identified as implementation dependent.

>
>
> Page 11, Section 4.7.1:
>
> Note the current discussion about L2 relay
> agents, where they don't have
> their own IP.  Or do we not call these L2 relay
> agents "relay agents"?
>
.....[rbh] I'm open to suggestions for the proper taxonomy,
though I'm biased towards leaving hosts/functions with their
own IP addresses retain the name "Relay Agent" and finding a
new name for the L2 devices.

>
>
> Page 12, Section 4.10, second paragraph:
>
> Talks about matching the ciaddr with the source
> IP.  This may not be a
> valid check as the DHCPINFORM may have been
> originally broadcast, and
> then relayed to the DHCP server.  As a result,
> the ciaddr refers to the
> client, but the source IP may refer to a DHCP Relay Agent.
>
.....[rbh] good catch....  I'll revisit the text to find the
underlying intent and reword to be specific.

>
>
> Page 13, Section 4.11, third bullet point:
>
> Figure 5 is the client state machine.  Perhaps
> this should have been
> Table 5?
>
.....[rbh] sorry for the inconsistency.  The Client State
Machine SHOULD refer to a figure, although this does get
confused with so many tables detailing the contents of
certain message fields.  Will examine each usage for
consistency.

>
>
> Page 13, Section 4.13:
>
> DHCP clients _do_ send messages to servers from
> the RENEWING and
> REBINDING states.  Specifically retried DHCPREQUESTs.
>
.....[rbh] this confusion arose from the original diagram of
the Client State Machine and it seems that I may not have
corrected it properly.

>
>
> Page 14, Section 4.13, Recommendation:
>
> It suggests the replacement to Figure 5 be
> sections 5.2.6 and 5.2.7.
> Those are the replacements for Table 5.  The
> Figure 5 replacement is in
> section 5.1.4.
>
.....[rbh] thanks, I will check all references for
consistency.

>
>
> Page 14, Section 4.14.1, second bullet point (labeled 5):
>
> Perhaps DHCP servers should send all configured
> options back to the
> client, but place those options which were
> specifically requested by the
> client first.
>
.....[rbh] I recall this particular point being a great bone
of contention among implementors.  I think this is a local
implementation matter in general, but I also believe that a
server MUST send any options that its administrator knows to
be crucial to operation in the network segment(s) being
served -- without them, a client may be rendered effectively
inoperable.  For example, Client IP Address, Address Mask,
Gateway Address(es), DNS Server Address(es), and Lease
Duration probably would be considered Mandatory by an
Administrator.  As for order of options, I would suggest
that the "Mandatory" options should be first, followed by
other client-requested options, then any remaining
configured options that fit.  Maybe this is best stated as a
recommended practice, rather than an absolute requirement?

>
>
> Page 16, Section 4.14.4, Recommendations 1:
>
> This may be hard to change, as other
> specifications are already written
> around this behaviour, specifically DOCSIS and
> PacketCable (in Basic
> provisioning mode).
>
.....[rbh] true, but my recollection is that one of those
specifications requires that a server not use the File Name
field for concatenating DHCP options -- and that seems like
a lousy restriction on DHCP, where another specification
abrogates well-established behavior of a protocol.  I've
little hope that DOCSIS and PacketCable implementations will
also support non-DOCSIS, non-PacketCable clients, but there
is a principle here about abusing another protocol.

>
>
> Page 17-18, Section 4.15.4:
>
> Perhaps this document should mention RFC 3925 -
> Vendor Identifying
> Vendor Options as a solution to the multiplicity issue?
>
.....[rbh] I'll toss this one to the co-chairs and the ADs.
One major topic of discussion is what to do with all the
related RFCs.

>
>
> Page 18, Section 4.16, first bullet point:
>
> Shouldn't that read: "... last sentence of list
> item 3."?  (Currently
> says "3.1")
>
.....[rbh]  thanks

>
>
> Page 19, Section 4.18, Recommendation:
>
> How about the following scenario:
> - Device is on subnet A
> - Device moves to subnet B, but the system cannot
> detect link changes
> - Device eventually enters REBIND
> - DHCP server recognizes that this device is
> REBINDing from a new
> network, and could NAK the device
>
> Under this recommendation, the DHCP server would
> be required to attempt
> to Unicast the ACK back to the ciaddr (which
> presumably wouldn't get there).
>
.....[rbh] wouldn't your scenario require that both subnets A
and B essentially be a shared network segment?  Otherwise,
the client that moved would be (presumably) unable to
communicate and would fairly quickly move to DISCOVER.  I'll
have time tomorrow to completely examine the scenario and
may have a more complete response then.

>
>
> Page 20, Section 4.20:
>
> I think the phrasing is wrong.  Perhaps that
> section should use the
> phrase "any return messages" instead of
> enumerating DHCPOFFER and
> DHCPACK specifically.
>
.....[rbh]  I'll carefully re-read this.

>
>
> Page 28, Section 5.1.4, Figure 5:
>
> I don't agree with the new state machine.  The
> new machine changes the
> relationship between BOUND, REBINDING, and
> RENEWING.  As it currently is
> drawn, follow the sequence:
> - Device is in BOUND
> - T1 expires, unicast DHCPREQUEST, transition to RENEWING
> - No responses arrive, T2 expires
> - No transition occurs as the only ways a device
> may leave RENEWING is
> to either receive an ACK or NAK.
> - Same problem when the lease expires.  That
> doesn't cause a state
> transition from RENEWING either.
>
.....[rbh] I would argue that until the client receives a
response, it hasn't transitioned to the next state, but I
will look carefully at the previous and proposed state
machines.

>
>
> General Consistency Issues:
>
> Sometimes a single-item recommendation list is
> not bulleted in section
> 4.4, 4.6.1, 4.6.2, 4.13, 4.14.2, 4.14.3, 4.17,
> 4.18, 4.19.1, 4.22, and
> 4.27; everywhere else does.
>
.....[rbh] thanks

> The draft is inconsistent as to what bulleted
> lists are using for bullets:
> - Bulleted Lists in sections 4.2.1, 4.2.2, 4.2.3,
> 4.2.4, 4.4, 4.6,
> 4.7.2, 4.10, 4.11, 4.12, 4.14.1, 4.16, 4.17, 4.19.2
> - Numbered Lists in sections (where it isn't
> really an enumeration) 4.1,
> 4.5.1, 4.14.4, 4.23, 4.25
> - And mixed bullets and numbers in sections 4.2.5, 4.14.1
>
.....[rbh] thanks

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

---

From: Andre Kostur <[email-masked]>
Date: Wed, 12 Jul 2006 09:57:11 -0700

> will look carefully at the previous and proposed state

Under that argument, a device would never leave the BOUND state (except 
for lease expiry and NAKs).  The device would emit a DHCPREQUEST in the 
BOUND state, wait for a response (maybe retry a couple of times), 
finally receive an ACK, and then transition to.... the BOUND state.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 12 Jul 2006 18:31:56 +0000

Just as a forewarning, I'll have more substantive comments once I
find some time for it.

I don't agree with several bits of the document.

So stay tuned (and smack me if I'm holding you up).

On Wed, Jul 12, 2006 at 09:40:16AM -0700, Barr Hibbs wrote:
> graphically.

Anecdotally: Clients that use DHCPINFORM singularly exist which
do not set the ciaddr value.  This is both the same and different
from having an IP address already (these clients have IP adresses,
and use them, but fail to set ciaddr...indicating falsely that
they do not yet possess one).

For reference, I provide for example this discussion from the
ISC dhcp-server mailing list about something called "Macromedia
Flash Proxy Autodiscovery":

  http://marc.theaimsgroup.com/?l=dhcp-server&m=113466843320099&w=2

Even though it is bad taste, I will quote myself on this subject
out of pure ego:

  "There is a lot of pain in this packet."

I submit for the WG:

1) If giaddr is set on a DHCPINFORM, ISC DHCP now /always/ returns
   the response to the giaddr (as a relay), and includes the relay
   agent options (if any were supplied).

2) If the giaddr is set and the hardware address is zeroed, ISC DHCP
   sets the broadcast bit to 'help' the relay.  This may or may not
   be a good idea.

3) If a DHCPINFORM is received which has no ciaddr or giaddr set, ISC
   DHCP uses the IP source address to deliver the response.  This
   appears to mimic behaviour of other implementations (at least I
   assume that is the case for Macromedia's INFORM to have ever left
   a lab or be used in the field).

4) Otherwise, the ciaddr is used, which (finally) is the RFC specified
   behaviour for INFORM.

I seme to recall deciding that the 1-3 behaviour is clearly not
reference behaviour (it is allowed by reference ("SHOULD"), but the
specific behaviour is not reference).  Right or wrong.  I am guilty
of 'extending' this behaviour (the no-chaddr->broadcast bit is my fault,
my only excuse is that the rest of this behaviour was already in the
server and I did not question its referenceness), but can not take full
credit for this.

Whatever the case, it's clear to me that ISC DHCP should not use this
behaviour unless a WG document exists which documents it or it's moved
to a user-configurable option.

Since the above is current operational practice, should it be
clarified ("made reference") as appropriate behaviour?  Should it be
clarified as inappropriate behaviour?

I tend to think it should be clarified as inappropriate (quoting now
section 4.10 of draft-ietf-dhc-implementation-02):

1) "The server SHOULD check the network address in a DHCPINFORM message
   for consistency."

   I suggest this should be clarified to mean:

   "The server MUST discard DHCPINFORMs whose ciaddr is 0.0.0.0.  The
   server SHOULD discard DHCPINFORMs whose ciaddr is not an address in
   any subnet under that server's domain."

2) Leave 4.27 bulletpoint 6 alone (but possibly move this to 4.10?).

3) Since the server will never respond to giaddr ("MUST" now), punt
   on chaddr validation.  Why?  This information may not be available
   to the process transmitting the DHCPINFORM, so there are use cases
   where it might be zeroed.

> identified as implementation dependent.

Be careful: how many retries before the client retransmits its
DISCOVER?

I am looking forward to the day that ISC DHCP keeps track of
time events on a microsecond scale - so that we may finally
wait less than a second for one ICMP echo to time out and offer
addresses (on purpose rather than by accident today).

> For example, Client IP Address, Address Mask,
> Administrator.

I might point out anecdotally that DHCP Server implementations
already exist which forcibly supply the Subnet Mask option wether
the client requested it or not.  It turns out clients exist that
understand options they don't ask for (despite various claims to
the contrary).

This makes ISC DHCP incompatible with such clients.

As a consequence, ISC DHCP will follow suit.

As this is an implementation document, you might want to capture
that (if you haven't already...I've read the document but I can't
remember now).

My own take on this is, we stuff some options into the packet
right off the bat, not only "without the client asking" but
"at highest priority" (before the client's priority list):

        priority_list [priority_len++] = DHO_DHCP_MESSAGE_TYPE;
        priority_list [priority_len++] = DHO_DHCP_SERVER_IDENTIFIER;
        priority_list [priority_len++] = DHO_DHCP_LEASE_TIME;
        priority_list [priority_len++] = DHO_DHCP_MESSAGE;
        priority_list [priority_len++] = DHO_DHCP_REQUESTED_ADDRESS;

We then add in the parameter list supplied.

After that, we put in some options that also might not be requested
(but we thionk should be), and documentation at one point or another
suggests it must be provided wether the client asks for it or not:

                if (priority_len < PRIORITY_COUNT)
                        priority_list[priority_len++] = DHO_FQDN;

                if (priority_len < PRIORITY_COUNT)
                        priority_list[priority_len++] = DHO_SUBNET_MASK;

The list is uniq'd before options start getting written into the
options buffer (later repeats of the same option are removed).

> As for order of options, I would suggest
> configured options that fit.

I think as I've documented above we're in agreement.

>   Maybe this is best stated as a

I think if we don't specify this very carefully as a common and
consistent behaviour, that we're going to invite compatibility
problems.

I'm worried most about what options appear in a packet if they do not
appear on the parameter request list.

I'm worried next about what options are omitted if there isn't enough
space (and in what order).

I'm worried not at all about what order they appear within that packet.

I think the above needs to be MUSTs.

> is a principle here about abusing another protocol.

Anecdotally, the file and sname fields are only avaialable for DHCP
options if the 'options overload' option is in use.  I have some
questions that have troubled me about that.

The DHCP Server has no idea if the client implements option overload.

Has anyone encountered a client that doesn't?  It's rare enough
that we encounter a need for it, I assume we may simply not know
because there's never been a need.

It's pretty clear to us that you should, just for this compatibility
question, fill the 'options' buffer first, then the file buffer, then
the sname buffer.

This invariably results in a fragmented option (a partial option) in
the options buffer, and the remainder in the file buffer.

IF the client does not support overloading, they'll process the
truncated option.

So should we give the advice that option fragments should not span
option overloaded spaces?

> One major topic of discussion is what to do with all the

Minor point: if the client sent more than one vendor class option
it would be concatenated together and treated as one vendor class
option by the server.

I think you should simply omit this section.  I don't think there's
any operational guidance we can give on this subject.

> may have a more complete response then.

That's not the case - if 802.1q is being used (or HSRP or VRRP
for the default router) on both segments, it's possible that
packets will escape the network and reach the DHCP server.

If the server receives such unicasts, yes, it MUST DHCPACK and
we know (or hope) the client will not receive that answer.  As
it turns out, in one implementation, such DHCPACKs from the ISC
DHCP server with directly-connected clients (no relay agent) do
actually reach the clients.

Eventually the client will enter REBIND and broadcast, and
since we can tell the difference between RENEW and REBIND
based upon wether the client broadcast or unicast ("was via
a relay agent or not" or local interface tricks if there is
no relay agent) then we can NAK the REBIND.

But only so long as we can tell the difference between those
two.

I think what Mr. Hibbs means is that 'Servers trust "ciaddr", for
those purposes for which it is used.'  I don't think he meant to
imply that DHCP servers always respond to clients via the ciaddr,
and never via giaddr.

For example, DHCPNAK may be transmitted to the ciaddr, unicast,
but only if giaddr is not set (rfc2131 is pretty clear that it
prefers to get these via broadcast - in fact such unicasts are
merely 'not reference behaviour', they are never actually
made reference).

-- 
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

---

From: Andre Kostur <[email-masked]>
Date: Wed, 12 Jul 2006 11:43:03 -0700

> they do not yet possess one).

Arguably that makes it an invalid DHCPINFORM.  According to Table 5 (RFC 
2131), the ciaddr is required to be the client's network address.  This 
is also specified in section 4.4.3 (RFC 2131).

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 12 Jul 2006 17:12:01 +0000

> finally receive an ACK, and then transition to.... the BOUND state.

I agree with this assessment.

ISC dhclient transitions into these states, and as a consequence of
that state transition detection, causes a packet to be transmitted.

The state change is both conceptually and realistically prior to the
emission of a message related to that state-event.

I also agree that there are several other states that are entered
into upon receiving certain packets (such as DHCPNAK), but this is
not to say that state transitions are made only upon receiving
packets.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Jul 2006 01:08:40 +0000

> is also specified in section 4.4.3 (RFC 2131).

I don't think there is any argument to be had here: the client behaviour
is clearly going against reference and could not be described to be
implementing RFC2131.

The server behaviour reference questions are the ones that are
fundamentally more interesting to me on this point.

Be liberal in what you accept and...something like that?

Or screw liberalness and break the clients?

Or something else entirely?

I've shared my opinion and I'd like to hear others.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Jul 2006 21:42:45 -0400

> I've shared my opinion and I'd like to hear others.

Well, you probably already know my opinion from reading my code, but
just for the record, the fact is that there are a lot of very poorly
written DHCP clients out there.   The more you insist on strict
conformance, the less likely your server is to be useful on a practical
level.

So you have to decide: is the ISC server a DHCP server, or a protocol
compliance testing device?   If it's the latter, be strict.   If it's
the former, leave all those heuristics in.   Practically speaking, I
think you're actually better off if you care about conformance to add a
--strict flag to the server to enable strict conformance checking.

When we originally did the ISC server, the motivation was to have a
server out there that would run on Unix boxes and hopefully stimulate
acceptance of the protocol, so Paul never really asked me to be strictly
conformant (although perhaps that was what he thought he'd asked me - I
don't know).   The server would have worked well with very few clients,
certainly not the Microsoft client, if it had been strictly conforming
at that time.

But the situation is different now - aside from the NUL botch, the MS
client is pretty good now, and there aren't any really broken DHCP
clients in Macs or Linux boxes anymore.   So it's probably okay to be
strict now.

I certainly wouldn't argue that you should add stuff to RFC2131-bis to
be more lenient - the clients you're working around are *broken*, and
the fix is to the code, not to the protocol.   We already made that
mistake with the NUL botch - let's not do it again.   It just adds bloat
to the protocol and to the implementations.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Jul 2006 03:15:38 +0000

On Wed, Jul 12, 2006 at 09:42:45PM -0400, Ted Lemon wrote:
> compliance testing device?

To answer this tangential question in-band: neither.  It's a "reference
implementation."

It is implemented "to reference."  So what is the reference?

If the reference is documenting a protocol that is usable in the real
world, alone and on its own merit, then ISC DHCP will be useful in
the real world.

If the reference is not useful if you implement to it (unless you
know all the workarounds and tricks), then so will ISC DHCP be
useless.

This is why IETF attendance and participation is now on my "job
description": it's my *job* to fix the reference where it's broken
to match the reality.  I realize you haven't gotten many drafts from me
yet, and in particular none on these sorts of topics.  That will change.

It may be a painful experience, and I apologize in advance.

If you're still at IETF 66 we should get together and see if I can
explain this better.  It's not the first time I've amazed you with
ISC DHCP's new direction.  I don't want to burn too much dhcwg airtime
on this.

> to the protocol and to the implementations.

I agree, as I've said, on the client issue: the client behaviour should
continue to be specified as incorrect.  Which I think (or hope) is
what you're talking about here.

But are you disagreeing with the current draft-ietf-implementation-02.txt
which changes this 'SHOULD' that sort-of 'allows' this workaround to
a 'MUST' which does not allow the workaround?  This is encoding strictness
into the reference on this issue, which I get the idea you're against
(I admit I'm a little confused - you started out promoting leniency
and ended promoting strictness, and I'm not sure in what contexts).

If you and other WG members think it is worthwhile, we can ask Mr.
Hibbs to alter his stance here: leave the 'SHOULD' and provide a
description of ISC DHCP's current behaviour as an acceptable ("MAY")
alternative?  Or I could provide that alternative behaviour in a
companion draft to solve my, and my alone, reference problem.

Whatever the case, thanks for taking the time to comment, Ted.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 13 Jul 2006 15:07:27 +0000

I really don't think my job description, or ISC DHCP's design goals
are within the charter for the DHC WG, nor its mailing list.  I meant
it when I said I'd be happy to talk about it, and I would: I am in
the IETF 66 terminal room right now if anyone wants to schedule an
ad-hoc meeting.  I'm sure I'll be somewhere in the vicinity of
Montreal until Friday afternoon.  My email address is in the header
of this very message, and I welcome its use.

However.

If there's interest, and the chairs can speak if this is topical
to this WG, and it would result in less discussion about it
cluttering the mailing list, I suppose I can provide a presentation
at the next DHC WG meeting to try and explain it, since clearly Ted
has enough interest in the topic to discuss it, but not enough to
come find me in the terminal room at IETF 66 (if he's even still
here), and there might be others in the same boat.

I am certainly not inviting any disagreement or discussion on our
design goals except to say: talk to my boss, Rob Austein, his:
Brian Reid, and his: Paul Vixie, preferrentially in that order if
you have any problems whatsoever with my interpretation of same.

Although Ted intimates that ISC DHCP's direction is "my choice",
nothing could be further from the truth.

I just work here.

Ted:  Get us out of these weeds.  I am still unclear on what you
agree or disagree with that appears or does not appear in
draft-ietf-dhc-implementation-02.txt sections 4.10 or 4.18, or
any other topical section I'm missing, as the vague statements
you have made in support or defiance of either leniency or
strictness have not been in strict reference to any statement or
section that appears in that draft.  I don't mean to intimate
that you're changing positions on the topic, rather that it
simply is not clear under which circumstances your statements
apply (and that if I read them a certain way, it appears you
are actually arguing that the draft Mr. Hibbs has produced and
revived should cease to exist!).

If I were Mr. Hibbs, I would not know how you expected that
document to be improved except vaguely that you wanted "good
things to happen" and had quite a lot of opinions on the
vagueries of what kinds of things are good and what kinds of
things are not.

Direction for Mr. Hibbs is what's important here.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Jul 2006 09:35:27 -0400

> and ended promoting strictness, and I'm not sure in what contexts).

The problem here is that the protocol specification wasn't extremely
tight when it was first released, and the second RFC revision wasn't
very tight either, and in fact included some additional permissiveness
in the form of allowing NUL characters in text fields, which didn't
actually fix the problem with the Microsoft DHCP client, but did make it
harder for an implementor to figure out what to do.

I don't think my position on this is at all inconsistent.   I think the
protocol specification should be tight, and should require correct
behavior.   And I think that implementations should work around bugs.
An informational draft describing the places where existing
implementations deviate from correct behavior would be useful.

It might help to draw the distinction between heuristics that make the
server more permissive in the face of bad implementations, which I don't
really count as deviations from the spec, and bad implementations
themselves, which I do count as deviations from the spec.   Both are
technically deviations, but the former are generally done carefully by
people who actually understand the spec, and so they generally do not
(and certainly SHOULD not) introduce incorrect behavior when
interoperating with conformant clients.  Whereas broken clients
themselves by definition exhibit non-conforming behavior even to
conforming servers.

It's your choice as to how you want the ISC server to behave in this
situation, and I honestly don't want to be involved in that decision -
it's your baby now and you're stuck with it (*evil laugh*).

What I do very much care about though is RFC2131 and what follows.   I
applaud your wish to update and clarify RFC2131, but I would encourage
you to be conservative in your attempts to do so.   Some of the proposed
"updates" I've seen actually break the protocol, and I think it's
remarkably easy to do this, so it behooves us all to be careful.

This is particularly true because many DHCP implementations are cast in
stone at this point.   We still have RFC1541-conforming implementations.
  Changing the spec is not going to fix those clients, and there are
other clients that are in the same boat - nobody's maintaining them
anymore.    I think an informational draft talking about the issues is
going to be more beneficial than any actual protocol updates.

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 14 Jul 2006 11:07:46 -0700

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, July 13, 2006 06:35
>
*Snip!*
> behavior.   And I think that implementations
...[rbh] Ted, I agree with you that the protocol
specification should be as "tight" as possible, to hopefully
prevent misinterpretations that create divergent or
incompatible implementations, but I also think that is quite
difficult to accomplish without being extremely
prescriptive:  this opinion comes from my experience trying
to advance the proposed DHCPv4 Server MIB through the review
process.  The MIB doctor and his AD just could not accept
that RFC 2131 and related RFCs just simply *did not* specify
in precise detail every last bit of server behavior with
respect to such things as validating client messages.  I
could not overcome their assertion that such prescriptions
"had" to be in the RFCs, and they strongly objected to my
recognition that not all servers had identical behavior.

> implementations deviate from correct behavior
...[rbh]  I disagree here, because I think that is an
entirely different tack than is traditional with IETF:
documenting how differing implementations of a protocol
behave means that we could never be finished.

> themselves by definition exhibit non-conforming
...[rbh] the difficult part is determining when an
implementation is merely providing a workaround to a
specification or existing implementation problem, or is
introducing a new implementation inconsistency.  Isn't that
what bake-offs are supposed to do?

> remarkably easy to do this, so it behooves us all
...[rbh] Ted, Rob and I've tried very carefully to capture
all of the discussions that led us to proposed changes in
2131.  I know that we specifically agreed NOT to alter the
protocol just because we thought that it was broken and we
had the "correct" fix, or had some magical knowledge of how
to "improve" it.  Having said that, we recognize that we
still may not have captured all of the rationale and all of
the differing opinions from all of the discussions about the
issues with 2131, so *please* provide specific criticism of
this draft if anything in it actually "breaks" the protocol,
so we won't be still discussing this when it is time for
DHCPvNG to be rolled out.

> going to be more beneficial than any actual
...[rbh] I'll yield on this point, precisely because I'd
love to get rid of the SNAME and FNAME fields but, as you
point out, we still must contend with 1541-compliant
implementations, and DOCSIS-compliant ones as well.  Despite
your work on creating a uniform Client Identifier, I'm not
even sure that issue is entirely settled, given discussion
in the last 24 hours.

I'll stand firm about misspelled words, inconsistencies in
the text, and other matters that don't change the protocol.