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

From: "Ralph E. Droms" <[email-masked]>
Date: Wed, 18 Nov 1998 07:32:13 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------
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.