--On Wednesday, 27 September, 2006 11:33 +0200 Frank Ellermann
<nobody@xxxxxxxxxxxxxxxxx> wrote:
> 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.
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.
>>> 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.
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").
> 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
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.
> 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".
Yep
> 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...
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
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf