Subject: Motion Re: [dnsext] regulatory problem statement (was Re: ... as "the same")

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Sep 2010 11:37:36 -0400

Paul is right, this discussion is really going downhill.

Here we have people imputing that a request is being made on behalf of
ICANN and ICANN is not present. So instead of ICANN being required to
engage in this discussion and define its requirements with precision
we have people trying to channel their thoughts.

There is in fact a formal process that the IETF has for dealing with
such circumstances, the liaison process.

I propose that henceforth the only person who is permitted to speak on
behalf of ICANN is the official IETF liaison and that further we ask
the IETF-ICANN liaison to request from ICANN a concise statement of
their requirements before we consider accepting this as a WG work item
on their behalf.

If ICANN either can't be bothered or is unable to state their
requirements it is a pretty good sign that the the task is either not
as important as people imagine or that it is not soluble.

Reading posts on ICANN staffer blogs to find requirements is not a way
to conduct an international standards activity. If they are the
constituency for this requirement they have to state it themselves.

On Tue, Aug 31, 2010 at 11:32 AM, Paul Hoffman <[email-masked]> wrote:
> At 11:16 AM +0800 8/31/10, Jiankang YAO wrote:
>>----- Original Message -----
>>From: "Paul Hoffman" <[email-masked]>
>>To: "Paul Vixie" <[email-masked]>; <[email-masked]>
>>Sent: Tuesday, August 31, 2010 8:04 AM
>>Subject: Re: [dnsext] regulatory problem statement (was Re: ... as "the same")
>>
>>
>>> At 11:38 PM +0000 8/30/10, Paul Vixie wrote:
>>>>i think ICANN has been pretty clear about why it wants this stuff.
>>>
>>> why it wants != requirements
>>>
>>> If you think ICANN has been pretty clear about its requirements, a URL would be handy. An ICANN staffer speaking up would be even more useful.
>>>
>>
>>Tina from ICANN has a report in Brussels meeting. this may help us to understand it.
>>
>>https://brussels38.icann.org/meetings/brussels2010/presentation-idns-dam-23jun10-en.pdf
>
> With all due respect, I do not see anything in here that could be called "pretty clear" about requirements. Sending links to presentations that discuss possible solutions but do not discuss the problems is not helpful to this discussion.
>
>>also some idn seessions:
>>https://brussels38.icann.org/node/12683
>
> And the same here. I see presentations on well-known IDN issues, not clear statements of requirements for equivalence.
>
>>https://brussels38.icann.org/full-schedule
>
> And that's just insulting.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
>

-- 
Website: http://hallambaker.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Sep 2010 12:01:51 -0400

Chair hat on.

> such circumstances, the liaison process.

Well, it's funny you should raise that.  There has in fact been some
discussion behind the scenes exactly along these lines.  If anything
comes of it, I'll keep the WG posted.  That said,

> constituency for this requirement they have to state it themselves.

