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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
