Another Transition Plan Proposal

[Vint Cerf]

Cary,

having the ICANN Guidelines group undertake to develop and
express transition tactics for zone administrators to select for
adoption, based on the extant IDNA2008 documents, strikes
me as a very potent solution to the problem the IDNABIS WG
has had in reaching common views on transition plans.

Your idea draws a broader range of informed participants
to the problem and also recognizes the essential autonomy
of the registries to adopt practices as they see fit, as long as
these don't violate technical standards.

I would consider it a courtesy if you would offer to the
ICANN Guidelines group both the current IDNA2008
documents and the most recent proposed transition idea
that has been circulated. Since you are also aware of
the several other ideas discussed on the IDNA-UPDATE
list, you are in a position to draw these ideas to the Guidlelines'
group attention.

Assuming there is no objection from the IDNABIS working
group to this proposition, I would argue that the WG has
completed its technical work on the standards and that
the transition question is moved to the ICANN Guidelines
group for analysis and consideration.

Vint


On Dec 16, 2009, at 7:19 AM, Cary Karp wrote:

> Quoting John:
>
>> Procedural question, just out of curiosity and independent of
>> other issues. A BCP like the one you describe would require
>> either a significant charter revision (to add the task) or a new
>> WG.
>
> There is no way to override the autonomous authority that a zone
> administrator has for implementing such things as support for IDN
> without rescinding the basic tenet of the DNS that distributes such
> responsibility together with zone delegation. To be sure,  
> implementation
> guidelines can be enormously useful in ensuring reasonably homogeneous
> practices Net wide. With one single but rather important exception,
> however, the acceptance of guidelines from any source is a voluntary
> act. As far as the gTLDs are concerned, compliance with the ICANN IDN
> Guidelines (to which I've already made several references) is a
> contractual obligation.
>
> I am a signatory to such a contract (.MUSEUM) and oversee that TLD's
> day-to-day operation. I also hold the pen in the group that develops  
> the
> Guidelines and am, or have been, a member of other IDN advisory groups
> within ICANN, with authorial or editorial involvement in the texts  
> they
> produce. I apologize for the immodesty of this recital, but feel it
> necessary as a disclaimer for the following text. It may, however,  
> also
> be taken as a "claimer" of a pretty good degree of understanding of  
> the
> practical operational and policy details that it addresses.
>
> The gTLDs cannot undertake any commitment to implement comparable IDN
> recommendations codified elsewhere, unless there is an absolute
> guarantee that those recommendations will never be at odds with the
> ICANN Guidelines. (It is hard to imagine how any such assurance  
> could be
> provided, but individual registries obviously can and do build on the
> Guidelines in accordance with the needs of their local  
> constituencies.)
> A good number of ccTLDs have also voluntarily accepted the Guidelines
> and contribute to their development. There have also been reassuring
> indications that other zone administrators have an eye on them and  
> find
> them useful.
>
> I would therefore like to propose that the group that maintains the
> ICANN Guidelines (many of whom are in our own midst) be accepted as  
> the
> functional equivalent of any IDN BCP WG that our WG might consider
> spawning. The mandate of the ICANN group ensures that its members have
> immediate experience with the operation of registries that support  
> IDN,
> and have dealt with policy and technical issues that are easily as
> intricate as the ones still under consideration here, in the actual  
> DNS
> production environment.
>
> The authorship group is convened by Tina Dam, who also sets its  
> agenda.
> I'm normally the one to block out new text for the group's  
> consideration
> and can guarantee that the wisdom generated in the IDNABIS WG will be
> explicitly reflected and acknowledged. ICANN provides a venue for open
> public commentary on documents such as the Guidelines, which are
> formally approved by the ICANN Board (several members are also here)
> before entering into effect. The Board also provides a buffer for the
> ever-so-delicate political aspects of making recommendations to
> governments in matters that they regard as their own sovereign  
> concern.
> ICANN has additional relevant communication channels that lack  
> parallel
> in the IETF but will be harnessed if the procedure I'm suggesting is
> acceptable.
>
> This all means that the concerns of our WG are known on the ICANN side
> without need for constructing mediation channels. I can also make sure
> that regular reports will appear on this list about the details of
> Guideline development that are of present concern (either simply by
> doing the job myself or recruiting another member of the Guidelines
> group for it). These reports can easily also be forwarded to the  
> DNSOPS
> mailing list.
>
>> Would people like/intend to block the existing documents until such a
>> BCP can be developed and consensus received on it?  Or is it possible
>> to get the current documents out and then start work on the BCP?
>
> The protocol statement has to be a common-denominator instrument that
> can be applied to the administration of all zones. Implementation
> requirements vary intrinsically from zone to zone in response to local
> needs. It is therefore highly advisable, if not flat out necessary, to
> articulate implementation detail in a separate vehicle.
>
> I hope that I have described a ready alternative that will allow us to
> move forward on both fronts. Unless we wish to see major portions of  
> our
> documents prove irrelevant, we'd better finalize them well enough in
> advance of the appearance of A-labels in the root zone for them to  
> be of
> use in establishing the operational policies of the designated TLDs  
> (to
> say nothing of proposals that are currently being drafted for
> IDN-labeled TLDs in broader generic contexts).
>
> /Cary