I don't think they are _the_ constituency for this requirement.
CNNIC, for instance, has a problem in this space (which I think
they've tried to outline), and CNNIC staff have been active and
valuable contributors.  We've also had some input from some other
registry operators with different but perhaps related problems.  

Speaking without my hat, I think the reason ICANN has been brought in
is because they're a large, important registry and we know they have
done some things in this area because of the IDN CCTLD events earlier
this year.

A

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Sep 2010 09:14:42 -0700

>constituency for this requirement they have to state it themselves.

To that end, <http://www.ietf.org/liaison/managers.html> lists Thomas Narten as the IETF's liaison to the ICANN Board. (The ICANN web site doesn't have an equivalent list of liaisons to other SDOs.)

Thomas: there is a (so far unofficial) desire on the the part of the DNSEXT WG to hear from ICANN what its requirements are in order for us to move forward on possible WG work items. What is the best way for us to ask ICANN in an official fashion?

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Sep 2010 09:28:06 -0700

>done some things in this area because of the IDN CCTLD events earlier

Actually, that's not my interest in having ICANN give specific requirements. My interest is that others keep saying "ICANN requires it" as a reason for us to do the work, and ICANN can speak more authoritatively than those individuals about what they do or do not require.

--Paul Hoffman, Director
--VPN Consortium

---

From: Jim Reid <[email-masked]>
Date: Wed, 1 Sep 2010 18:05:46 +0100

> their requirements before we consider accepting this as a WG work item

+1

We seem to be running round the same poorly defined equivalence maze  
that emerged from ICANN 4-5 months ago.

> as important as people imagine or that it is not soluble.

Not necessarily. It could be that ICANN is unable to articulate their  
requirements in a way that makes sense to us DNS geeks.

Personally, I think there is an important problem in here somewhere.  
However it's not clear what that problem is or whether it is soluble.  
Or if a solution is best done in the DNS or elsewhere.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 01 Sep 2010 18:25:34 +0100

> their requirements before we consider accepting this as a WG work item

+0.75

CNNIC and various others have a requirement quite separate from whatever
ICANN's might or might not be for equivalence. We should hear them
out on this as far as technical requirements go. However, I think
we should put aside supposed ICANN policy dictat unless and until
the above happens.

After all, we have had people who have suggested a requirement for
zone equivalence who have never pleaded 'ICANN says we must do it
and it must be done this way', and indeed never even mentioned ICANN.
I see no reason not to take those technical requirements at face value,
just because others have said "ICANN says it must be done this way".

I would agree that we should put ICANN's supposed policy requirements
aside until and unless we have have a concise statement of ICANN's
requirements through IETF-ICANN liaison rather than second guessing
what they might want and why from staff blogs etc.; I think it would
also be useful if at least some of the non-trivial nature of "well
just make the zones the same and everything will be fine" was
explained to them.

-- 
Alex Bligh

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Sep 2010 13:34:38 -0400

Thanks, that is my position as well.

---

From: David Conrad <[email-masked]>
Date: Wed, 1 Sep 2010 10:55:59 -0700

A clarification:

On Sep 1, 2010, at 9:01 AM, Andrew Sullivan wrote:
> is because they're a large, important registry

No they're not.  ICANN (via the IANA functions contract/historical reasons) is the registry for INT and via some combination of the IANA functions contract and RFC 3172, the registry for some of ARPA's children. None of these are very large and some might question their importance (e.g., see 'iris.arpa').  Those domains also aren't particularly relevant to IDN discussions.

> and we know they have

ICANN (through bottom-up, multi-stakeholder, blah blah blah processes and consultation with experts in the field) has come up with the consensus rules by which the "fast track" IDN top-level domains could be added to the root.  One of those rules was the synchronization hack. It may come as a shock, but I don't believe anyone in ICANN staff would claim to be an extreme experts on questions relating to IDN -- they rely on the community to provide cogent input. I personally do not know how the synchronization hack came to be imposed but I am fairly confident it was viewed as a temporary solution to enable forward motion on the "fast" track IDN effort.

I personally believe the right folks to provide the actual requirements aren't ICANN (who would be merely relaying requirements with potentially some loss of signal), but rather are the folks that are experiencing the problem: the folks at CNNIC, the folks in Greece, probably some folks in the Arabic world, etc.

Regards,
-drc

---

From: Ted Hardie <[email-masked]>
Date: Wed, 1 Sep 2010 10:55:19 -0700

On Wed, Sep 1, 2010 at 10:05 AM, Jim Reid <[email-masked]> wrote:
> Personally, I think there is an important problem in here somewhere. However
> it's not clear what that problem is or whether it is soluble.

The shortest formulation I have heard is that the DNS violates the
principle of least surprise for people using scripts other than ascii,
because what they see as "the same" are treated as "different"
when the DNS does its lookup.    There is one aspect in which
the DNS does not violate the principle of least surprise for users
of ascii (  example.com and EXAMPLE.com and EXaMPLE.CoM all
produce the same result).  Since users of ascii get this behavior,
users transitioning from the use of ascii to their native script
feel that their needs are not being met when what they perceive
as the same sort of variation is not handled the same way.

That is, if  China.com and CHINA.com and china.com
all produced the same result, why can't 中国.com and 中國com
work the same way?

All the talk of "expecting variants to work" really seems to be
modeled on the way upper and lower case are treated as
equivalent at the presentation layers (e.g. URI authority sections) feeding
into DNS processing. The problem is that users' understandings of
character equivalence
are often based on script and national rules, rather than pure
character variation, and these require
context that the DNS does not have.  (That is, there is no guarantee that
发 mapping to 髮 in some contexts in Hong Kong means that the first will
map to the
second in Japan; it's a property of Chinese as written in Hong Kong,
rather than the
character itself.  It may or may not be true in other contexts).

What we have discussed so far is allowing registrants (for some value
of registrant)
to work out what variants would be required to avoid violating the principle
of least surprise for their user communities, and to then maintain the resulting
zones and equivalences with the least pain possible.

Are they other ways to skin this cat?  Absolutely; a context-specific
presentation
layer that understood how to map from the user's entry to what the DNS expects
to look up would work just as well.  But because many of the players in
this game think in terms of registration entities, that has not been where the
pressure has been.  The presentation layer approach also has a number of
related risks (primarily in that variation there can cause the view of
the underlying
reality to shift depending on what presentation layer is in use, which
has a serious
set of implications).

>Or if a
> solution is best done in the DNS or elsewhere.
>

The final lookup will be done in the DNS no matter what, so I believe there
continues to be a need for DNS folk to be involved in crafting the solution,
even if a great deal of it gets pushed up the stack.

Two cents from my personal opinion penny jar,

Ted

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 1 Sep 2010 14:11:09 -0400

> No they're not.  ICANN (via the IANA functions contract/historical reasons) is the registry for INT and via some combination of the IANA functions contract and RFC 3172, the registry for some of AR…

ICANN via the IANA function isn't the registry for . ?  I guess I'm
confused.  If ICANN isn't that registry, then everything you said
follows, yes.

A

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

---

From: David Conrad <[email-masked]>
Date: Wed, 1 Sep 2010 11:35:30 -0700

On Sep 1, 2010, at 11:11 AM, Andrew Sullivan wrote:
> ICANN via the IANA function isn't the registry for . ?

An interesting question (i.e., is it ICANN, VeriSign, or NTIA who is "the registry" for ".").  In the zones I mentioned, ICANN has edit control over the zone so it is (IMHO) clear that ICANN is the registry.  In the case of the root, ICANN (via the IANA functions contract) merely requests changes to the zone.  We can probably quibble over the semantics, but I suspect we'd both prefer not to.

The real point is that ICANN (regardless of whether it is the registry or not) is reactive to community requirements: ICANN staff isn't making up those requirements out of thin air itself.  The folks who really matter in defining the problem and exploring potential solutions are the folks who are experiencing those problems and are looking for solutions.  Thomas/Tina/etc. would be merely relaying (possibly with some misinterpretation of) what they believe the problems/solutions to be.

Regards,
-drc

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Sep 2010 14:44:26 -0400

The root of the issue here is that we have one problem divided between
two separate consensus based organizations.

But we are at least narrowing down the real issue which is that we
have a group of people who want to achieve a specific effect and would
like to be able to thread it through the ICANN fast track process.

That only increases the need for an ICANN person here if we are going
to move on this.

We need to know what their criteria for fast track would be. Do we
have an SOA record to a delegate zone with the magic pointer or do we
put a magic pointer in the root? That distinction makes a huge
difference to the political and commercial issues.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 01 Sep 2010 15:03:10 -0400

>  ... I personally do not know how the synchronization hack came to be ...

(a) i do. even the choice of words, specifically "synchronous" was an 
individual's blunder.

> I personally believe the right folks to provide the actual requirements aren't ICANN (who would be merely relaying requirements with potentially some loss of signal), but rather are the folks that…

(b) agree. and the distance between (a) and (b) is sufficient. solve 
for (b), which is not one use case, nor the common case for string 
equivalencies, nor the general case for administrative convenience, 
and ignore (a).

to actual authorities listed in (b) i would add cary karp.

-e

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 1 Sep 2010 12:35:47 -0700

On Sep 1, 2010, at 12:03 PM, Eric Brunner-Williams wrote:
> (b) agree. and the distance between (a) and (b) is sufficient. solve for (b), which is not one use case, nor the common case for string equivalencies, nor the general case for administrative convenience, and ignore (a).
> 

Stupid question time again then:  The problem seems to be a language specific normalization problem.

As such, is it sufficient to have a relaxed equality constraint?  EG, A=B is only valid for a specific level, eg,

If at L1, A=B, that would imply A.A == A.B, but NOT B.A

If at L2, A=C, would imply that A.A == C.A.

And if both, that would be A.A == A.B == C.A == C.B

If thats sufficient, why doesn't something like BNAME suffice?  

The TLD could have a BNAME of B->A, and the second level could have a BNAME of C.*->A.A.  (Semantics might get weird if the second level BNAME was C.*->A.B, but there might be a way to handle this cleanly with some thought).

---

From: [email-masked]
Date: Wed, 1 Sep 2010 20:23:46 +0000

> The real point is that ICANN (regardless of whether it is the registry or not) is reactive to community requirements: ICANN staff isn't making up those requirements out of thin air itself.  The fol…

	I guess this whole thread begs the point about IETF not being a membership based
	organization. Historically the IETF has been pretty resistent to specific change
	requests from any given legal person/entity - e.g. the pushback to the NAV6TF etc
	as a trade group that wanted to engage with the IETF... they were told to participate
	as natural persons.   

	In this case, if there is a crisp definition of the problem space, which ICANN 
	spokesmodel is going to stand up and say; "It is the position of ICANN and its members
	that foo is the problem with bar, and as a unified consesus opinion of ICANN and its
	members, we would like the members of the IETF to consider this a problem worthy of
	their consideration."

	is that a board resolution?

--bill

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 01 Sep 2010 16:30:16 -0400

> ... The problem seems to be a language specific normalization problem.

well ... there's the han unification, which created the sc/tc 
"variants" off of a single script, coupled with some cctld idn ft 
anglophonic self-interest that produced the one-script-per rule, to 
which we find sufficient awkwardness to seek a relaxation ... my point 
being it isn't a property of chinese language under chinese encoding 
standards, but a property of some non-chinese encoding the ietf 
adopted as _the_ universal script encoding.

then there are the other two classes of problem, the (again) 
unification of the arabic influenced scripts into arabic Script, by 
the same entity, which had variants of its own (positional), before 
unification and the variants introduced by language differences using 
a common base script, and the greek tonos.

> And if both, that would be A.A == A.B == C.A == C.B

if you are directing your question to state actors and their 
registries, then state actor requirements may be arbitrary.
and see 1, 2, 3, implicit above.

if you are directing your question to non-state actors and their 
registries, then "commercially reasonable" terms may be possible.
and see 1, 2, 3, implicit above.

-e

---

From: Thomas Narten <[email-masked]>
Date: Wed, 01 Sep 2010 18:06:23 -0400

> Thomas Narten as the IETF's liaison to the ICANN Board. (The ICANN
> web site doesn't have an equivalent list of liaisons to other SDOs.)

Right. I am the Liaison *to* ICANN, not the other way around.

So, I can't speak authoritatively for ICANN. What I can do (sometimes)
is explain what I think ICANN is saying or trying to say, but that
would still just be my opinion, and not "authoritative".

If you want an authoritative statement from ICANN, they will have to
produce it.

> Thomas: there is a (so far unofficial) desire on the the part of the
> DNSEXT WG to hear from ICANN what its requirements are in order for
> us to move forward on possible WG work items. What is the best way
> for us to ask ICANN in an official fashion?

What I am hearing (and have been hearing on and off for some time) is
that DNSEXT doesn't understand what exactly the "requirements" for
variants are, or what the problem statement is. And ICANN seems to be
saying they need "something", but we don't understand what that
"something" is in enough detail and clarity to act on it or plot a
course forward.

I have to admit, I'm with the WG on that, as I do not understand what
it is in exact terms either. (Or exact enough terms that I'd feel
comfortable chartering work with a Good Feeling that it would produce
a Good Result.)

Opinion: Part of the problem here is that ICANN (to a large extent) is
just fronting the problems/issue of others when it talks about
variants. I.e., its users and TLD operators that want to use IDNs with
variants, so the problems/requirements really would best come from
them. (David Conrad stated that quite will, IMO.)

This is not an uncommon problem in the IETF, where we really want to
hear from the actual users/customers/deployers of a technology, so we
can make sure we actually solve the real problem that needs solving.
But instead hear from intermediaries such as vendors or researchers,
and the details of the problem don't come through clearly, or are a
mismatch with the real problems the user/operator has.

I (and some others following this list) are taking the above message
back to ICANN.

And to be clear, I think ICANN probably does have some input to add to
this discussion. As stewards of the TLD space and root zone, one would
hope that they have things to say about stability, security, quality
of user experience, etc.

Thomas

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 1 Sep 2010 18:55:20 -0400

You can't speak for ICANN but we can ask you to send a message to ICANN.

I think we need ICANN itself here and not just the people raising the
issue in ICANN because it is clear to me that at least a part of this
problem is political as opposed to technical and they are the people
who should understand what the political possibilities are in their
particular space. They are also the people that can go back to their
consensus process and explain what lies in the realm of the possible
and what does not.

We can certainly make changes to the DNS specs, but they will not have
any utility unless there are also changes to either deployed
application clients or deployed application servers.