Subject: Re: Last Call: 'Domain Suffix Option for DHCPv6' to Proposed Standard (draft-ietf-dhc-dhcpv6-opt-dnsdomain)

From: Frank Ellermann <[email-masked]>
Date: Tue, 26 Sep 2006 22:15:46 +0200

The IESG wrote:
 
> <draft-ietf-dhc-dhcpv6-opt-dnsdomain-03.txt> as a Proposed Standard

What's a "domain suffix" ?  I don't see or missed it in 3315
and 4361.  LDH labels with a TLD maybe ?  Are they guaranteed
to be "valid" in some ways, could a host "name" send mail as
"name.suffix" ?  Could it use "@name.suffix" in Message-IDs ?
Does the IPv6 it got point to "suffix" ?

Sorry, probably that's all obvious, but where is it defined ?

Frank

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Fred Baker <[email-masked]>
Date: Tue, 26 Sep 2006 13:38:59 -0700

On Sep 26, 2006, at 1:15 PM, Frank Ellermann wrote:

> Sorry, probably that's all obvious, but where is ["domain suffix"]  
> defined ?

At the Verisign site. It is the new-speak for use when all us ancient  
geeky types would prefer "TLD".

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 26 Sep 2006 23:25:32 +0200

Fred Baker wrote:

 ["domain suffix"]
> It is the new-speak for use when all us ancient geeky types
> would prefer "TLD".

I thought it's some new kind of DHCP builtin DynDNS service.

If it's a TLD I'm perplexed why that would ever change for a
given DHCP server.  And for clients of different servers the
TLD isn't enough to know where they are. 

Confused: Frank

---

From: Stig Venaas <[email-masked]>
Date: Wed, 27 Sep 2006 09:19:23 +0200

>>It is the new-speak for use when all us ancient geeky types

It's what a client might add to it's hostname to form an FQDN. Typically 
also used as domain search path by many systems if no explicit search 
path is specified. Often also called "domain name".

> TLD isn't enough to know where they are. 

For a given DHCP server and a given client, this would normally not 
change. The draft doesn't say that it might change either. However, a 
given server might give different domain suffices to different clients.

Stig

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Sep 2006 04:13:02 -0400

--On Wednesday, 27 September, 2006 09:19 +0200 Stig Venaas
<[email-masked]> wrote:

> It's what a client might add to it's hostname to form an FQDN.
> Typically also used as domain search path by many systems if
> no explicit search path is specified. Often also called
> "domain name".

Whoops.  It is what a client might add to a hostname to form an
FQDN if, and only if, that hostname appears as a second level
domain.  But hostnames as registrations in TLD zones are not
especially common, MX records for mail and short forms for web
servers notwithstanding.  The typical host name looks more like
abc.example.com or xyz.example.co.uk.  

For example, note that to get an FQDN from Frank's hostname
("xyzzy") one needs to add "claranet.de", and not "de", but the
latter is all that is permitted by this proposal.  If software
Frank was running assumed it could use this DHCP option to
construct an FQDN from Frank's hostname, Frank would end up with
xyzzy.de, which is probably not what is intended.

> For a given DHCP server and a given client, this would
> normally not change. The draft doesn't say that it might
> change either. However, a given server might give different
> domain suffices to different clients.

But, if your guess as to what this is for -- providing
information for completing an FQDN given a host name -- is
correct, then the option should be returning all of the FQDN
after the first component, "claranet.de" in Frank's case or
"bogus.domain.name" for a host FQDN of
"silly.bogus.domain.name".  But that use is prohibited: the
specification says that the option value may contain only one
"item" (presumably a DNS label).

The only thing I can think of that this option, as specified,
would support is not FQDN completion but the setting and
implementation of policy options on an TLD basis.  An example of
such a policy option would be the idea of interpreting IDNs
differently depending on what top-level domain they appeared in
that floated around some years ago.  That whole family of
policies strikes me as bad ideas, bordering on horrible, given
the nature of the DNS administrative structure.

I have sent a somewhat longer note to the IESG list.

   john

---

From: Stig Venaas <[email-masked]>
Date: Wed, 27 Sep 2006 10:44:48 +0200

> abc.example.com or xyz.example.co.uk.  

Right. In the context of this draft, the term domain suffix is
not meant to be just the TLD. If "domain suffix" generally means,
or is thought of as, just the TLD, then the draft should use some
other term instead.

> xyzzy.de, which is probably not what is intended.

