Subject: Re: draft-ietf-dhc-domsrch-01.txt (fwd)

From: "Ralph E. Droms" <[email-masked]>
Date: Tue, 8 Dec 1998 12:38:45 -0500 (EST)

message: sent to [email-masked] by [email-masked] follows.
---------------------------------------------------------------------

Comments below.

Pratik Gupta
[email-masked]

Robert Elz <[email-masked]> on 12/07/98 02:55:50 PM

Please respond to [email-masked]; Please respond to [email-masked]

To:   Pratik Gupta/Raleigh/IBM
cc:   [email-masked]
Subject:  Re: draft-ietf-dhc-domsrch-01.txt

    Date:        Mon, 7 Dec 1998 12:49:32 -0500
    From:        [email-masked]
    Message-ID:  <[email-masked]>
| 1. Use of space as the delimiter.
  | The reasons why a space was chosen are:

OK, as long as the WG directly considers this issue....<<rest deleted>>

> Just to give you some history, in version-00 time,(Many months ago)
> there was a discussion about encapsulation vs the simple format. The
> working group was leaning towards the simpler form and hence the
> simpler format draft.

  | 2. NVT ASCII Vs ASCII
  | The lower half of the 8-bit ASCII code set is defined as NVT ASCII

OK I see now where this is coming from, other DHCP docs use a similar
phrase ....<< rest deleted>>

> I agree. There should be greater details about the character set. I
> will change the language to refer to the actual character set
> specified in existing RFCs for DNS.(with the exclusion of space).
> That would make it more specific and consistent.

  | 3.  Defining behavior when both domain and domain search are specified.
  | The wording can be changed. The intent was as follows:

Yes, I guessed.   I realize that there's something of a problem caused
by the way that the "Domain Name" option is specified (in 2132).
.. <<rest deleted>>

Hence, I'd suggest that this doc explicitly specify that interpretation
for the domain name option, if a domain search option is present - the
domain name option in that case should have nothing whatever to do with
name resolution, and be used solely for constructing the fully qualified
domain name of the host in conjunction with the host name option.

> Done. I will add these details.

...<<rest deleted>>

Also, did I say last time that this doc really ought to be specifing just
what a "domain search list" really is?   I intended to, but perhaps did
not.
The text suggests that rfc1305 might provide a clue, but I don't believe it
does (and it is also quite plausible to read that reference as simply
applying to the word "DNS", which is what was probably intended, and is
correct, though you really ought refer to STD13 - both 1034 & 1035).

..<<rest deleted>>

I believe that you need to specify just how the option value is to be
interpreted by the client for it to be fully defined.   That includes
things like the ordering of the domains in the list (which is used for
what, and when) and how the client might be expected to use them.
..<<rest deleted>>

but it is certainly the ultimate in flexibility (define nothing and
everything is possible).

> The explanation of domain search list is certainly needed but should a
> DHCP options draft be the location for that explanation ?  This seems to
> contradicting your earlier comment about specifying DNS behavior in this
> draft.I am going to briefly add a description to clarify the points you
> have brought up and refer to DNS & BIND book as a real reference for
this.
> The problem is that there is really no documents except that book that
> specify DNS resolver behavior for domain search.
> (I guess that makes DNS resolvers very flexible ;-) )

> I agree that more detailed specification is better for interoperability.
> The past tradition has been to specify the information on the wire
> for DHCP and left it to the application on the client side to make use
> of the information.
>

regards,
Pratik

---

From: "Ralph E. Droms" <[email-masked]>
Date: Tue, 8 Dec 1998 12:48:13 -0500 (EST)

message: sent to [email-masked] by [email-masked] follows.
--------------------------------------------------------------------

Sorry for the late follow up.
There are a number of issues here.

1. Use of space as the delimiter.

I agree that if we were to consider the most general solution for a domain
name that contained an arbitrary set of characters, your method is more
appropriate. But that is not the case and may not be for a significant
period of time.
The reasons why a space was chosen are:

