Subject: Re: draft-ietf-dhc-dhcp-dns-09.txt

From: Mark Stapp <[email-masked]>
Date: Wed, 7 Apr 1999 14:45:57 -0400 (EDT)

Robert,

Thanks again for your comments. I've made a few replies/assents/mea culpas
inline. I've done some snipping, so please feel free to correct me if I
over-did it.

At 09:55 PM 3/27/99 +1100, Robert Elz wrote:

[snip]

>
>  | The fqdn option is a DHCP option, and it's currently an ASCII string like
>  | the existing host-name and domain-name options.
>

[snip]

>
>Unless there's a very good reason to use text formats (in which case the
>actual text format to use needs to be precisely stated, don't just assume
>it is "obvious", it isn't) using the DNS binary format in any protocol which
>is basically carrying binary encoded date (which DHCP certainly is) seems
>like an obvious "right" choice to me (even if it does mean an extra few lines
>of code to deal with it).
>

Yes, this was clearly a shortcoming, and there's consensus that I need to
allow for this encoding. I've proposed (in a reply that went to the dhcp
list, and that you probably didn't see) using the next bit in the 'flags'
field as an indicator that the fqdn is DNS-encoded. In that case, would it
be reasonable to allow a host to send a single element or label as an
indication that it knows only the most-specific part of its domain name,
and would like the DHCP server to append the rest?

>  | A server can reply to a client's request with a NAK, and the client will
>  | give up its current lease and attempt to acquire a new one. If that
>occurs,
>  | the server should clean up the DNS.
>
>Ah, I see what you mean, this occurs only when a client is attempting
>to confirm (and usually extend) its lease.   I think it would not hurt to
>add something to make that clear, lest anyone be tempted to read the text
>as implying that servers have some mechanism for arbitrarily terminating
>client leases, without client co-operation.   (It is a thing I occasionally
>see people asking how to do, since it is basically impossible to achieve,
>avoiding anyone being given a "but see RFCnnnn where it says ..." type
>argument).
>

Will do.

>
>  | The sentence you've quoted appears immediately after this one: "The
>  | following describes behavior of a DHCP client that implements the Client
>  | FQDN option."
>
>Sure, but "implements" and "desires to use" aren't the same thing.
>
>  | Sites whose administrators don't care about this option can
>  | use clients which don't implement it.
>
>That is unreasonable.   As you say ...
>
>  | Hopefully, the cooperation that the
>  | draft describes is useful, and clients will implement it.
>
>Yes, hopefully clients will implement it.   Hopefully all clients will
>implement it.   That doesn't mean that all sites will desire to use it.
>And if all clients implement it, the "use a client which doesn't implememt
>it" option for the site goes away...
>
>Avoid over specification - unless there is a very good operational reason
>for a MUST, don't give one.    The only reason I can see for requiring
>the client to include the FQDN option is when it is requesting the server
>to do something with the data.   In that case, obviously the server needs
>the value from the option to be able to function.   If the server isn't
>required to do anything with the fqdn, then there's no reason for the
>client to supply the data - regardless of whether or not the clients
>implementation supports it, and regardless of what dynamic dns interactions
>the client may intend to make.
>

Since the server is going to perform the PTR update, and the PTR update
needs to know the name that the client is going to try to add, the client
MUST tell the server what it thinks its name is. The draft could require
that the client send the existing host-name option instead, but that
doesn't offer the opportunities for the server to reply with additional
information like that carried by the fqdn option's 'flags' and 'rcode' fields.

In addition, I can envision a configuration in which the DHCP servers are
configured to perform updates for clients unless the clients ask to perform
the updates themselves. In organizations with a mixture of update-capable
and -incapable clients, or during a period of transition after the general
release of updating clients, it would save DHCP and DNS servers work if the
DHCP clients advertised their intentions. The other operational case that
motivates this is that of sites which intend to prohibit updates from DHCP
clients. In those sites, servers need to be able to 'override' the client's
offer to perform the A record update, as described in the draft's section
3.1, last para. 

Given those three cases, can the specification remain a MUST, or should it
be a SHOULD?

>  | Dangling names are seen as a very real administrative problem in many
>  | organizations.
>
>Sure, and they're seen as no problem at all in others.
>
>  | There are popular clients which do release their leases, and
>  | their behavior needs to be accounted for in the draft.
>
>Yes, I agree.
>
>  | If a client accepts responsibility for its name, it should make every
>  | effort not to leave the name behind when it's no longer in use.
>
>That's a value judgement, in what should be something left to individual
>sites to determine which they prefer.   Some certainly prefer that stray
>names be deleted when they're not in use.  Others may prefer that the names
>be left as they were until they need to be updated to reflect the next
address
>they obtain.   Others may prefer that the A record be deleted, and replaced
>by a TXT record (or something) as a placeholder, so the name is retained, but
>the old A record isn't.    This is all for local site determination, and
>need not be specified by this draft.
>

The 'clean up after yourself' specification is a SHOULD, not a MUST. If
this becomes a MAY, can I at least add a sentence to the effect that
vendors are encouraged to clean up thoroughly?

[snip]

>
>  | Do you mean that the text descriptions in 3.4.1 and 3.4.2 aren't
complete,
>  | or just that they aren't as clear as an example would be?
>
>What started me wondering, was in attempting to determine whether the
>server could provide any information which would assist the client in
>sending the data for the fqdn option.   There's the easy case where the
>client has simply been configured, via some other means, with its desired
>fqdn (which may happen for workstations, and similar things, which have a
>user sitting in front of them).  That is pretty straight forward.   But for
>devices with no human around to configure the fqdn, but where the device
>might just know enough of what it thinks it ought be called as a hostname
>at least.   But the domain name in which that name ought be installed
>is likely to be unknown.   The question is whether the server might supply
>a domainname option in the dhcpoffer response to the dhcpdiscover,  and
>then the client construct its full name for the fqdn in the dhcprequest
>packet from that domain name.    Is that reasonable, simply wrong, ...
>

Ah, I think I understand the issue better now. Section 3.3, para. 5 says
that the server MUST reply with a copy of the data the client sent. I'll
revise that to try to allow for the case where the server has more
knowledge about the more-general parts of the DNS domain that the client is
in. The server may need to tell the client everything, in fact: one DHCP
administrative policy may be to configure client's fqdns at the DHCP
server, and avoid per-client configuration. In that case the server may
need to be able to communicate all of the host-name info to the client.

Mark