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

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

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