Gustavo, Pending understanding and agreeing to the definition and purpose of the “registrar registration expiration date”, I have following feedback on the draft:
Why include a synchronization feature in the draft between two independent attributes? It’s best to treat these attributes, no matter the purpose of the “registrar registration expiration date” as separate attributes with no form of automatic synchronization. Enable the setting and unsetting of the attribute by the client and that’s it. Based on this, I recommend removing the use of the <rrExData:syncRyExpDate> element and simply include date under the <rrExDate:rrExDateData> element. You could rename the <rrExData:rrExDateData> element to <rrExDate:rrExDate> with a date value or an empty element to indicate no value. My recommendation is to only extend the domain create, domain update, and the domain info response to be able to set the attribute upon create, update it when the registrar changes the data, and get the current value via the domain info response. Passing the registrar registration expiration date for the operations that impact the registry expiration date like renew and transfer doesn’t cover all of the actions that impact the registry expiration date, and tries to tie the two dates that are independent. The registry expiration date is impacted by auto renew, by deletes within applicable grace periods that may be restored, and other custom operations like sync. My recommendation is to treat the registrar registration expiration date as an optional attribute that is separate from the registry expiration date, which means that it can be set with a create and updated via an update. For the domain info response extension, it should be that "the server MUST include the <rrExData:rrExDateData> in the <extension> section of the EPP response if the registrar registration expiration date has been set and the client supports the extension based on the login services.” — JG James Gould Distinguished Engineer jgo...@verisign.com <applewebdata://FF0429D5-C2F8-4B04-93D8-5B3FA83D4D24/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> > On Oct 26, 2016, at 7:15 AM, Hollenbeck, Scott <shollenb...@verisign.com> > wrote: > >> -----Original Message----- >> From: I-D-Announce [mailto:i-d-announce-boun...@ietf.org] On Behalf Of >> internet-dra...@ietf.org >> Sent: Tuesday, October 25, 2016 5:39 PM >> To: i-d-annou...@ietf.org >> Subject: I-D Action: draft-lozano-ietf-regext-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-regext-registrar-expiration- >> date-00.txt >> Pages : 13 >> Date : 2016-10-25 >> >> 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. > > Quick comment that is a repeat of something I said in some other context at > some other time (sorry, it's all a bit of a blur): > > This document needs to add a paragraph or two that explains *exactly* what a > "registrar registration expiration date" is and how it relates to the > <domain:exDate> element defined in RFC 5731. The draft defines the mechanics > for the extension, but it doesn't provide enough information to explain what > this value is, what purpose it serves, and why it might differ from the > exDate. The informative reference to the "GNSO Council Policy Recommendations > for a new Consensus Policy on Thick Whois" mentions a registrar expiration > date, but it doesn't explain what it is, either. > > Scott > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