Right, I understand what you mean, provided that "domain suffix"
generally just means the TLD or the last label in the FQDN.

> "bogus.domain.name" for a host FQDN of

Yes

> "item" (presumably a DNS label).

"One item" is intended to say that there is just one "domain name".
So you can specify "claranet.de" so that you get xyzzy.claranet.de,
but it can not have two values/items, like both "claranet.de" and
"bogus.domain.name". Clearly the text could be improved here.

> the nature of the DNS administrative structure.

Right, this is not at all what is intended.

Stig

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 27 Sep 2006 11:33:22 +0200

Stig Venaas wrote:

> In the context of this draft, the term domain suffix is not
> meant to be just the TLD. If "domain suffix" generally means,
> or is thought of as, just the TLD, then the draft should use
> some other term instead.

The term is okay if you mention that it's supposed to be one
or more labels, typically at least two.

>> Frank would end up with xyzzy.de, which is probably not what
>> is intended.

xyzzy.claranet.de also won't work, I could screw up and try a
host name used by another claranet.de customer, or vice versa.
The suffix has to be unique.

Maybe it's the same as gethostbyaddr() with a wildcard ?  So
at the moment I'm xyzzy.dnsalias.org = 217.251.168.208, that's
pD9FBA8D0.dip0.t-ipconnect.de, and if that would be a suffix I
could use xyzzy.pD9FBA8D0.dip0.t-ipconnect.de

Clearly not the same as DynDNS, if that's how the suffix works.
It would be also a dubious idea to use this in Message-IDs for
popular host names like "oemcomputer".

If it's no wildcard, does the client get a complete zone for
anything ending with the suffix ?  With IPv4 I'd guess that
we're talking about one IP and one host, but with IPv6...

Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Sep 2006 08:49:19 -0400

> or more labels, typically at least two.

Sure. But that isn't what the term means in common (non-IETF)
practice and the document is quite specific that the return
value contain exactly one label (er, "item") with no provision
at all for two.

> The suffix has to be unique.

Yes, probably.  But then it either is not a "suffix" or the
specification in this document is seriously misguided (stronger
terms from the history of the IETF occur to me, but I'll stick
with "misguided").

> could use xyzzy.pD9FBA8D0.dip0.t-ipconnect.de

Not with the specification as written.  That specification only
permits one label to be returned, never defines what "suffix"
means, and limits a "suffix" to a single "item", whatever that
is.

> popular host names like "oemcomputer".

Yep
 
> we're talking about one IP and one host, but with IPv6...

I think I know where you are going, but it isn't clear to me
what the above would mean in practice.  Certainly the
specification is not clear enough --in either mechanism or about
its intent--  to permit using it interoperably for that type of
purpose. 

IMO, this document should be rejected, and should stay rejected
until the authors clean up their terminology, explain how the
capability is intended to be used, and then explain why the
Internet needs it.   Once it reaches that point, a Last Call
review will make sense, but I would suggest that the proposal
should still be rejected unless the return value can be an
all-but-hostname FQDN, not a single-label "suffix".

       john

---

From: Jefsey_Morfin <[email-masked]>
Date: Wed, 27 Sep 2006 11:53:51 +0200

Stig,
in the MDRS project my group works on to support multilingual 
distributed referential systems we use the concept of Usage Level 
Domain which may have a problem with your usage of "suffix". "suffix" 
the usual/legal term used for the TLD in many non technical/general 
languages. I tend to think that by way of usage ULD will be 
translated also by many as "suffix", while I suggest "affix" to be 
used. We experimented this concept for two years through the dot-root 
test bed.

An ULD is the "TLD" that the user enters, which may be transformed in 
different ways depending on the kind of access. Chinese 
Names,  New.net, DNAMEd IDN.IDN use ULDs. ULDs are made of what the 
user will type and of all the different suffixes or affixes that can 
replace it depending on the ISP, plug-in, DNAME, etc. for a proper resolution.

jfc

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Sep 2006 06:49:02 -0700

> geeky types would prefer "TLD".

Not quite.  A TLD is the right most (visible) field, like com, net, my 
or us,  whereas a "suffix" is typically longer, constituting an 
"organizationl" base domain name string, like example.com, or mtview.ca.us.

Hence:

 > It's what a client might add to it's hostname to form an FQDN.

is a particularly practical way of putting it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Sep 2006 10:50:51 -0400

