Re: [dnsext] does making names the same NEED protocol changes at all?

[Suzanne Woolf <[e-mail]>]

On Fri, Feb 25, 2011 at 12:48:15PM +0000, Alex Bligh wrote:
> --On 24 February 2011 12:17:10 -0500 Phillip Hallam-Baker 
> <[e-mail]> wrote:
> 
> >I am starting to get a really bad feeling about the resolve the same
> >requirement. Is the objective here really to make things work better or
> >did the authorities that raised this in ICANN have a rather different
> >agenda?
> 
> We asked (effectively) that, and reply there came none.

ICANN has announced a proposed study project that stands some chance
of allowing it to arrive at its own position on what's entailed around
"variants" or "sameness". It appears that they are admitting they
don't know what they want, or whether it's got anything to do with the
DNS, so they're starting from the policy perspective and working
(perhaps) towards the technical.

See:
http://www.icann.org/en/public-comment/public-comment-201104-en.htm#idn-varianttld

(NB: I serve as a non-voting liaison to the ICANN Board of Directors
from one of its technical Advisory Committees, the Root Server System
Advisory Committee. However, I don't speak for ICANN, particularly not
on this issue; took on the aliases draft with no support or prompting
from ICANN and with the support of my employer, ISC; and have been
trying for quite some time now to get ICANN to speak for itself.)

> I think there may have been a little naivety involved, and someone rather
> hopefully thought a simple "fix in DNS" could make domain names in n
> different TLDs (which they thought of as 1 TLD with n different
> representations) "work the same". Several hundred messages here plus a
> non-trivial I-D just to set out the requirements, suggests that at the very
> least, the problem is not as simple as first thought.

Can't comment on what ICANN thought (see above). But I'll note that
part of how we got where we are was that the WG found itself with
several proposals for technology to solve a simple, obvious problem
that no one could state here, either.

In other words, there may have been plenty of naivety to go around :-)
(including my own, I claim no special wisdom)

> I also think I understand what the registries are trying to do, and suggest
> the answer is "enforce this within your business processes" (i.e. make
> registration of any of a bundle of identical names block out all further
> registrations other than by the same registrant, and let the same
> registrant insert NS records etc. for any other domain in the same bundle,
> perhaps up to some local policy limit). I can understand why synthesis
> might be useful here, but I can also understand why registries don't like
> it.
> 
> I also think I understand what the rest of the world might want to
> do, and my answer is "use CNAME/DNAME", plus possibly synthesis.

This is a very fair and important point-- that we're actually talking
about two different perspectives here, what registries want and what
application writers want. One of the things we have to settle is how
much they're talking about "the same thing"(!) -- i.e. how much their
concepts of what needs to be done overlap.

If all we're looking at is what registries need, we have to separate
the policy requirement to have a way to determine that a set of
objects should be treated as "the same" (not our business) from the
operational or technical requirements for a mechanism by which to
instantiate what that means (maybe our business).

To the first (registry) question, I'm hoping for more text on
variant-related use cases, which is why I'm hopeful about ICANN's new
project. But when you read the draft, you'll see a proposed
requirement that for any action the WG takes, it's necessary but not
sufficient to address the registry consideration, per some comments on
the list about a week ago. It's extremely important to get reactions
to that requirement from the full range of WG participants.

I've talked to some people (some of whom have posted here) who seem to
be saying that parallel provisioning by the domain registry is not
enough for their purposes, because the fact that the objects so
created are only related inside the registry and to some assumed set
of users is not enough-- that it would be useful to them to have a
service-independent, application-accessible way to create a property
or attribute of a set of names that we could call "sameness" or
"aliases-of".

If true, it provides a motivation for looking hard at a requirement
that parallel provisioning doesn't meet (your second prong). However,
it's been extremely difficult to get clarity on this, and it's one of
the things most important to get right for the draft.

Either way, we also need to settle exactly how CNAME/DNAME fall short,
if they do. The current draft takes a stab at that but it may need
more development.

> However, what we don't yet have is a coherent statement of the problem
> (save for the I-D just out which I have yet to read), which means we don't
> have coherent explanation of why it is so difficult to solve (and, IMHO, a
> bad idea if it requires protocol changes). This is why I should go and read
> the I-D.

Please do, looking forward to your comments.


best,
Suzanne