Re: [DNSOP] draft-liman-tld-names-04

[Eric Brunner-Williams <[e-mail]>]

Morning Andrew,

On 11/16/10 9:53 AM, Andrew Sullivan wrote:

> ...  I was simply arguing
> that we can't re-open the entire protocol every time someone wants to
> write something that depends on it.

A reasonable observation. The responsibility to ensure that the 
nuances of dependency were correctly noted in the past, or are 
correctly noted in the present, remain. If only every "i" had been 
correctly crossed, every "t" correctly dotted...

> ... If one thinks that IDNA2008 is
> broken or otherwise wrong, the right thing to do is to go write the
> IDNA2008 Considered Harmful draft, not to try to sneak those
> criticisms in through the back door of a pure clean-up document
> designed only to permit the use of IDNA2008 in the top level.  If
> there is such a Considered Harmful draft floating about, then ICANN
> has the obligation to make decisions about whether to form its policy
> in light of that document.

Loosely speaking, there is something that superficially resembles an 
obligation, but there has been no structural presence of a protocol 
supporting organization on the ICANN Board since December, 2002, only 
non-voting liaisons, and up until the recent moment, NOMCOM selected 
voting members with general technical competencies, now more weighted 
to competencies other than technical. So organic to ICANN's decision 
making process, no such general obligation exists or is latent. 
Organic to its By-Laws, there is an obligation to consider advice from 
the GAC, could you point to an obligation to consider advice from any 
other body?

One could point to the "Standards" language in ICANN's various 
"Mission" documents and the IETF's "Standards Track" document series, 
but that does involve a significant passage of time, and timeliness 
appears to be relevant, and it is not clear that an enforceable 
contractual obligation arises from "mission" and "purpose" language.

The UniCadettes' TR46 is a "IDNA2008 Considered Harmful" document, not 
that I think it the best thinking on the subject, and it is hardly a 
secret that directionality leakage across label separators is a 
feature not desired, and ... There are major objections, such as TR46, 
and moderate objections such as the directionality properties of "." 
and non-separator repertoire character properties, which vary from 
minor nits to moderate (fixable) objections, such as those which 
rfc4317 addressed.

   The IETF is about protocol, and all this
> document is trying to do -- and it is explicit about this -- is to
> relax (carefully) a restriction that may or may not have been
> understood somewhere as a protocol restriction.

Intent is good. Details matter. i's and t's.

>> That one was surfaced at the Mexico ICANN, with some bright young thing
>> dreaming of ".4u", presenting at least two problems in presumed policy
>> land.
>
> Note that .4u is still simply not allowed by RFC 1123 or by this
> draft.  That is an all-ASCII label, not a U-label, and it is not
> alphabetic.  Therefore, not allowed.  ...

I've written a separate note on those issues.

> ... If someone at ICANN wants to
> change that, s/he will need to write a draft.

There's not that large a qualified labor pool there to author such a 
document, and there may be non-technical impediments to ordinary 
contributions as we know them, a property more generally true than I'd 
like -- I still recall one exit interview marked by reference to a I-D 
I'd written on parallelism, file systems, and name spaces.

> ... Or, of course, ignore
> the RFCs published by the IETF.  I'm sure the people at the ITU would be
> happy with that latter outcome.

There are a lot of RFCs that are ignored, as is the ITU-T. These are 
not relevant to the issues at hand. I think your final line falls 
under the heading "rhetorical excess" and is best ignored.

Eric