Re: [dnsext] I-D Action:draft-ietf-dnsext-aliasing-requirements-00.txt

[Ted Hardie <[e-mail]>]

Hi Suzanne, Xiaodong,

Thanks for producing the document; I think it's a good start toward
getting a common terminology around the problem space.  Reading
through the text for "variants", I think it might actually be useful,
though, to start  a little further back.  This might be particularly
useful for non-DNS geek readers.  What I'm thinking of is adding a
section that says, in big bold letters:

The DNS is a known-item lookup protocol.

If you start up from that in big, bold letters, it first clarifies
that any version of "sameness" or "variation" that is not about lookup
is work that has to be done at some other layer.  It also suggests
describing different variant  types in terms of the desired lookup
behavior.

CNAME is the "referral" version--it provides a pointer to another part
of the namespace at which subsequent lookups should occur.  Some
variants may desire "referral" lookup behavior of some type not yet
supported.

Your text makes clear that there is a desired lookup behavior of
"consistent result", where a query to

<query name1, type, class, server IP address>
and
<<query name2, type, class, server IP address>

will return (as much as possible) the same data.

I think there are two flavors of "consistent result".  For one, the
relationship between or among the names queried is exposed.  Much of
the current text seems to assume that it would advantageous to expose
that in order to reduce provisioning costs (especially for
higher-layer constructs like names in certificates).  A different
flavor synthesizes a response that are consistent, but does not
exposes the relationships among labels whose responses are "the same".
(The different cache characteristics is probably something worth
exploring as well).

This probably seems both obvious and pedantic, but given that the
likely audience will include folks more used to search-engine style
behavior, I think trying to describe things in terms of pure lookup
may help in the long run.

regards,

Ted Hardie




On Wed, Feb 23, 2011 at 3:47 AM, Suzanne Woolf <[e-mail]> wrote:
>
> Colleagues,
>
> Per the announcement to the list last night, the -00 of the "aliases"
> problem statement has been posted to the i-d repository.
>
> Your comments are sought. It was pushed out this week to keep the
> discussion here going.
>
> It's a working draft and obviously needs a number of refinements on
> terminology and details, but the most important thing to establish at
> this point is whether it gets the overall landscape right.
>
> I hope we will have a -01 ready before Prague, so we can have a strong
> document by then and focus in the meeting on some decisions.
>
>
> best,
> Suzanne
>
> On Tue, Feb 22, 2011 at 04:15:02PM -0800, [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the DNS Extensions Working Group of the IETF.
>>
>>
>>       Title           : Problem Statement: DNS Resolution of Aliased Names
>>       Author(s)       : S. Woolf, X. Lee
>>       Filename        : draft-ietf-dnsext-aliasing-requirements-00.txt
>>       Pages           : 20
>>       Date            : 2011-02-22
>>
>> This document attempts to describe a set of issues that arises from
>> the desire to treat a set or group of names as "aliases" of each
>> other, "bundled," "variants," or "the same," which is problematic in
>> terms of corresponding behavior for DNS labels and FQDNs.
>>
>> With the emergence of internationalized domain names, among other
>> potential use cases, two or more names that users will regard as
>> having identical meaning may sometimes require corresponding behavior
>> in the underlying infrastructure, possibly in the DNS itself.  It's
>> not clear how to accommodate this required behavior of such names in
>> DNS resolution; in particular, it's not clear when they are best
>> accommodated in registry practices for generating names for lookup in
>> the DNS, existing DNS protocol elements and behavior, existing
>> application-layer mechanisms and practices, or some set of protocol
>> elements or behavior not yet defined.  This document attempts to
>> describe some of these cases and the behavior of some of the possible
>> solutions discussed to date.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aliasing-requirements-00.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>
>
>> _______________________________________________
>> dnsext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsext
>
> _______________________________________________
> dnsext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsext
>