Re: [dhcwg] Option 119 (Domain Search Option) and Option 15 (Domain Name Option)

[Alfred Hönes <[e-mail]>]

David,
in response to my last message, you wrote:

>>  I guess everybody once saw RFC 3397 as a functional replacement
>>  for option 15, since the DSL (#119) allows a compact representation
>>  of multiple domain names by making use of domain name compression
>>  as in the DNS protocol.  (This pretty much matches your previous
>>  comment on space conservation.)
>
> Not precisely.  There is some value in informing some clients of
> their 'domain name', as being separate from their domain-search
> list.  ...

Yes, there's indeed value in that (iff it is clear that the DHCP
client is configured with a bare host name), and I initially also
believed to recall that #15 served this purpose.

But looking for #15 in RFC 2132, I found in Section 3.17:

|  This option specifies the domain name that client should use when
|  resolving hostnames via the Domain Name System.

It says "resolving hostnames", not "configuring the local domain name".

The domain search list is discussed in RFC 1034, which clearly
predates RFC 1533, the predecessor of RFC 2132.  Therefore, I assume
that the authors were aware of the function of the search list and
supplied a simple mechanism to fill in a single entry.

> Although at one time these two were one in the same (and in time,
> people began to identify with it only for domain search behavior),
> the domain name can actually feed other behaviors, and is useful
> to some clients separately from their domain-search configuration.

Indeed:

Digging deeper into history, I found that #15 initially was defined
in RFC 1395 with exactly the "configuring the local domain name"
semantics: "Specifies the domain name of the client ...".
This has been copied literally in the successor of RFC 1395, RFC 1497.

But clearly the description has changed in a significant way in the
next update step of the scpecification, from RFC 1497 to RFC 1395.

So the semantical shift you describe has been documented, and it looks
like we are now in a position where it is questionable to interpret
#15 as a method to set the local domain name for hosts only configured
with a relative domain name, as also described in RFC 1034.


Regarding the other points in my message: That was a strawman
collection of things that would need to be specified in the
update to RFC 3397 that Ted Lemon had suggested in his primary
response to the #15 vs. #119 question.

If requirements I had listed are seen as sufficiently specified
(otherwise/in general), a precise pointer to that specification
would serve the purpose, of course.

If, on the other hand, a requirement deemed useful cannot be
expected to be supported directly by DHCP server implementations,
but by proper configuration, it could easily be carried forward
in that manner, as a caveat to server admins, in a potential update
to RFC 3397.


Based on your words on #15, it now seems worth to _first_ clarify
its role unambiguously.  Without this clarification, an improved
specification for #119 cannot be conceived.
If #15 really is back to RFC 1395 semantics (local domain of DHCP
client, to be appended to his bare host name), no overlap with #119
exists, and RFC 3397 might be precise enough.

Kind regards,
  Alfred.