ICANN ICANN Email List Archives

[gnso-irtpc]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-irtpc] Recommendation Charter Question C

  • To: Paul Diaz <pdiaz@xxxxxxx>, "Mike O'Connor" <mike@xxxxxxxxxx>
  • Subject: Re: [gnso-irtpc] Recommendation Charter Question C
  • From: Marika Konings <marika.konings@xxxxxxxxx>
  • Date: Tue, 29 May 2012 10:22:09 -0700

If I've understood the comments on the call today correctly, I think the main 
concern with the proposed language by the RySG was that it seemed to suggest 
that new registries should not be allowed to use proprietary IDs, which I don't 
think was the intent of the RySG or the WG (but please correct me if I am 
wrong). If this assessment is correct, a possible solution could be to add one 
sentence to the language proposed by the RySG (in between brackets and bold):

The WG recommends that all gTLD Registry Operators be required to publish the 
Registrar of Record's IANA ID in the TLD's thick WHOIS. Existing gTLD Registry 
operators that currently use proprietary IDs can continue to do so, but they 
must also publish the Registrar of Record's IANA ID. [This recommendation 
should not prevent the use of proprietary IDs by gTLD Registry Operators for 
other purposes, as long as the Registrar of Record's IANA ID is published in 
the TLD's thick Whois].

Does this make sense?

Best regards,

Marika

On 29/05/12 18:30, "Paul Diaz" <pdiaz@xxxxxxx<mailto:pdiaz@xxxxxxx>> wrote:


Just get to the crux of the matter:

The WG recommends that all gTLD Registry Operators be required to publish the 
Registrar of Record's IANA ID as a distinct field in the TLD's thick WHOIS.  
Existing gTLD Registry operators that currently use prorprietary IDs can 
continue to do so, but they must also publish the Registrar of Record's IANA ID.

Proprietary IDs are used by a number of Registry Operator for essential 
back-end operations.  "Encouraging" the "exclusive use" of IANA IDs (in place 
of the proprietary numbers) is NOT in this WG's remit as it would effectively 
be dictating a business model.

The WG is charged with looking into ways to to facilitate transfers and save 
Registrars the extra step of having to look up the proprietary IDs?  Ok.  Then 
just require that the IANA ID has to be clearly published in the thick Whois 
output.  Other fields not connected to the transfer process are of no 
consequence to this WG.

If anything, "proprietary IDs" are going to be even more commonplace when new 
gTLDs come to market as the finite pool of back-end operators will need unique 
ways of tracking registration partners for the various TLDs under their 
management.

Best, P


On May 29, 2012, at 11:54 AM, Mike O'Connor wrote:

here's a go at the Charter Question C stuff

PREVIOUS TEXT:  Recommendation Charter Question C: the WG recommends that new 
Registries standardize onIANA IDs. The WG also recommends that existing 
Registries that currently use proprietary IDs switch to use IANA IDs, but these 
Registries will be allowed to maintain the option to continue to use their 
proprietary IDs. Finally the WG recommends that the option to maintain the use 
of proprietary IDs be reviewed in 24 months and reconsidered at that point in 
time.

PROPOSED TEXT:  Recommendation Charter Question C: the WG recommends that new 
gTLD Registry Operators standardize on IANA IDs and that all Registry Operators 
must publish the Registrar of Record's IANA ID. The WG encourages existing 
Registry Operators that currently use proprietary IDS to consider transitioning 
to the exclusive use of IANA IDs, but notes that there are operational issues 
that may make this very difficult.  Thus Registry Operators that currently use 
proprietary IDs can continue to do so, but they must also publish the Registrar 
of Record's IANA ID.

mikey


- - - - - - - - -
phone  651-647-6109
fax   866-280-2356
web  http://www.haven2.com<http://www.haven2.com/>
handle OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)






<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy