[registrars] Update on yesterday's NC call....

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

Update on yesterday's NC call.  We made some progress.....

Transfer issue ..... there was support for the Registrars position ...
and as
agreed during our Registrars tel conf there would be a two tier approach
with a fast track policy position and the constituency approach such
that the NC could come to a consensus policy in MdR.  A small task
force..... has been created, one NC rep from each constituency which
will review the Registrars teansfer paper to make SURE there is a motion
for a consensus position vote in MdR.

iDN (Rick .... supplied me with excellent material below- thanks again
Rick) .... Not sufficient discuss this issue in detail but it was agreed
that a NC resolution would be drafted within the next 5 days and
presented for a vote within 7 days to "delay" the 27th October date
either for IETF standard or such time that is consiered reasonable......
do bear in mind the Registrars will bear the cost of implementation,
changing the encoding specs, customer support (complaints)- as the names
won't work!- and educating their customers... with little chance to
provide
value added services as there are no applications funcionaliting for
iDNs .... (Please note Verisign will be moving to the IETF standard when
it is finalised and that is expected ......... (soon)!!!!

The advice of the Registrar Excom is to wait until the IETF have
finalised the iDN Standard but we need your thoughts on the iDN issue
asap.

Best

Paul

Rick's notes follow

  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.



Best

Paul