a. Existing servers that can send strings can send this option without
changes.
b. I assert that domain names visible to an end user for resolution will
not contain a space.
c. When such a change is done ( I believe it will be done in the context of
Internationalization and will have a much broader impact  on all string
options. The implementations will have to be upgraded in a number of areas
to support network code page). At that time, the DHCP option versioning
system can be used to use the same option with the more complicated
solution.

2. NVT ASCII Vs ASCII

The lower half of the 8-bit ASCII code set is defined as NVT ASCII ( Most
significant bit is 0).  I am  expecting domain names not to use characters
that use the upper half of the code set.  For domain names it is really
even a subset of NVT ASCII  . I can probably  add a reference to the
current  DNS RFCs to obtain the actual character set. at the very least it
is NVT ASCII.

3.  Defining behavior when both domain and domain search are specified.

The wording can be changed. The intent was as follows:

Today, BIND based resolvers pick the domain or the search keyword that
appears last in the resolv.conf file. Other implementations may do it
differently. I propose that the DHCP client follow a simple rule, because
then there can be interoperability issues for 2 clients getting the same
set of options. Thus, this is was  meant as a recommendation to aid DHCP
interoperability rather than to specify DNS behavior.

4. The draft format etc. related issues have been fixed in the -02 version.

regards,

Pratik Gupta
[email-masked]

Robert Elz <[email-masked]> on 11/18/98 06:26:48 AM

To:   Pratik Gupta/Raleigh/IBM
cc:   [email-masked]
Subject:  draft-ietf-dhc-domsrch-01.txt

I just saw draft-ietf-dhc-domsrch-01.txt and I have a suggestion/request.

The current (initial I assume, as this is just a -00 draft) spec is ...

   The code for this option is TBD, and its minimum length is 2 bytes.

             Code     Len       Domain Names in Sequence
           +-------+-------+-------+--------+---------+-
           |  TBD  |   n   |  d1   | 0x20   |   d2    |
           +-------+-------+-------+--------+---------+-

   Where d1 & d2 are domain names specified as NVT ASCII strings. An
   ASCII space character (0x20) is used as a separator between the
   domain names.

I would strongly suggest avoiding the "space is a delimiter" technique,
and making the domain names (d1, d2) be explicitly counted.  That is ...

             Code     Len       Domain Names in Sequence
           +-------+-------+-------+--------+---------+-------+
           |  TBD  |   n   |  ld1  |   d1   |   ld2   |   d2  |
           +-------+-------+-------+--------+---------+-------+

Where d1 and d2 are domain names, and ld1 and ld2 give the lengths of
those domain names.

The point of this is that domain names are not NVT ascii strings (certainly
not NVT, which implies all kinds of noise related to the telnet protocol
and handling of particular character sequences) - and while ascii is the
predominate base for domain names that are in use right now, it is entirely
possible that it will change to something a little less restrictive well
within the lifetime of this protocol (option).  Certainly the domain name
system doesn't need to change at all to allow that.

So, permit the domain names themselves to be anything at all, and use
explicitly counted strings, rather than specifying ascii and forcing space
to be excluded from the set of characters that can be in a domain name.

Also, from this I can't tell if it is intended that the search list
be exactly 2 domain names, or whether it is intended to be a list of
arbitrary (packet and option length considerations constrained of course)
numbers of domain names for the search list.   That needs to be explicitly
specified.

Slightly less importantly,

  DHCP Client Behavior

     The DHCP client will use this option to create a domain search list
     for name resolution.

That's fine.   But this ...

                   If a DHCP client is given both a Domain Name
      Option and a Domain Search Option, the Domain Search Option  will
      take precedence.

I think is attempting to specify the way the BIND resolver works, and has
no place anywhere here.   The first sentence is just fine to specify what
the search option is intended to do (though something ought specify the
how the order of the domain names is used, so we don't get some people
trying the last first, rather than last).

And even less important, delete the 3/4 of a page that defines MUST SHOULD
etc - none of those terms are actually used in the text of the doc,
defining
them seems like rather a waste of space.   If, at some stage, any of those
terms were to be needed, a simple reference to RFC2119 (BCP14) would be
a better way to have them included.