--On Wednesday, 27 September, 2006 06:49 -0700 Dave Crocker
<[email-masked]> wrote:
 
> Fred Baker wrote:
>>> Sorry, probably that's all obvious, but where is ["domain
>>> suffix"]  defined ?
>> 
>> At the Verisign site. It is the new-speak for use when all us
>> ancient  geeky types would prefer "TLD".
> 
> 
> Not quite.  A TLD is the right most (visible) field, like com,
> net, my or us,  whereas a "suffix" is typically longer,
> constituting an "organizationl" base domain name string, like
> example.com, or mtview.ca.us.

Dave, unfortunately, if "suffix" is formally defined, I haven't
been able to find it.  And it has been relatively common
practice among registrars, registries, and other participants in
"the domain name market" to use "suffix" as a synonym for TLD,
as Fred suggests.  That terminology follows the practice in a
number of operating systems of referring to the second part of a
two-part file name as a "suffix".

It is, IMO, just not acceptable for a standards-track document
to leave the interpretation of terms like "suffix" and "item" up
to the imagination of the reader when their definitions are key
to the implementation of the specification.

> is a particularly practical way of putting it.

Then that definition belongs in the specification.  Moreover,
IMO, the authors of the specification should work with DNSext
and/or DNSops to determine whether there is other terminology
that might be more established and/or more clear and then use
it.  

I've recently been reminded that the DHC charter requires
precisely that type of check and approval; I have reason to
believe that the charter requirement was not followed in this
case.  To the extent to which a WG Charter is a contract between
the WG and the community, this particular WG has apparently
broken that contract.

      john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Sep 2006 08:09:13 -0700

John C Klensin wrote:
> been able to find it.  

Right.

I was not intending to suggest that the specification was acceptable, 
and apologize for not making that clear.

I was merely noting that the construct only made sense in terms of an 
organization "base" domain name, rather than a TLD.

So it is a number of anchored right-hand fields, rather than only 
containing the single, right-most-field.

As you and other note, the specification is critically flawed.

At the least:

1. It fails to define the semantics of "suffix".

2. It does not specify any syntactic detail for the <domain suffix> 
field of the DHCP option.  Is it a dotted ascii string?  Some other 
encoding?

> to the implementation of the specification.

+1

d/
-- 

   Dave Crocker

---

From: "Bill Fenner" <[email-masked]>
Date: Wed, 27 Sep 2006 08:24:58 -0700

> field of the DHCP option.  Is it a dotted ascii string?  Some other

While I was confused too as to what this option is intended to be used
for, I think that

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

sufficiently specifies the encoding of the <domain suffix> field.

  Bill

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Sep 2006 08:41:27 -0700

> sufficiently specifies the encoding of the <domain suffix> field.

as John noted, the term "item" is not defined, so we don't know how many 
labels (dns fields) are permitted.  This certainly encourages the 
confusion between TLD and "organization base".

I'm also a tad uncomfortable with the levels of indirection in the cited 
reference.  The 3315 section really points to a section in 1035, modulo 
prohibiting compressed form.  The cited section in 1035 defines a basic 
syntax but then relies on a different section in 1035.  This all seems 
likely to invite different interpretations.

d/

-- 

   Dave Crocker

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 27 Sep 2006 09:52:30 -0700

I'm not sure why this discussion has broken out on [email-masked].

Is it not better for iesg@ and dhcwg@?

> confusion between TLD and "organization base".

It's hard to disagree with the term 'item' being more vague than is
ideal.  To be clearest it should probaly say "having exactly one root
label (one domain name)" or similar.

I am, however, a little skeptical at how useful it is going to be
to define the term 'domain name suffix'.  I suspect the author of
this draft started by calling them 'zone suffixes' and was asked by
DNS people to switch to 'domain name' instead of 'zone' because
the principle concept of a 'zone name' is different from a 'domain'
(although they overlap and are sometimes equal).

That's judging by the history of edits of this document and others
it at one time referenced (which looks to be a bid to place the
suffix in RS/RA, calling it a 'zone suffix' at that time).

I think operators know what this term means intuitively.  We can
define what it means all we want, but they already know and don't
care what we think it means.  So it seems like a lot of work with
very little payout and a high degree of probability it will turn
into a windmill designed for tilting at.

Once standing upon that ground, one questions why there would be
any wonderment about the meaning of the word 'item' in this context,
where the term 'domain name suffix' is already well understood.

> likely to invite different interpretations.

