Re: [eppext] [provreg] Publishing of the Change Poll EPP Extension IETF Draft

["Gould, James" <[e-mail]>]

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.


—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

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

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

On Jan 30, 2015, at 4:08 AM, Ulrich Wisser <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>:
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


<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>

James Gould
Distinguished Engineer
[e-mail]<http://[e-mail]/>

703-948-3271<tel:[phone]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/provreg


_______________________________________________
EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext