[gtld-tech] [eppext] I-D Action: draft-lozano-ietf-eppext-registrar-expiration-date-00.txt

Fri Jan 22 22:59:35 UTC 2016

Good point, Rubens, not everyone knows how the policy implementation process works at ICANN. The authoritative reference is https://www.icann.org/policy/implementation

Paraphrasing and summarizing what is explained there you have:

  1.  The gNSO (through a working group composed of community members) works on a certain matter and reach consensus on a “policy recommendation”
  2.  The gNSO council adopts the policy recommendation
  3.  The ICANN Board adopts the policy recommendation and directs ICANN staff to implement it
  4.  ICANN staff issues a call for (community) volunteers to form an Implementation Review Team that works with ICANN staff to  help draft the policy language and implementation plan
  5.  The draft policy language and implementation plan go for public comment
  6.  Draft policy language and implementation are updated as relevant based on comment (if necessary, go back to step 5)
  7.  Then you have a new policy (which is announced with an effective day for implementation)

The Thick Whois policy implementation is currently on step 5.

Regarding the reseller field (from the 2013 RAA), which is another field currently not passed from registrar to registry, we were thinking that this requirement would be covered by the drafts draft-zhou-eppext-reseller-mapping and draft-zhou-eppext-reseller.

Regards,

--
Francisco

On 1/21/16, 3:32 PM, "Rubens Kuhl" <rubensk at nic.br<mailto:rubensk at nic.br>> wrote:

Francisco,

It's possible that Jim and Scott were looking at https://www.icann.org/resources/pages/registrars/consensus-policies-en to find an in-force consensus policy covering such requirement. I tried finding it there as well and failed as well... that is consistent with the information that although the policy was approved by GNSO Council and the Board (https://www.icann.org/resources/board-material/resolutions-2014-02-07-en#2.c) has still not come through with its IRT (Implementation Review Team), which is why the document is still in public comment and the policy is still a draft.

So, perhaps the I-D is a few weeks premature and the registries opposing it might see first whether that really becomes in-force ?

I also wander what happened to the reseller information relaying, which was foreseen in the policy...

Rubens

Em 21 de jan de 2016, à(s) 20:51:000, Francisco Arias <francisco.arias at icann.org<mailto:francisco.arias at icann.org>> escreveu:

Hi Jim,

Please see https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-policy-draft-25nov15-en.pdf, particularly section 2.1, starting on page 8. This document is in public comment at https://www.icann.org/public-comments/rdds-output-2015-12-03-en until 31 January.

The draft provides a reference to the “parent” document of the aforementioned document, which is already in final form. Perhaps the reference in the draft should be to the child document?

Regards,

--
Francisco

On 1/21/16, 12:08 PM, "EppExt on behalf of Gould, James" <eppext-bounces at ietf.org<mailto:eppext-bounces at ietf.org> on behalf of JGould at verisign.com<mailto:JGould at verisign.com>> wrote:

Gustavo,

I agree with Scott, it is not clear the relationship between the two and the relevance in the registry of maintaining this value.  Can the registrar expiration date be greater then the domain expiration date, less then the domain expiration date, or completely different from the domain expiration date?  The reference for the ThickWhoisPolicy is incorrect in the draft.  Please provide the appropriate reference and highlight where in the Thick Whois Policy it defines the requirement for the registry to hold and display a registrar expiration date in addition to the authoritative domain expiration date.

Thanks,

—

JG

James Gould
Distinguished Engineer
jgould at Verisign.com<x-msg://42/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://verisigninc.com/>

On Jan 21, 2016, at 2:52 PM, Hollenbeck, Scott <shollenbeck at verisign.com<mailto:shollenbeck at verisign.com>> wrote:

-----Original Message-----
From: I-D-Announce [mailto:i-d-announce-bounces at ietf.org] On Behalf Of
internet-drafts at ietf.org<mailto:internet-drafts at ietf.org>
Sent: Thursday, January 21, 2016 2:30 PM
To: i-d-announce at ietf.org<mailto:i-d-announce at ietf.org>
Subject: I-D Action: draft-lozano-ietf-eppext-registrar-expiration-
date-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

       Title           : Registrar Registration Expiration Date
Extension Mapping for the Extensible Provisioning Protocol (EPP)
       Author          : Gustavo Lozano
Filename        : draft-lozano-ietf-eppext-registrar-expiration-
date-00.txt
Pages           : 15
Date            : 2016-01-21

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension mapping for the provisioning and management of the
  registrar registration expiration date for domain names stored in a
  shared central repository.  Specified in XML, this mapping extends
  the EPP domain name mapping.

Gustavo, I wish this document would explain what this value actually means given that registrars are not the authoritative source of information for domain expiration dates. Could you please add some text to the Introduction that explains the purpose of the value and what it means of the context of the expiration date maintained by registries? Can they ever be different? What does it mean if they are different? Why are both needed if they are supposed to be the same?

I'd also like to suggest that you add text to the different command descriptions to make it clear what the values represent when you're extending a renew, transfer, etc.

Scott

_______________________________________________
EppExt mailing list
EppExt at ietf.org<mailto:EppExt at ietf.org>
https://www.ietf.org/mailman/listinfo/eppext

_______________________________________________
EppExt mailing list
EppExt at ietf.org<mailto:EppExt at ietf.org>
https://www.ietf.org/mailman/listinfo/eppext

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20160122/a61ed59f/attachment-0001.html>