kre

ps: I'm not on the DHCP list, so if there's any point getting a reply back
to me, you'll need to include my address explicitly.

---

From: "Ralph E. Droms" <[email-masked]>
Date: Tue, 8 Dec 1998 12:50:03 -0500 (EST)

message: sent to [email-masked] by [email-masked] follows.
-------------------------------------------------------------------
    Date:        Mon, 7 Dec 1998 12:49:32 -0500
    From:        [email-masked]
    Message-ID:  <[email-masked]>

OK, as long as the WG directly considers this issue, if it is decided that
DHCP will be unable to send domain search lists containing space, then I
won't object.   I don't personally see it your explanations as all that
convincing, but nor do I expect that the demand for space in a domain name
in a search list will become so great ever that lacking the ability to
transmit it will be too much of a burden.

I would note however that none of the other (related) options have any
such restriction that I can find.   There's nothing to prevent either
the host name, or the domain name, containing spaces (or any other
character - they're not even restricted to "NVT" I don't believe).

  | 2. NVT ASCII Vs ASCII

OK I see now where this is coming from, other DHCP docs use a similar
phrase - note however that rfc2132 (at least) uses the phrase "from the NVT
ASCII character set" mostly, which is approximately correct (appending
"character set" limits the scope of "NVT ASCII").    If you're going to
continue with that (misguided I believe) practice, at the very least,
give some kind of definition of, or pointer to a definition of, NVT ASCII.
When 2132 is next revised, it needs the same.   As both docs stand now,
they simply assume that the reader knows what "NVT ASCII" means.

I'd suggest simply explicitly defining exactly what you mean, which is
not NVT ASCII as defined in the Telnet Spec (rfc854) anyway, as you're
excluding space (0x20) from the set of legal characters (as it is now
anyway).

Yes, I guessed.   I realise that there's something of a problem caused
by the way that the "Domain Name" option is specified (in 2132).   In
3.17 of that, it appears that the domain name option is intended as a
(one element) domain search list (much like BIND had before "search" was
added to resolv.conf).   On the other hand, it is very easy to draw an
inference from section 3.14 (Host Name Option) that the intent of the
domain name option is really to specify the domain in which the host name
given by that option is to be found (though the host name is also permitted
to be fully qualified).

My experience is that the latter of those interpretations is most common,
and that the domain name option is used to specify the host's home domain,
which need not have anything at all to do with how it does DNS host
resolution (of other unqualified host names).   This allows the domain
name to be configured once (or infrequently anyway) in the DHCP server
configuration, and just the host name part (sub-domain) of the fully
qualified host name to be specified for each host (or perhaps each address,
however it is done).

Certainly don't just say "take precedence".   What does that mean?  That
the domain search option is used first, and the domain name option after
that?   It easily could, but by analogy from BIND's behaviour, I don't
think that is what you intend.

what a "domain search list" really is?   I intended to, but perhaps did not.

I fully agree with your intent expressed in this message that it is important
that all clients interpret the option the same way, otherwise configuring it
will be almost impossible.   But, if the sole definition of the option is
that it sets the client's "domain search list" then I don't see how that can
be achieved.   Some clients might very well use their object called the
"domain search list" for purposes quite unlike it is used on other hosts.

Then again, I'm no DHCP expert (I'm coming at this more from the DNS
part of the world), perhaps it is normal in DHCP to simply specify a
way for the server to return some potentially useful data to the client
and then leave it up to the client to use it however it prefers?  That
would be potentially more confusing, and harder to configure (some clients
might want the domain name search option in one order, others in the
reverse order, to achieve exactly the same effect), but it is certainly
the ultimate in flexibility (define nothing and everything is possible).

kre

ps: Once again, I'm not on the DHCP list I don't believe, so please include
my address in any reply you want me to see.   If the Reply-To header works
correctly for you, that should just happen - but please do verify it.