Subject: Who's problem? (was Re: [idn] Mixed TC/SC (was Re: Layer 2 and "idn identities")

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 07 Dec 2001 08:28:10 -0500

Like Scott, I think I understand Rick's note, and like Scott, something in
my understanding needs checking.

> > The only entity that can define what is and is not allowed in domain names
> > (not host names) is ICANN and although they have doen it before, it
> > doesn't happen often.

True for those operators that delegate this policy to ICANN. This includes
gTLD (unrestricted and restricted), the .AU ccTLD operator. At the moment,
I'm personally not aware of any other TLD operator that has delegated this
policy to ICANN.

> > If you want to continue down this path I suggest you submit a proposal to
> > the DNSO and that it is not a path we wish to take in this wg.

Assuming that the scope of the policy sought includes the set of operators
and their domains for which ICANN, and thus its DNSO, are the delegated
policy formation bodies.

It is worth reminding ourselves from time to time, that some IANA root TLD
operators (other than Verisign) have operational practices that differ from
the current ICANN gTLD contract.
...
>
> The responsibility and expertise to define domain and host name formats lies
> with the IETF.

Assuming the ICANN MOU, s/IETF/PSO/, and of course we all hope that in this
context, the ITU, W3C, and ETSI are non-contributory. Again, ICANN itself is
binding as the policy making body only where there is consent, currently
limited to com/net/org/info/biz/pro/museum/coop/aero, and AU, again AFAIK.

>             ... The DNSO is responsible for determining the policy aspects
> of how those identifiers are used.  This implies that the IETF should strive
> to develop policy-neutral engineering solutions.

Which leads me back to zone-scope, which existed in version 4 of the Seng/
Wenzel draft as [35], and as [30] in versions 5, and 6 of that draft.

It is a policy to require zone-scope mechanism(s) not exist in the IETF work-
product, and that policy promotes some local policy, possibly .com's to global
scope.

It is a policy to require zone-scope mechanism(s) do exist in the IETF work-
product, and that policy is neutral w.r.t. policies and scope.

Even when some "law of least astonishment" is cited as an excuse to pursue
a single-scope mechanism, in my mind, within the framework of rfc2826, and
the MOU, the "customer" is not ICANN uniquely, but ICANN and the TLD and
root zone operators, and they don't agree on policy.

> Is the issue of mixed TC and SC an engineering issue, or a policy issue?  I
> haven't seen much on this thread to suggest that an engineering issue
> exists.  If registrar or registry guidelines are being described as the way
> to resolve the issue, Rick is probably right about this not being an IETF
> issue, but a DNSO issue.

Here I differ with my learned colleges. I know we are dealing with a problem
of mechanism, and if it were a DNSO issue, there is little reason to conclude
that the gTLD and ccTLD registries would, absent controlling policy, construe
identical, or even consistent guidelines.

I appreciate the opportunity to have observed ICANN process first-hand at all
three of its meetings this year, and to have observed CDNC and JET process as
well. It has been educational.

Eric

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Dec 2001 09:36:38 -0500

Eric,

I agree with much of this analysis, disagree with a bit, and
suggest that some qualification or explanation may be in order
for the others.  Let me focus on the latter two categories...

--On Friday, 07 December, 2001 08:28 -0500 Eric Brunner-Williams

>> > The only entity that can define what is and is not allowed
>> > in domain names (not host names) is ICANN and although they
>> > have doen it before, it doesn't happen often.
> 
> True for those operators that delegate this policy to ICANN.
> This includes gTLD (unrestricted and restricted), the .AU
> ccTLD operator. At the moment, I'm personally not aware of any
> other TLD operator that has delegated this policy to ICANN.

