[council] Re: Proposed resolution on IDN

["Paul M. Kane" <Paul.Kane@reacto.com>]

Fellow NC members

I am unsure if we will be able to deal with this important issue in this
call but in light of the announcement by Verisign to take action on the
27th October the NC needs to address it within the next two weeks, else
any subsequent action will be futile.  

To assist in your deliberations here are some of the more technical
issues for your consideration as a foundation for seeking to delay the
introduction of iDN names into the zone as proposed.

Best

Paul

  o ACE-ACM-Z is not a standard it is just what the IETF working group
    has identified as our ACE of choice. ACE-ACM-Z has not had a last
call
    in the working group and the encoding and specification is subject
to
    change.

  o iDN names requires a 2 pahse process, namePrep or StringPrep which
has
    also changed but is not a standard and may change in the future.
    Stringprep has not had a last call in the IETF IDN working group and

    may change.

  o If registrars continue to use the old nameprep per the origional
    testbed specs  and RACE encode registrations while VGRS uses
ACE-ACM-Z
    in the zone files, there will be much confusion as all records
(registrar
    communication, whois etc) will be in RACE while ACE-ACM-Z is in the
    zone file. The registry and registrars must have a better method to
    manage migration as consumer confusion will be the only result.

  o the prefix for ACE-AMC-Z (RACE uses the prefix of bq--) has not
    been choosen yet. The prefix for ACE-ACM-Z will be chosen
    by the RFC Editor after the IESG approves the document which will
    happen after the last call in the working group. Since there is no
    assigned prefix VGRS should not proceed.

  o Any addition of iDN names to a gTLD zone shoud not occur durring a
    "testbed phase." the plilosophy of 'testbed' does not imply anything

    moving into production. We must only allow IETF standards in gTLD
    zones or risk the stability of the Internet as basing production
    practices on Internet-Draft documents is create instablity as drafts
    change and RFC documents do not change.