[gtld-tech] [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft

Fri Mar 6 00:07:36 UTC 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 at 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 at 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 at wisser.se <mailto:ulrich at 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 at verisign.com <mailto:JGould at 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 at 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 at ietf.org <mailto:provreg at ietf.org>
>> https://www.ietf.org/mailman/listinfo/provreg <https://www.ietf.org/mailman/listinfo/provreg>
>> 
>> 
>> _______________________________________________
>> 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 <https://www.ietf.org/mailman/listinfo/eppext>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20150305/12b63e23/attachment-0001.html>