Subject: Re: WG Last Call for "DHCP Relay Agent Information Option" I-D

From: "Michael W. Patrick" <[email-masked]>
Date: Tue, 01 Feb 2000 13:37:29 -0500

Folks,

I don't mind if the subnet mask option is moved to a separate draft.
At the last IETF meeting, however, there was support both publicly and
privately to keep it in. 

Is there anyone in the WG who would OBJECT to removing subnet
mask sub-option for the initial relay agent option draft?
In particular, Bernie Volz, Mike Carney, and Kim Kinnear, could
you respond and give your opinion? Can you live without the
subnet mask sub-option in the initial draft?

-mike

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

> I respectfully request that the draft be withdrawn until my
> objections to it, which I have expressed previously and in detail,
> have been addressed.

> To summarize, I believe that the implementation of the subnet mask
> suboption has not been described completely, and is likely to result
> in multiple non-interoperable implementations.  The solution that I
> propose is to seperate the subnet mask suboption into its own draft,
> and try to do it justice there.  I think it's a reasonable idea, but
> it needs to be fleshed out some more.  I don't want to see the Relay
> Agent Information Option draft delayed until we have a better
> specification for the subnet mask suboption.

> In case anybody's thinking "aw, it's not such a big problem, why are
> you so worried," please remember all the discussions we've had about
> seemingly subtle points in RFC2132 like what the DHCP parameter
> request list option does.  The subnet mask suboption clearly has
> wider implications, and yet the description of it is equally brief -
> all that's described is the format of the option, and the meaning of
> the bits in it.  No requirements are placed on either the server or
> the relay agent.  This is a recipe for disaster.

> I'm really sorry to be a stick-in-the-mud about this.  Michael
> Patrick has worked hard on this draft, and deserves some
> satisfaction.  It is partially my fault that we're at the point we
> are at - if I had carefully read the several previous versions of
> the draft in which the suboption was added, I could have raised my
> objections sooner, and perhaps we could have fixed the wording in
> time for the subnet mask suboption to be in the draft.  However,
> this fact is not a reason not to do the right thing - it is merely
> evidence of a failure on my part, for which I apologize.

> 			       _MelloN_

---

From: Bernie Volz <[email-masked]>
Date: Wed, 2 Feb 2000 10:08:13 -0400

Oops:

>Basically, using ISC configuration like syntax, one might have:
>	template subnet 255.255.192.0 {
>		range 2 1022;
>		option routers 1;
>	}

That 255.255.192.0 should have been 255.255.252.0. (That's one reason I
like the subnet mask-length better than these darn masks.)

- Bernie

---

From: "HIBBS, BARR (SBCSI)" <[email-masked]>
Date: Wed, 2 Feb 2000 13:44:38 -0800

It's my opinion that most of the interoperability and usability problems
that have arisen with DHCP are the result of wording in the RFC's that
permit implementors to assume the intent of the authors/editors.  This is
not to say that there aren't great areas where the appropriate wording is
"this is an implementation or local administrative matter," but rather to
suggest that the converse simply isn't appropriate.  That is, omitting some
clarification when an RFC says MAY or SHOULD or MAY NOT or SHOULD NOT can
certainly lead to trouble.

An example (that we've beaten nearly to death already, so please don't start
a new thread about it!) is the behavior of a server when a client changes
subnets:  is the server to replace (that is, expire) the existing lease or
retain it as valid until the lease lifetime expires?

I think most of us would agree that some clarification is appropriate, even
if that clarification is "a matter for local administration."  By explicitly
including a statement, an implementor, network architect, or server
administrator should be alerted to a possible area where different servers
might behave in diverging manners.

Okay....  I really have a problem with the assertion that address pools can
be created dynamically, apparently by garbled packets.  This seems to flow
directly from the assumptions about server behavior, thus, that is a
candidate for an explicit statement of implied behavior, so some revision of
the text is appropriate.

If we can't quickly resolve this, then Ted's suggestion to extract it from
this draft and create a new one may be the best approach to avoid delaying
the rest of the draft during Last Call.

--Barr

---

From: "HIBBS, BARR (SBCSI)" <[email-masked]>
Date: Wed, 2 Feb 2000 15:15:20 -0800

> suggest that the converse simply isn't appropriate.  That is, omitting
> some clarification when an RFC says MAY or SHOULD or MAY NOT or SHOULD NOT
> can certainly lead to trouble.
> 
> An example (that we've beaten nearly to death already, so please don't
> start a new thread about it!) is the behavior of a server when a client
> changes subnets:  is the server to replace (that is, expire) the existing
> lease or retain it as valid until the lease lifetime expires?
> 
> I think most of us would agree that some clarification is appropriate,
> even if that clarification is "a matter for local administration."  By
> explicitly including a statement, an implementor, network architect, or
> server administrator should be alerted to a possible area where different
> servers might behave in diverging manners.
> 
> Okay....  I really have a problem with the assertion that address pools
> can be created dynamically, apparently by garbled packets.  This seems to
> flow directly from the assumptions about server behavior, thus, that is a
> candidate for an explicit statement of implied behavior, so some revision
> of the text is appropriate.
>