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

From: [email-masked] (by way of Ralph Droms <[email-masked]>)
Date: Tue, 13 Apr 1999 20:44:05 -0400 (EDT)

message:sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------
    Date:        Wed, 07 Apr 1999 14:05:40 -0400
    From:        Mark Stapp <[email-masked]>
    Message-ID:  <[email-masked]>

Apologies for taking so long to reply.

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

No, please don't do that.   Just decide (the WG decide) whether a simple
ascii string (ie: with restrictions on what characters will be allowed, etc)
will really be adequate, or not, and define the thing one way.   Making this
kind of thing optional is just asking for trouble.

Just please do define whatever you decide (for a DNS packet encoding you
could refer to 1035) - don't just assume that what is intended is obvious.
That is, for an ascii encoding, make it clear that dots separate the labels
in the FQDN, and indicate whether there is to be any way to include a dot
in a label (the DNS allows it, but that doesn't necessarily mean you must).

If you decide not to require the FQDN option to actually contain an FQDN,
but just its leading part (client: "My host name is "spock" but I don't
know what universe I am in...) then you will need to specify some kind of
rule for the server to be able to determine what is a FQDN and what is not.
If that is to be as simple as "one label, no dots is nota FQDN, anything
else is", then say so, and simply restrict it so that the client can't
say "my name is spock.enterprise, but I don't know what universe I am in".

Write down your assumptions, and try to make sure that you're covering all
the cases (by explicitly covering all possibilities, by prohibiting anything
but what you want to allow, or by saying "everything else is undefined").

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

If you're asking me for some reason, yes, sure, I think that would be
reasonable (though I don't see how the encoding of the field is relevant
to that).   Just specify it if this is to be allowed behaviour.

  | Since the server is going to perform the PTR update,

Says who?   Maybe no-one is.

  | and the PTR update needs to know the name that the client is going
  | to try to add,

Why?     And if the client is going to add two or three names (perhaps
foo.example.tld www.example.tld ftp.example.tld ...) then it would have
to supply all of those in the fdqn option (somehow) so the server can
stick them all in the PTR record?

The name that the client thinks it is called (and wants to be called)
need not have any relationship at all with the name that has been assigned
to the IP address (by the PTR record).   That name should (ideally, and

practically because of the way the world currently implements such PTR
security as exists) have a DNS entry with an A record that returns the
address that was used to construct the PTR record, but there is no
requirement that that name be the one the client likes to refer to itself by.

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

Then the server should do that.   If the client hasn't given a name, the
server will have to use one of its choosing.   If you require the FQDN
option to be present, then clients will either send one, with a FQDN in it
that they know the server will be unable to update, or they will send one
with a random junk name that they don't care about, and take no notice of
what the server does with it.    (This is those clients whose code base
understands the option, but which don't want the server making any DNS
updates at all).

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

Fine, you can explain that, and request that clients co-operate.  This
isn't a justification for demanding it however.

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

Huh?   So if your site is such a site, and I bring my laptop and visit,
you're planning on having your server tell my client that my client is
not permitted to update its name in my zone file?   And you think your
server is going to be permitted to do that?

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

I'd not have it a requirement of any kind (a MAY would be right, but makes
no sense here - it's an option, clients use it when they want to - that may
be most of the time, that's fine, but there's no need for any kind of upper
case noise language to require it).

However, you don't need my agreement on this - the WG ought to be (and perhaps
is, I don't know) discussing the issue, and deciding what is the correct
behaviour.   I just read the draft and pointed out a few things which looked
a bit odd to me.

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

"vendors" is the wrong word, but yes, clients & servers ought clean up
exactly as much as their owners want them to do.   Mechanisms to do that
certainly ought exist in the code, so it can be enabled if desired, but
nothing ought be forcing me to make use of those mechanisms.

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

No, while that is all fine, it isn't what I was getting at.

I'm no DHCP expert, but as I understand it, the general protocol functions
as ...

	client broadcasts DHCPDISCOVER
	server(s) return DHCPOFFER
	client picks an offer and sends DHCPREQUEST
	server sends DHCPACK

(in the normal case anyway, and assuming a client starting with no
knowledge at all - I know that most for many exchanges, only the latter
two packets are actually used).

Now, as I understand this FQDN proposal, the FQDN option goes in the
DHCPREQUEST packet (and the server returns data about what happened with
it in the DHCPACK).

What I was wondering was whether the server could (or should perhaps)
include in the DHCPOFFER data that the client might use in constructing
the FQDN option that it includes in the DHCPREQUEST.   If so, it might
be worth mentioning that as a possibility in the draft - so servers know
it is reasonable to include that data, and clients know what they can do
with it (and I'd certainly say "can" not "must").

That's quite different from whether the server can take the FQDN that
the client included in its DHCPREQUEST and change it in any way before
returning the FQDN option to the client in the DHCPACK (which is another
thing which can be done - it just isn't what I was asking about).

Now it is entirely possible that you are not understanding what I'm attempting
to say because of some lack of knowledge of mine about how either the
DHCP protocol works, or about the intent of the FQDN option.   If it is the
former, I'm not asking that you educate me, that isn't the role of the WG,
you could just (collectively) say "he doesn't understand DHCP" and ignore me.
That's fine.   On the other hand, if I haven't been able to follow the
intent of the draft, that might indicate that it needs some aditional
clarification.   Or third, it may just be that my earlier messages have
not been close to clear about what I'm meaning (which would not be unusual
for me).

kre