ICANN has three types of authority in this (and several other)
area(s).

	* One is contractual or otherwise formal, and that is
	what you are referring to here: A TLD (or, in principle,
	lower-level domain) agrees to delegate certain decisions
	to them, as you suggest.  The "agreement" may be
	voluntary or thrust upon them; makes little difference.
	
	* The second is moral and/or advisory.  ICANN can make
	recommendations to domains, registrars, or registries as
	to what they ought to do.  Those domains, registrars, or
	registries can follow the advice or not as they deem
	appropriate and useful.  It is worth remembering that
	anything the IETF does in terms of a standard is in this
	same category: we have no authority, other than
	persuasion, to force anyone to conform to a standard or
	to do anything else we recommend.
	
	* And the third is that, in principle, ICANN can remove
	an offensive party/ TLD from the root or redelegate a
	domain against the wishes of the administrative contact
	and relevant legal authorities.   I hope they never try
	this,  at least without very broad public support in
	advance, because I don't want to think about what would
	happen if they did.  But it is possible.

None of this differs from the status of IANA long before ICANN
came into being, except that IANA never resorted to a contract.
The tools were recommendations, education, persuasion, and the
implied threat of involuntary redelegation.

>> > If you want to continue down this path I suggest you submit
>> > a proposal to the DNSO and that it is not a path we wish to
>> > take in this wg.
> 
> Assuming that the scope of the policy sought includes the set
> of operators and their domains for which ICANN, and thus its
> DNSO, are the delegated policy formation bodies.

I am not aware of anything in the DNSO's charter that would
prevent their generating recommendations about best practices
that would apply to all domains, independent of where they could
enforce such recommendations.  Of course, there is a separate
problem, which is that the DNSO rarely demonstrates an ability
to agree on anything more sweeping than when to hold a NC
meeting :-(
 
> It is worth reminding ourselves from time to time, that some
> IANA root TLD operators (other than Verisign) have operational
> practices that differ from the current ICANN gTLD contract.
> ...

I agree completely. But that doesn't seem to have anything to do
with either IETF's scope, ICANN's scope, or whether
recommendations to domains ("registries") are possible.  In
principle, the IETF could make a recommendation in this area
too: we make operational recommendations fairly regularly.  But
such recommendations aren't in the IDN WG's charter, so anyone
wanting to generate such a document should probably start
charter-drafting.   And, without having consulted anyone on the
IESG about this, I'd guess that the threshold for convincing
them that the IETF actually should take on such work would be
quite high.  But, again, to suggest that we could not make such
a recommendation would be going a bit past the facts and history.

>> The responsibility and expertise to define domain and host
>> name formats lies with the IETF.
> 
> Assuming the ICANN MOU, s/IETF/PSO/, and of course we all hope
> that in this context, the ITU, W3C, and ETSI are
> non-contributory. 

Actually no, the IETF, subject to the comments above.  The PSO
would, as I understand both the MOU and current practice, get
involved only under one of two scenarios: (i) if there were a
dispute among the SDOs about the allocation mechanisms for
protocol parameters that could not be settled bilaterally or
(ii) if the DNSO or ASO or ICANN Board were about to generate a
policy or recommendation that might have technical impact.  It
would really be stretching the imagination to believe that the
formats of domain (or host) names were "protocol parameters".
And the PSO is carefully designed to avoid situations in which a
technical matter can be settled by majority vote.

> Again, ICANN itself is binding as the policy
> making body only where there is consent, currently limited to
> com/net/org/info/biz/pro/museum/coop/aero, and AU, again AFAIK.

And IETF itself is binding on nothing.  So?

> I appreciate the opportunity to have observed ICANN process
> first-hand at all three of its meetings this year, and to have
> observed CDNC and JET process as well. It has been educational.

See if you still believe that after a few more years of such
"education"  :-(

    john

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 07 Dec 2001 10:32:34 -0500

John,

My point in mentioning mechanism and scope is that if a mechanism is
incapable of scope, it's deployment may be "scoped", and that has some
consequences. If a mechanism is capable of scope, it's deployment may
not be scoped, though its policy instantiations may be.

I'm on a list with about a half-dozen other parties, and for the life
of me, I can't see a common intent to obtain technical cooperation and
consistency on that list. Enlarging the stage to include the DNSO as a
policy making body, and assuming that a single guideline will arise is
simply contrary to my understanding of some of "our customers".

I'm concerned by a presumption of universal applicability. Persuasion
is the better authority.

Eric

P.S. This list could use a meta- list.

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Dec 2001 10:31:54 -0500

Hmm.   After reading Eric's comments, I think I finally
understand the zone-scope problem and the associated
"requirements" issue.   And I have probably been part of the
source of confusion, for which I apologize.   Of course, I could
be wrong; I may still not understand it.

There are, I think, two rather separate "zone scope" problems:

(i) May different zones have different policies about what sorts
of names are permitted to be registered and how they are managed
within those zones?  I think that is (at least most of) the
issue Eric addresses below, certainly it is the issue if we are
getting into debates about what ICANN can or should try to
mandate.

My answer to that one is "yes, of course".  It has always been
that way and it should continue be that way, subject only to
constraints of operational (and interoperational) necessity.
And I would suggest that it is not an IETF problem, except
insofar as we need to provide information and guidelines about
the types of policies that would interfere with successful
global interoperation (see other note about engineering/policy
interactions).

Because I don't think of this as an IETF problem --and because
it seemed completely obvious to me-- it didn't occur to me that
this might be the meaning intended in the statement in the
requirements doc drafts.

(ii) May different zones adopt different ways to resolve or
interpret names, i.e., may they have local variations on the
protocols themselves?  My response to that one would be that the
DNS needs to work globally or it essentially does not work at
all. The combination of caching and cross-tree links makes it
almost impossible to localize a particular protocol variation
and the notion of having TLD-specific code cases in each
resolver is appalling (and something we could never get to work
reliably over time).  So we can't have, e.g., different
name-encoding (ACE or otherwise) strategies which are
interpreted depending on which TLD is in use, etc.  And _that_
is what I've been assuming we were talking about when we've
talked about zone-specific rules.

Was anyone else equally confused?   Does that help with the
confusion?  Is there any chance that we actually agree about
this?

    john

--On Friday, 07 December, 2001 08:28 -0500 Eric Brunner-Williams
in Portland Maine <[email-masked]> wrote:

>>             ... The DNSO is responsible for determining the
>>             policy aspects of how those identifiers are used.
>> This implies that the IETF should strive to develop
>> policy-neutral engineering solutions.
> 
> Which leads me back to zone-scope, which existed in version 4
> of the Seng/ Wenzel draft as [35], and as [30] in versions 5,
> and 6 of that draft.
> 
> It is a policy to require zone-scope mechanism(s) not exist in
> the IETF work- product, and that policy promotes some local
> policy, possibly .com's to global scope.
> 
> It is a policy to require zone-scope mechanism(s) do exist in
> the IETF work- product, and that policy is neutral w.r.t.
> policies and scope.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 07 Dec 2001 11:42:00 -0500

John,

These are the operative clauses of [30] (nee [35]), from the Seng/Wenzel
text, as points in time (-04, -05, -06) prior to the present:

	within a single zone
	the zone manager
	MUST be able to
	define equivalence rules

This does not speak to what names are permitted or how they are managed,
your (i), but to equivalencey rules, your (ii) -- the iceberg about which
we've been beating for above six months.

I appreciate your response, but like mine, it isn't the opinion of the
dns experts to whom an IDN "recommended solution (involving the DNS)" may
be forwarded on to. If the DNSEXT WG can't consensus that a mechanism
may be scoped, then a requirement such as [30] _can't_ be satisfied. If
on the other hand, they are divided (no pun intended) on the issue, or
consensus to the affirmative, then the lack of a capacity for scoping is
possibly justified on grounds other than technical infeasibility.

Let's stick to (ii). If we were doing (i) then we'd be discussing whether
palindrome-only and rent-by-the-day operational practices in zone A were
permitted, while zone B has a must-be-a-trademark-when-reversed and yearly
rentals. There would be humor, even some sensible business rules, but not
a lot of technical matter.

Eric