Subject: [dhcwg] (*sigh*) draft-ietf-dhc-dhcpv6-opt-dnsdomain

From: "David W. Hankins" <[email-masked]>
Date: Mon, 16 Oct 2006 11:07:22 -0700

One of the rediculous reasons this draft is back on our plates is
over the wording of section 2:

   The domain suffix in the 'domain suffix' field MUST include only one
   item, and MUST be encoded as specified in the section of RFC3315 
   titled "Representation and use of domain names".

'item', we're being told, is suboptimally vague.

Upon thinking more upon this, I suggest a slight reword at the
same time as clarifying the term:

   The domain suffix in the 'domain suffix' field MUST be encoded as
   specified in (unknown non-recursive new reference), except that it
   SHOULD only include one domain name, being a series of labels
   terminated by exactly one root label.

   If more than one root label is present, implementations MUST select
   the first name, ignoring any subsequent labels.

My reason for this blatant change in normative language...

It's my understanding that the 'atom', if you will pardon my use of a
term I defined myself in a recent document, for "DHCPv6 domain names"
currently in use by deployed software is a list of an arbitrary number
of root labels.

Obviously that understanding has the potential for being flawed.

But if not, then day 1, when no software has formal support for
single-root-label limitations, operators will be able to configure
their servers and clients to use this already commonly used format,
the rfc3315-defined-one with no extra limits, and it will appear to
work.

This represents a day 1 divergence from the 'MUST' inter-operability
requirements for this option, depending entirely on operator use,
and I can forsee some inter-operability failure if there's a reliance
on it.

I think it's a lot cleaner if we accept that some software is going
to let people configure more than one name here - a list of names
just like any other 3315-formatted-domain-name-field - and only place
a restriction on how much of the consumed contents may reasonably be
acted upon ("...MUST ignore the rest").

But as I didn't argue with the draft's wording before, I'm not
fixed on this point.

Particularly if I'm wrong about the implementations out there (not
ours).

It's just a suggestion.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Tue, 17 Oct 2006 15:23:33 +0200

David W. Hankins wrote:
[...]
> But as I didn't argue with the draft's wording before, I'm not

I think I agree. Ideally the server shouldn't send multiple, but in 
order to keep it simple, we can leave out the special restriction on
syntax and content of the option itself.

Stig

PS
Reminds me of how some dhcpv4 implementations have misused the 2132 
domain name option to pass a list of domains as a search path...

> ------------------------------------------------------------------------
>