Subject: re: [dhcwg] dhc WG last call on DHCP FQDN option draft

From: Richard Barr Hibbs <[email-masked]>
Date: Fri, 25 Feb 2005 13:45:25 -0800 (PST)

Ralph, et alal

I support accepting the document, mostly to bring it
finally to completion after all these years.  Mark and
Bernie have done a good job of bringing this about.

There are, in fact, a few parts of the document with
which I don't fully agree:

"Clients MAY send the Client FQFQDNption, setting
appropriate Flags values, in both their
DHDHCPDISCOVERnd DHDHCPREQUESTessages.  If a client
sends the Client FQFQDNption in its
DHDHCPDISCOVERessage, it MUST send the option in
subsequent DHDHCPREQUESTessages though the contents of
the option MAY change."

I have never agreed with this, although I recognize
the possibility.  My great reservation is that a
DHDHCPerver and client may significantly disagree over
the assignment of an FQFQDN user Mike might want more
than anything else for his system to be known as
"Mike's PC" while the network administrator prefers
"370ThThirdStRm9."  So the network administrator might
prpreonfigure DNDNSnd DHDHCPith the
FQFQDN370ThThirdStRm9.papacbellet," and DHDHCPith the
separate host name "370ThThirdStRm9" and domain name
"papacbellet" only to find that user Mike locally
changes his host name to be "Mike's PC."

This has now suddenly become a discussion about local
administrative policies, an area where IEIETFisely
chooses not to play.  I strongly feel that this option
should require that an FQFQDNe composed exactly of the
host name concatenated with the domain name, subject
to local administrative policy enforcement.  To that
end, the draft should reinforce the idea that
consistency among various options that involve naming
is a Good Thing (TM), and perhaps explicitly state
that both a DHDHCPnd DNDNServer can apply
administrative policies to reject or ignore a client's
request for changing the FQFQDNn the fly.

I'm not sure there is much that can be done to "solve"
the confusion that might cascade from a client being
allowed to change FQFQDNsost Names in some
circumstances, although there are probably many good
reasons why an administrator might desire a client to
be more self-configuring (detecting name collisions
when two or more users try to change their
hohostnameso be "Mike's PC.")

Again, I support accepting this draft as is to avoid
re-opening what is in all likelihood an insoluble
policy matter.

--Barr

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Feb 2005 16:28:07 -0700

Barr, requiring in an internet draft that a DHCP client behave in a 
certain way if commanded to do so by the server is really policy, not 
mechanism.   It's only mechanism if there's a way to override that 
behavior on the client, or if we don't specify a mechanism like that.   
To say that site-wide policy is the only kind of policy that there can 
be is beyond the scope of what the IETF generally tries to do in 
standards specifications, and certainly beyond the scope of DHCP.   
DHCP provides a mechanism whereby clients can discover network 
configuration parameters appropriate to their network.   We don't state 
any policy about what should be done with these parameters, other than 
to the extent that we must in order to specify the protocol whereby 
clients and servers communicate.

So while I sympathize with your wish to be able to impose site-wide 
policy using DHCP, I would argue that it is out of scope for this 
working group.