Subject: [dns-dir] Solicitation for subscribers in response to ICANN

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Apr 2010 12:16:38 -0400

Dear colleagues,

The previous draft response to ICANN appears to have been obviated by
ICANN's clarifying remarks, which appear in the Q&A they posted and in
Tina Dam's remarks on the blog. 

Accordinly, I've prepared a different response to ICANN.

I'd like to hear from people who want to subscribe their name to this
when I send it.  If you don't say that you want your name on it, I
won't attach yours.

Jim Reid has authorized me to add his name, so there will be at least
one other person listed at the bottom.

Obviously, suggestions for changes to the text are also welcome. I'm
running out of time to work on this, however.  I won't have much time
today, and tomorrow I leave for a trip to Washington.

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Peter Koch <[email-masked]>
Date: Mon, 12 Apr 2010 22:31:23 +0200

Andrew, all,

> results in a response containing the target IPv4 or IPv6 address.
> Since the Q&A web page is clear that there is no such requirement,
> given that the two delegations are completely distinct in the DNS,
> ICANN should use other terms to make its point or risk continuing
> confusion.  We have not been able to understand what it means for
> something to resolve to "a value".

it appears to me that this is acknowledging the fact that "addresses"
aren't the only data stored in the DNS, but also MX-RRs, NAPTRs - ugly
as they are - or some yet-to-be-defined fancy new type. Now that the
explanatory text explains that "addresses" are no longer meant to be
"addresses" but something (maybe even URLs, maybe more abstract) that
leads to "similar user experience", the distinction between addresses
and values no longer has much value (apologies for the pun).  What I
find concerning is that the text is somewhere between misleading and
incomprehensible without the Q&A part. In fact, these aren't clarifying
but actually constituting the meaning the applicant would have to
subscribe to.

> Second, question and answer 9 in the Q&A should be updated.  The
> answer there says, "DNS responses must produce equivalent
> results. . ."  We would prefer that language be removed or somehow
> altered, because despite the disclaimers immediately following it, it
> could be misinterpreted as a constraint of what may be part of any of
> the zone data in question.  It needs to be clearer that the test of
> synchronization is that users should not be surprised and not that
> there be any congruence of answers in the DNS.  Most users have no
> direct experience of the DNS, and there need be no requirement of any
> kind on DNS responses.  The example should be modified to include the
> case where delegations under S1 and S2 have similar names, but where
> the addresses at those names are different.  As long as the results
> the user experienced were the same, (e.g. because the different
> servers each served localized but otherwise-equivalent content), that
> would be consistent with ICANN's stated condition for synchronization.
> It should also be made clearer that the target systems are not only
> web systems, but any systems; so MX records and such should also be
> part of the examples.

Thanks for adding this.  Still this reads a bit like minor word
smithing nits.  In my opinion one would either accept the text and Q&A
"clarifications", since all these additional suggestions are in line
with the inconsistency provided so far -- or it needs a major overhaul.
The meta issue here is that "user experience" is at least as fuzzy a
term as "confusingly similar".

That said, if we'd extend the comments to the Q&A and the Blog entry,
we might want to clarify the status of the proposed BNAME RR type
and any expectations that may arise from its availability.

-Peter

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 12 Apr 2010 16:36:56 -0400

I've had some comments back, so a modified version is attached.  That said,

> with the inconsistency provided so far -- or it needs a major overhaul.

. . .this is half the basic problem.  The other half is that whereas
the other documents are backed up by Board resolutions, the Q&A does
not appear to have the force of the Board behind it.  So officially,
of course, only the Plan is really what's up for consideration.  I
think it would be churlish to pretend that, however.

> and any expectations that may arise from its availability.

See the attached & see if it suffices.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 13 Apr 2010 05:29:08 -0400

I've made a couple more changes.  I think that I need to send this
today.  If you have a strong objection, please let me know.

So far, only Olafur says he will sign this.

A

> Thank you for posting, and for the opportunity to comment on, the
> "Proposed Implementation Plan for Synchronized IDN ccTLDs"
> (henceforth, the Plan).  Thank you also for the clarifications you
> posted in the form of a set of Questions and Answers on 8 April, 2010.
> 
> We are individuals who work on the DNS protocol and on DNS
> operations, as participants in the Internet Engineering Task Force.
> We have read the documents carefully.
> 
> Prior to the posting of the Q&A, we had several concerns about what
> might be entailed for the DNS by the Plan.  The Q&A, however, makes
> clear that the Plan is exclusively focussed on administrative
> arrangements, and has no implications for the DNS protocol.  We
> therefore understant that under the plan, whatever delegations are
> made from the root zone are simply different DNS delegations with no
> interdependencies.  We understand that synchronization is to be
> understood entirely in terms of user expectation, and that users'
> expectations could be more or less satisifed in any number of ways,
> including by using completely different servers to address the needs
> of different communities.
> 
> In light of that, we have two suggestions.
> 
> First, it would be helpful in the present case, and in similar future
> cases, if ICANN did not use the terms "resolve" and "address" when the
> ordinary meaning of those terms is not what is intended.  Both the
> Plan and the Q&A web page use the expression "to resolve to the same
> address or value".  In the Internet context, "resolve" almost always
> entails an entanglement with the DNS.  Similarly, in the Internet
> context, "address" almost always means an IPv4 or IPv6 address.  For a
> name to resolve to an address, therefore, means that there be an entry
> in the DNS such that a lookup of the name results in a response
> containing the target IPv4 or IPv6 address.  Since the Q&A web page is
> clear that there is no such requirement, given that the different
> delegations are completely distinct in the DNS, ICANN should use other
> terms to make its point or risk continuing confusion.  It is not clear
> to us what it means for something to resolve to "a value".  We are
> aware that there are many DNS resource records that do not contain
> addresses (NAPTR records, for instance), and that this is perhaps what
> is intended.  If that is the case, it should be avoided, because the
> Plan as clarified does not require any real "sameness" in the DNS
> anyway.
> 
> could be misinterpreted as a constraint on what may be part of any of
> the zone data in question.  The test of synchronization is that users
> should not be surprised, and not that there be any congruence of
> answers in the DNS.  Most users have no direct experience of the DNS,
> and there need be no requirement of any kind on DNS responses.  The
> example should be modified to include the case where delegations under
> S1 and S2 have similar names, but where the addresses at those names
> are different.  As long as the results the user experienced were what
> the user expected, (e.g. because the different servers each served
> localized but otherwise-equivalent content), that would be consistent
> with ICANN's stated condition for synchronization.  It should also be
> made clearer that the target systems are not only web systems, but any
> systems; so MX records and such should also be part of the examples.
> 
> Thank you for this opportunity to contribute to the completion of
> ICANN's Fast Track process.
> 
> Sincerely,
> 
> [signatories]

> _______________________________________________
> dns-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-dir

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.