April 2015 - gtld-tech - lists.icann.org

Publishing of the Change Poll EPP Extension IETF Draft
by Gould, James July 7, 2015

July 7, 2015

The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/html/draft-gould-change-poll-00 ) has been submitted to the IETF. I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify clients of any server-side change, including but not limited to regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-data of what, when, who, and why. We would like this draft to be included in a re-charting of the EPPEXT Working Group. Please review the draft and provide any feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

2 2

Re: [gtld-tech] [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft
by Rubens Kuhl May 31, 2015

May 31, 2015

James et al, Has the use case of DNS publishing been considered for the changepoll extension ? Some registries defer publication of a domain to the registry zone until DNS servers respond correctly (authoritative, DNSKEY matches DS etc.), and a poll message could signal that to the sponsoring client. I couldn't find an appropriate operation in changepoll-02... what are your and the group's thoughts on this ? Rubens > Em 30/01/2015, à(s) 11:53:000, Gould, James <JGould(a)verisign.com> escreveu: > > Ulrich, > > Thank you for the review of the draft. My feedback is embedded below. > > I received private feedback to add an optional caseId element to help capture the UDRP, URS, or other case identifier for the change. The optional caseId element was added with an enumerated “type” attribute, with the enumerated values of “udrp”, “urs”, and “custom”, and with an optional “name” attribute for the “custom” type. Are there any additional case types that should be included in the enumerated list? You can see the latest updates of the draft using the GitHub project https://github.com/james-f-gould/EPP-Change-Poll.git <https://github.com/james-f-gould/EPP-Change-Poll.git>. > > — > > JG > > > <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png> > > James Gould > Distinguished Engineer > jgould(a)Verisign.com <x-msg://23/jgould@Verisign.com> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > VerisignInc.com <http://verisigninc.com/> > On Jan 30, 2015, at 4:08 AM, Ulrich Wisser <ulrich(a)wisser.se <mailto:ulrich@wisser.se>> wrote: > >> Hi James and Trung! >> >> You two did a nice job on the extension. >> >> I would prefer the transform command instead of the info response. That would eliminate the need for before/after indicator. > > You mean you want to see the full input transform command in the poll message? Most of the server-side operations don’t go through EPP, so it would be a challenge to attempt to present the input prior to executing the operation using an EPP transform command. Another issue with using a transform command is representing the server-side logic that is not reflected in the input parameters like the setting of the expiration date. The client can see the end result of the operation without having to replicate the transform operation logic, along with the meta-data about the operation using the info response. > > One question for the list is the value in making the before image of the object available? The after image is required, but the thought is that the before image may be desired. > >> >> I have some problems with the operators >> >> - Why is autoRenew a special operation instead of operation renew with op="auto”? > > I agree that both are associated with renewing the domain; although I view them as separate first class operations with different characteristics (What drives the operation, how does the operation function, and what is the applicable grace period for the operation). > > >> - What is the difference between delete and delete op="purge”? > > Good question. Purge is associated with physically removing the object from the database where the delete could start an RGP lifecycle flow. An immediate delete (e.g. delete within the add grace period) is reflected by a “delete” with the op=“purge”; otherwise it would be just “delete”. > >> - Why autoPurge / autoDelete? > > Another good question. What if for some registries the domain is deleted instead of auto renewed at expiry? That would match the use of the “autoDelete” operation. Now, the “autoDelete” could include the purging of the object which would be reflected by setting op=“purge”. The autoPurge operation is the server batch that physically purges the object (domain) at the end of the pendingDelete period. In this case the domain has been deleted, put through the RGP lifecycle flow, and is being purged from the database. We wanted to handle both types of registries (auto renew and auto delete) as well as be able to identify the event when the object is purged from the database. I hope this makes sense. > >> >> Kind regards from Stockholm >> >> Ulrich >> >> >> >> 2015-01-20 14:49 GMT+01:00 Gould, James <JGould(a)verisign.com <mailto:JGould@verisign.com>>: >> The first draft of the Change Poll EPP Extension ( http://tools.ietf.org/html/draft-gould-change-poll-00 <http://tools.ietf.org/html/draft-gould-change-poll-00> ) has been submitted to the IETF. I co-authored this draft with Trung Tran from Neustar to provide a mechanism within EPP to notify clients of any server-side change, including but not limited to regular batch processes, customer support actions, Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid Suspension (URS) actions, court directed actions, and bulk updates based on customer requests. Since the client is not directly involved or knowledgable of these operations, the extension is used along with an EPP object mapping to provide the resulting state of the post-operation object, and optionally a pre-operation object, with the operation meta-data of what, when, who, and why. We would like this draft to be included in a re-charting of the EPPEXT Working Group. >> >> Please review the draft and provide any feedback. >> >> Thanks, >> >> — >> >> JG >> >> >> <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png> >> >> James Gould >> Distinguished Engineer >> jgould(a)Verisign.com <http://jgould@verisign.com/> >> >> 703-948-3271 <tel:703-948-3271> >> 12061 Bluemont Way >> Reston, VA 20190 >> >> VerisignInc.com <http://verisigninc.com/> >> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.” >> >> >> _______________________________________________ >> provreg mailing list >> provreg(a)ietf.org <mailto:provreg@ietf.org> >> https://www.ietf.org/mailman/listinfo/provreg <https://www.ietf.org/mailman/listinfo/provreg> >> >> >> _______________________________________________ >> EppExt mailing list >> EppExt(a)ietf.org <mailto:EppExt@ietf.org> >> https://www.ietf.org/mailman/listinfo/eppext > > _______________________________________________ > EppExt mailing list > EppExt(a)ietf.org <mailto:EppExt@ietf.org> > https://www.ietf.org/mailman/listinfo/eppext <https://www.ietf.org/mailman/listinfo/eppext>

3 4

Re: [gtld-tech] Whois Advisory - upcoming publication
by Francisco Arias April 27, 2015

April 27, 2015

Colleagues, Just to let you know that the final Whois advisory has been published at https://www.icann.org/resources/pages/registry-agreement-raa-rdds-2015-04-2…, the effective date is 31 January 2016. As explained in the announcement (https://www.icann.org/news/announcement-2015-04-27-en) contracted parties will receive formal notice within the next two weeks. Regards, -- Francisco. On 4/14/15, 1:01 PM, "Francisco Arias" <francisco.arias(a)icann.org<mailto:francisco.arias@icann.org>> wrote: Dear RrSG and RySG members and colleagues, Attached please find the draft Whois advisory that ICANN intends to publish as final by 27-Apr-2015 with an effective implementation date of at least, 6 months after publication (final effective date TBD), providing contracted parties ample time to implement any necessary changes. As you may know we have had several interactions between ICANN and the community to define the contents of the Advisory. We believe this Advisory incorporates the input received and is ready for publication. We wanted to give a heads up to the contracted parties and the community in general of the upcoming publication. Thank you again for your time and your constructive inputs. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

1 0

Call for Presentations for TechDay at ICANN Buenos Aires
by Dr Eberhard Lisse April 21, 2015

April 21, 2015

Hi, As usual we shall be organizing TechDay on Monday of the coming ICANN meeting in Buenos Aires. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz As we have a very small budget presenters are responsible for their own transport and room and board, though we might be able to assist the most riveting proposal :-)-O As the name suggests, talks must be of a technical (or operational, perhaps even administrative) nature, and should revolve around TLDs, but otherwise we are quite open. Please forward this to gNSO and other lists as well :-)-O greetings, el

1 0

Whois Advisory - upcoming publication
by Francisco Arias April 14, 2015

April 14, 2015

Dear RrSG and RySG members and colleagues, Attached please find the draft Whois advisory that ICANN intends to publish as final by 27-Apr-2015 with an effective implementation date of at least, 6 months after publication (final effective date TBD), providing contracted parties ample time to implement any necessary changes. As you may know we have had several interactions between ICANN and the community to define the contents of the Advisory. We believe this Advisory incorporates the input received and is ready for publication. We wanted to give a heads up to the contracted parties and the community in general of the upcoming publication. Thank you again for your time and your constructive inputs. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN

1 0

draft-gould-idn-table-02 Posted
by Gould, James April 2, 2015

April 2, 2015

The third draft of draft-gould-idn-table ( draft-gould-idn-table-02 ) was posted to the IETF to address the feedback received from the Registration Operations Workshop (ROW), held on March 22, prior to IETF-92. The following is the draft information: URL: http://www.ietf.org/internet-drafts/draft-gould-idn-table-02.txt Status: https://datatracker.ietf.org/doc/draft-gould-idn-table/ Htmlized: http://tools.ietf.org/html/draft-gould-idn-table-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-gould-idn-table-02 The following is a description of the changes from draft-gould-idn-table-01 to draft-gould-idn-table-02: 1. Removed support for returning the idnTable:codePoint and idnTable:codeRange elements in the table info response based on the feedback at the Registration Operations Workshop (ROW), held on March 22, 2015, prior to IETF-92. 2. Fixed info command samples that referenced the <check> element instead of the <info> element. Please review and provide your feedback. Thanks, — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgould(a)Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> “This message (including any attachments) is intended only for the use of the individual or entity to which it is addressed, and may contain information that is non-public, proprietary, privileged, confidential and exempt from disclosure under applicable law or may be constituted as attorney work product. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this message in error, notify sender immediately and delete this message immediately.”

1 0