Quite the opposite.  DHCP server software commonly refers to shared
code to process DHCP option contents.

So citing this section of RFC3315 is telling an implementor to
reuse that code.

Literally, when I read an option document for DHCPv6 that cites
this section of 3315, all I have to do is turn that into:

	{ "option-name", "D", &dhcpv6_universe, CODE_NUM, 1 },

I don't even need to look up that section of 3315 nor the 1035
document.  This is just a "standard DHCPv6 domain name" format.

Note that if we take this stance, that every draft must redefine
the meaning or cite some new work that does so, then we should have
done that in RFC3319, RFC3646, RFC3898, and RFC4280.  Possibly the
DHCPv6 FQDN draft (still waiting for RFC assignment) as well, I can't
remember.

All of these used this method to define options of this format, to my
recent memory at least.  It is common DHC WG guidance to authors to
cite 3315 rather than reinventing.

DHCPv4 has taught us that, while clarity is important and we strive
for it, consistency is more important of these two.

It is better that one implementation treat all similarly formatted
options the same (poor) way, than for any implementation to treat
some options differently from others.

The former is easy for implementations to construct workarounds -
in single, reused-code ways.  The latter is a nightmare construct
of matrixes of option codes and special-case code.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email [email-masked].
-- 
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
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Matt Larson <[email-masked]>
Date: Wed, 27 Sep 2006 13:01:55 -0400

> geeky types would prefer "TLD".

I fail to see the relevance of invoking VeriSign.  Your cheap shot is
unfounded: a Google search for '"domain suffix" site:verisign.com'
yields one page, where the two words don't even appear together.

Microsoft has actually used the term "domain suffix" in the context of
its stub resolver search list for years--it goes back several versions
of Windows.  But in this context, the term can refer to any domain
name, not just TLDs.  So while it's not a term that I use, it has been
around for some time.

Matt

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Sep 2006 10:32:58 -0700

> this draft started by calling them 'zone suffixes' and was asked by

DNS zones are an administrative construct, not a user-visible naming 
construct.

Stated differently:

Domain names are a registration space for globally unique names.  The 
DNS server network provides a query mechanism relating to those names.

Zones are relevant to the query network, not the registration service.

So, zones do not have semantic relevance to the user-level Domain Name 
model.

Hence there is nothing in the DHCP option that necessarily pertains to a 
zone boundary.

> I think operators know what this term means intuitively.  We can

The discussion on this list has made clear that there are a number of 
entirely reasonable -- but quite different -- intuitive interpretations. 
  That the specification permits this ambiguity is a perfect 
demonstration of its deficiency.

> where the term 'domain name suffix' is already well understood.

Even with a good understanding of the term "suffix" the term "item" 
remains ambiguous.  I share John Klensin's concern about this.

So at base what we have is a specification that makes assumptions about 
the interpretation of key terms.  A specifications must not do that.  It 
must define them.  Define = specify.

 > So citing this section of RFC3315 is telling an implementor to

Oh.  So there is a specification for existing DHCP mechanism(s) that use 
this construct?  What part of DHCP is that?  And why does the current 
specification not provide that DHCP context?  Absent that reference, how 
can you know that the capability is already present in a DHCP server.

My concern is that you are confusing software implementation with 
protocol specification, since they can be quite different.

d/
-- 

   Dave Crocker

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 27 Sep 2006 19:47:09 +0200

FWIW, "domain suffix" is used in RFC 3263, 3588, 4183 and 4620. In none 
of these documents does it seem that the author has seen a requirement 
for a definition; "a domain name that is intended to be used as a suffix 
of a complete domain name" seems to be the implied definition.

A pity that Verisign has started using it differently.

                    Harald

---

From: Matt Larson <[email-masked]>
Date: Wed, 27 Sep 2006 14:08:07 -0400

Harald,

> A pity that Verisign has started using it differently.

Please see the email I wrote that you responded to: I don't understand
the (now ongoing) reference to VeriSign's supposed use of, let alone
redefinition of, this term.  Can we drop it, please?

Matt

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Sep 2006 14:14:53 -0400

--On Wednesday, 27 September, 2006 09:52 -0700 "David W.

> Is it not better for iesg@ and dhcwg@?

Because Last Call announcements invite such discussion.  Some
people tend to go to [email-masked] with any Last Call comments.
Others of us tend to go to this list only when more general
principles are involved than the details of a particular
specification.   This proposal seems to be (quite reasonably,
IMO) bringing out both groups, partially because of a feeling
that the DHC WG has failed in its review responsibility by
letting a specification with this many undefined terms and
concepts reach IETF Last Call.

>> as John noted, the term "item" is not defined, so we don't
>> know how many  labels (dns fields) are permitted.  This
>> certainly encourages the  confusion between TLD and
>> "organization base".
> 
> It's hard to disagree with the term 'item' being more vague
> than is ideal.  To be clearest it should probaly say "having
> exactly one root label (one domain name)" or similar.

> I am, however, a little skeptical at how useful it is going to
> be to define the term 'domain name suffix'.  I suspect the
> author of this draft started by calling them 'zone suffixes'
> and was asked by DNS people to switch to 'domain name' instead
> of 'zone' because the principle concept of a 'zone name' is
> different from a 'domain' (although they overlap and are
> sometimes equal).
> 
> That's judging by the history of edits of this document and
> others it at one time referenced (which looks to be a bid to
> place the suffix in RS/RA, calling it a 'zone suffix' at that
> time).

Any clear and precise definition would be satisfactory.  I don't
believe that anyone would be quibbling on this list about
whether one style of definition was better than another if only
there were one that was unambiguous to all readers, regardless
of how much DNS and/or DHCP implementation experience they had.

> I think operators know what this term means intuitively.  We
> can define what it means all we want, but they already know
> and don't care what we think it means.  So it seems like a lot
> of work with very little payout and a high degree of
> probability it will turn into a windmill designed for tilting
> at.

David, I've been pretty close to some operators.  I've also been
very close to applications design and implementation, as has
Dave.  Neither of us are sure what this is for, much less what
some of the words mean, which is pretty damning.

It the intention of the specification is that it cannot be read
except by those who are already experienced with DHCP options
and their implementation, that would probably be ok too.  But
then it needs to say that and tell newcomers what to read.
Otherwise, you don't have a standard, just a memo to the
in-group.

> Once standing upon that ground, one questions why there would
> be any wonderment about the meaning of the word 'item' in this
> context, where the term 'domain name suffix' is already well
> understood.

But it is not "well understood".  In deference to Matt, I
wouldn't blame Verisign (and haven't), but there is definitely a
use in the domain name marketing community that is exclusively a
TLD and there is apparently a use --largely undocumented in the
IETF community as far as I know -- that is the "non-hostname"
part of the name.  When there is ambiguity about what a name
means, especially if it is used for two different things, then
one either avoids the term or defines it locally to the
document.  That isn't much to ask for, I think.

>> I'm also a tad uncomfortable with the levels of indirection
>> in the cited  reference.  The 3315 section really points to a
>> section in 1035, modulo  prohibiting compressed form.  The
>> cited section in 1035 defines a basic  syntax but then relies
>> on a different section in 1035.  This all seems  likely to
>> invite different interpretations.
> 
> Quite the opposite.  DHCP server software commonly refers to
> shared code to process DHCP option contents.
> 
>...

Let's assume that we accept that much.   We still have two
problems.  The first is that of the "levels of indirection" to
which Dave and I have referred.  It isn't a request to define
the label format from scratch in each document, as you seem to
imply.  It is just a question as to whether referencing a
section of 3315 (without a section number) which references a
section of 1035, which sort of references another section of
1035 is the best way to do this.  That is arguably a criticism
of 3315, not of this document, but there are two reasonable ways
to "fix" this and, .  One is to just skip the reference to 3315
and go to 1035 on the theory that 3315 isn't adding value.  The
other is that 3315 should have provided a crisp and compact
definition for use in DHCP and then noted, informatively, how it
is built on particular options from 1035.

The second is that, starting from my application bias, when I
look at a DHCP option, I'm not too concerned about the
relatively small number of people who implement DHCP servers.
I'm concerned about the somewhat larger number of people who
implement DHCP client software and, more important, the _much_
larger number of people who implement applications that retrieve
the values that DHCP returns and try to use them.   Those folks
may (and often do) use only a single DHCP option.  They need to
know exactly what it means, what the values are, and what it
returns.   And what you, as a server implementer, already know
or can take advantage of is of absolutely no use to them.

That difference in perspective gets us onto one of the IETF's
slippery slopes which is important to understand but that still
doesn't impact this document.   Suppose I'm implementing a DHCP
client for the hypothetical "OS Z" operating system.  If, at the
request of an application, I request this particular option and
get an answer, nothing prevents me from defining my interface to
the application (an API or whatever) so that I get back a domain
name in "DHCP" format (lengths and labels) but hand the
application a dot-separated ASCII string.  Then the client needs
to know about my API and not about the protocol.   Still, we
know that (1) that doesn't happen very often, maybe not as often
as it should and (2) it makes it even more important that what
the DHCP client is going to get to the server be specified
without ambiguity.

>...

Sure. But see above about clients and applications.  Server
implementers are not the only users of this sort of
specification.  I also agree with Dave's comment about the
difference between specification/standard and implementation and
note, in the DNS cases especially, how many problems have been
caused by "the implementation is the standard" assumptions.

> Note that if we take this stance, that every draft must
> redefine the meaning or cite some new work that does so, then
> we should have done that in RFC3319, RFC3646, RFC3898, and
> RFC4280.  Possibly the DHCPv6 FQDN draft (still waiting for
> RFC assignment) as well, I can't remember.

> All of these used this method to define options of this
> format, to my recent memory at least.  It is common DHC WG
> guidance to authors to cite 3315 rather than reinventing.

Not the point or the requirement.  See above.

>...

    john

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Sep 2006 11:29:53 -0400

--On Wednesday, 27 September, 2006 08:09 -0700 Dave Crocker
<[email-masked]> wrote:

> 
> 
> John C Klensin wrote:
>> Dave, unfortunately, if "suffix" is formally defined, I
>> haven't been able to find it.  
> 
> Right.
> 
> I was not intending to suggest that the specification was
> acceptable, and apologize for not making that clear.
> 
> I was merely noting that the construct only made sense in
> terms of an organization "base" domain name, rather than a TLD.
> 
> So it is a number of anchored right-hand fields, rather than
> only containing the single, right-most-field.
> 
> 2. It does not specify any syntactic detail for the <domain
> suffix> field of the DHCP option.  Is it a dotted ascii
> string?  Some other encoding?

Actually, I believe that the document does specify this,
although the definition involves two levels of indirection and
is convoluted.   Personally, I don't find two levels of
indirection acceptable when sorter and clear paths exist but, if
that were the only problem with this document, I believe it
would be acceptable as a Proposed Standard.

Specifically, in section 2, we have

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

The relevant section of RFC 3315, Section 8, points to Section
3.1 of RFC 1035, which specifies representation of a domain name
as a set of {length string} pairs, one for each label.  3315
also prohibits use of the compressed form, but, since that form
is not discussed in 1035 (3.1), the statement is largely
gratuitous. 

Whether that syntax form is wise or optimal or not is, of
course, dependent on intended use, which we don't have.
Certainly if one intends to use it to construct FQDNs for any
purpose other than immediately feeding back into the DNS, there
is a case to be made that dotted-ASCII would be better.  But, of
course, this document does not provide enough information for us
to figure that out.

After reading your question, it also occurs to me that this
specification should be required to include an
"Internationalization Considerations" that notes that, if the
label(s) in the "suffix" are IDNs, the punycode form MUST be the
form returned and perhaps justifies that in terms of intended
use.

That, of course, is just another chapter in support of
"critically flawed".

      john

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Sep 2006 14:33:31 -0400

some of this I've said elsewhere, but not here.  sorry if you've already 
seen it.

IMHO this is fundamentally a very dubious option because DNS is the 
authoritative source of name-to-address mappings, and the way to find 
out what DNS name is assigned to a particular network address is to 
query the DNS for PTR records at the appropriate in-addr.arpa or 
ip6.arpa locations.

It's bad design to have two authoritative sources of the same piece of 
information.  If there's a conflict between DNS and DHCP, which one 
wins?  And given that DNS server information can be obtained from DHCP, 
why not just query the DNS to find out the FQDN that corresponds to the 
network address assigned to the host?  Or is DHCP just acting as a kind 
of DNS cache in order to make life simpler for relatively 
unsophisticated networked appliances?  If so then the rules for caching 
need to be observed.

Note also that in the IPv6 world it is considered perfectly normal for a 
host to have multiple IPv6 addresses and IPv6-aware applications are 
expected to deal with this somehow (currently, by a combination of luck 
and trial-and-error).  There's no reason to assume, and good reason to 
not assume, that all of the addresses associated with a host are on the 
same network.  For this reason it makes even less sense in IPv6 than it 
did in IPv4 to assume that "the" network to which a host is attached 
configures the host.  So any information obtained from DHCPv6 should be 
considered as only meaningful in the context of that particular network 
attachment - not as something that applies to the entire host.

Even if this option can be found to have value (with suitably narrow 
applicability), IMHO it's nuts to define the "domain suffix" (components 
2..n of the FQDN) separately than the "host name" (the leftmost 
component of the FQDN).  Any attempt by a host to infer anything about 
the relationships between hosts based on their domain name suffixes is 
extremely dubious anyway.  Why not just define a FQDN option and be done 
with it?  Seems like it would be less likely to be misused.

Also, one should be careful to avoid making the assumption that a host 
has a single FQDN, or even a distinguished FQDN, or that an FQDN maps to 
at most one host.  None of these is true in practice.

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Sep 2006 11:29:53 -0400

john

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Sep 2006 14:33:31 -0400

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 27 Sep 2006 15:42:48 -0400

> value contain exactly one label (er, "item") with no provision

Except it doesn't say "label"; that's your interpretation.  I grant it is 
an entirely reasonable interpretation, and in fact the alternate 
interpretation that was suggested is not one that would have occurred to me.

> review will make sense

I agree.  As it stands, this document refers to DNS concepts using terms 
other than those normally used, and in particular the term "domain suffix", 
while not having any formal meaning I am aware of, has at least one 
commonly-used meaning which is different than that apparently intended by 
the authors.

In short, I believe this document currently lacks the precision appropriate 
for an IETF specification.

, but I would suggest that the proposal
> all-but-hostname FQDN, not a single-label "suffix".

I agree with this also, given that the latter seems fairly useless. 
Fortunately, I suspect the document authors also agree, and are simply 
using poor terminology to say what they mean.

-- Jeff

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Sep 2006 07:32:17 +1000

> interpretation that was suggested is not one that would have occurred to me.

	Well for this option to encode a TLD it would have to
	encode 2 label.

	As for "domain name suffix" while I can't remember seeing
	a formal definition.  In the DNS world it is any domain
	name appended to a unqualified or partially qualified domain
	name to create a fully qualified domain name.

	Now the DNS RFC's always talk about both wire and presentation
	formats.  The option itself is a domain name in uncompress
	DNS wire format.
 
--
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DHCP.  Email [email-masked].
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 27 Sep 2006 17:56:05 -0400

On Thursday, September 28, 2006 07:32:17 AM +1000 Mark Andrews 
<[email-masked]> wrote:

>> Except it doesn't say "label"; that's your interpretation.  I grant it
>> is  an entirely reasonable interpretation, and in fact the alternate

True, but that is a subtlety that is lost on most people.

> 	name to create a fully qualified domain name.

Except among people who use it to mean "TLD", which does seem to be a 
common usage.  I have seen this usage on the web sites of domain registars. 
There are clearly multiple uses here, and which one the reader assumes will 
depend on his background and possibly other factors.

> 	formats.  The option itself is a domain name in uncompress

Yes; I think the reference makes that reasonably clear, particularly if one 
is already familiar with what is currently common practice in DHCP and the 
DNS.  But as has been pointed out, not all of the readers of this document 
will have that background.

Basically, if John Klensin misinterpreted your document, and Dave Crocker 
did, and I did, that's at least three readers with at least some 
familiarity with the concepts involved for whom the document was not clear 
enough.  IMHO, that's enough to suggest it could use some clarification.

-- Jeff

---

From: John C Klensin <[email-masked]>
Date: Thu, 28 Sep 2006 12:27:54 -0400

--On Wednesday, 27 September, 2006 14:33 -0400 Keith Moore
<[email-masked]> wrote:

>...
> IMHO this is fundamentally a very dubious option because DNS
> is the authoritative source of name-to-address mappings, and
> the way to find out what DNS name is assigned to a particular
> network address is to query the DNS for PTR records at the
> appropriate in-addr.arpa or ip6.arpa locations.
>...
> Also, one should be careful to avoid making the assumption
> that a host has a single FQDN, or even a distinguished FQDN,
> or that an FQDN maps to at most one host.  None of these is
> true in practice.

Ok.

We are now up to two independent issues.  Perhaps it is useful
to identify them separately, either to focus discussion or to
swiftly send this document back to the relevant WG (see below)
for further consideration and rewriting.  I recommend the
second, if only because the IETF list is a lousy place to either
edit document or to resolve specific design issues.

Issue 1: Even if the option is desirable and the motivation for
it is clear, the specification is inadequate in definitions and
specificity in this particular document.   I believe that there
is no longer any real controversy on that matter and that the
issue suggests, and perhaps requires,  ending the Last Call and
returning the document to the authors.  Further kicking of that
dead horse on this list is unlikely to accomplish much of
anything, IMO.

Issue 2: We should, IMO, be taking the transition of DHCP from
IPv4 to IPv6 as an opportunity --I would hope a mandate-- to
review old options to see if they have been proven in use and
have sufficient mandate from user communities, whether they can
be combined or better optimized, and whether they are
appropriate in an IPv6 world.  Whether one agrees with Keith's
conclusions (and not just the ones I've quoted above for
context) or not, I think he is clearly suggesting the right
questions. Those questions deserve careful consideration and
response (with "we did this before" or "we are already on that
path" not being considered a proper response).

Certainly the charter of the DHC WG doesn't contain "mindlessly
move options from v4 to v6".

This is up to the ADs and relevant WG Chairs, but, IMO, given
the issues DHC charter and other, the right WG to review the
mandate for this proposal (and Keith's comments) would be one
involved in DNS and DNS usage.  My instinct is like Keith's
conclusion: I'd like to see one "return FQDN" option, possibly
with some syntax to specify "don't have a clue about the
hostname", rather than a bunch of options to return various
pieces of domain names.  There may be perfectly good reasons to
not do that but it seems to me that those reasons need to be in
the province of either DNS-related WGs or of some group(s) in
the Applications Area that actually has to _use_ this stuff, not
simply defaulting to these options because the DHC WG (clearly)
has the ability to define something or has done so before.

   john

---

From: Ralph Droms <[email-masked]>
Date: Thu, 28 Sep 2006 12:48:22 -0400

OK, now I have to step in with a response and to correct a couple of
misconceptions.

> dead horse on this list is unlikely to accomplish much of

Based on feedback received during the IETF last call, the authors and the
dhc WG, in collaboration with the dnsop WG, will revise the spec to address
the following issues:

1. clarify the use case motivating this option
2. clarify/reword the phrase "domain suffix"
3. simplify the reference to RFC 1035 encoding

> Issue 2: [...] 

And the dhc WG has explicitly not "mindlessly moved options from v4 to v6".
Had you checked the history of DHCPv6, you would have found that the dhc WG
considered several mechanisms for carrying DHCPv4 options over to DHCPv6.
The WG rejected those mechanisms and made an explicit decision to only
redefine DHCPv4 options for DHCPv6 on demand, as required by specific use
cases.

In retrospect, we should have collaborated with the dnsop WG on this option
and we'll do so now.

However, to correct another misconception, the dhc WG does, in fact,
collaborate with customer WGs on new DHCPv[46] options.  In fact, the WG, in
consultation with the Internet ADs, makes every effort to have the customer
WG do the bulk of the option development, with input from the dhc WG on
compatibility with DHCP operation, syntax, etc.

> [...]

So, you've all had an opportunity to make your points, more or less
accurately and constructively, and the dhc WG will, as I said, work with the
authors and the dnsop WG to review, reconsider and clarify the document.  We
will be sure to better document the motivation and use cases for this option
in a revised document.

I think we've spent way more energy in dead horse kicking than we needed to
on a fairly insignificant DHCPv6 option at this point.

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 28 Sep 2006 11:20:20 -0700

I am flattered that my simple opinion required not one but two such
voluminous responses.  Thank both of you for the compliment.

I don't think repeating my (unchanged) opinion is useful or will have
any real impact on the Internet, so I had not planned on responding.

But there is something in Dave Crocker's reply that I need to clear
up, as I gather it is my fault:

On Wed, Sep 27, 2006 at 10:32:58AM -0700, Dave Crocker wrote:
> this construct?

If I gave you the impression that the ISC DHCP server and client
software shared common code or libraries with, say, the Kame server
and, say, the Apple OSX client (if there is one), that is incorrect.

I was referring to practices internal to implementations, reuse of
code internal to each.

And so long as I'm transmitting, there is one other thing;

| returns.   And what you, as a server implementer, already know
| or can take advantage of is of absolutely no use to them.

One might infer from this that I am creditable for ISC's DHCPv6
Server implementation, and that isn't correct.

Let me be clear: the only person who deserves that credit is Shane
Kerr.  If I deserve any credit, it is for helping him find bugs.

We are both, however, equally culpable for any blame.