RE: [dhcwg] Host Name option considerations draft

> -----Original Message-----
> From: Carl Smith
> Sent: Wednesday, March 06, 2002 22:35
>

<*Snip!*>

> > > 	That's not the intention.  First, a clarification:  the point is
> > > that if a client sent the Host Name option, it MUST accept
> the value that
> > > the server returns.  Upon further reflection, perhaps a bit
> more should
> > > be said:  if a client requests a Host Name via the Parameter
> Request List,
> > > it MUST accept the value the server returns.
> > >
> > ...look at what you wrote, again:  in the first part you specified the
> > client sending the Host Name OPTION and in the second,
> requesting the Host
> > Name in the Parameter Request List -- the two are not the same
> thing, which
> > is where my disagreement arose.
>
> 	Yes, I know they're not the same thing (which is why I wrote that
> ``perhaps a bit more should be said'' when I extended it to include the
> Parameter Request List.  There are now two questions to consider
>
> 	-  if a client sends a Host Name option and the server responds with
> 	   a different name from the one the client requested, what must the
> 	   client do?
>
...this presupposes that (1) the client sent its preferred Host Name to the
server, but (2) did not include the Host Name option in the parameter
request list.

> 	-  if a client requests a Host Name option be returned,
> must it accept
> 	   the value the server returns, or choose to use its own?
>
...this case is that the client (1) did not send its preferred Host Name to
the server, but (2) did include the Host Name option in the parameter
request list.

> The language in the draft addresses only the first of these:  if
> a client sends
> a Host Name option and the server responds with a Host Name
> option, the client
> needs to use the value the server returned, not continue the use
> of the one it
> (merely) requested.
>
...this begs the question:  "Should a server return a value for an option
which is neither mandatory nor requested by the client?" as well as "If a
client sends the server a suggested value for Host Name, is that equivalent
to an entry for Host Name in the Parameter Request List?" and finally "If
the server sends an unrequested [and non-mandatory] option, is the client
obligated to use the value?"

> 	The second one is more tenuous, but I believe the same
> argument can be
> made:  by requesting a Host Name option be returned, is the
> client agreeing to
> use the value or is it just hoping to get lucky?  If it's the
> latter, then the
> client should instead simply ask DNS what name corresponds to the
> address the
> server leased it.
>
...I agree:  if the client explicitly requests that a Host Name option be
returned by including it's option number in the Parameter Request List, then
it is obligated to use the returned value if it decides to accept the
offered lease.

We must answer the question about equivalence of Parameter Request List and
suggested Host Name:  if a suggested name implies a request for Host Name,
then I agree that the client should accept the name offered by the server or
decline [Not!  Just teasing after the other ongoing discussion...] the
offer.

<*Snip!*>

> > ...and I've also seen instances where clients certainly don't
> follow these
> > guidelines, but expect that option values won't change between
> an offer and
> > an ack.  A reasonable expectation is that certain values (e.g.,
> Host Name
> > and Domain Name) will not be changed by the server.
>
> 	I'm happy to add something to this draft that says the Host Name's
> value should not change, but as you suggest the problem is larger
> than just
> one or two options.
>
...that is a good example of a "best practice" with respect to Host Name and
yes, this is like opening a can of worms.....

--Barr

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg