ietf
[Top] [All Lists]

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

2006-09-27 06:00:03
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

At 10:44 27/09/2006, Stig Venaas wrote:

John C Klensin wrote:
--On Wednesday, 27 September, 2006 09:19 +0200 Stig Venaas
<stig(_dot_)venaas(_at_)uninett(_dot_)no> wrote:

Frank Ellermann wrote:

Fred Baker wrote:

["domain suffix"]


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

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.

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.

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.

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


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.

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

Yes

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

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

Right, this is not at all what is intended.

Stig

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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>