Subject: Re: [regext] I-D Action: draft-carney-regext-validate-00.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 19 Apr 2016 11:29:59 +0000

> -----Original Message-----
> From: I-D-Announce [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, April 18, 2016 6:17 PM
> To: [email-masked]
> Subject: I-D Action: draft-carney-regext-validate-00.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 
>         Title           : Validate Extension for the Extensible
> Provisioning Protocol (EPP)
>         Authors         : Roger Carney
>                           Joseph Snitker
> 	Filename        : draft-carney-regext-validate-00.txt
> 	Pages           : 11
> 	Date            : 2016-04-18
> 
> Abstract:
>    This document describes an Extensible Provisioning Protocol (EPP)
>    extension mapping for the validation of contact and eligibility
> data.

Roger, thanks for publishing this. Some questions: what exactly is the server-side recipient of a <validate> command supposed to do to validate the information received from a client? Why is validation of a postal address (for example) the responsibility of the server operator and not the client who collects that data in the first place?

Scott

---

From: Roger D Carney <[email-masked]>
Date: Tue, 19 Apr 2016 16:51:45 +0000

Hi Scott,

Thanks for the quick review. The intent here is to get the "approval" of the server that this specific address can be created for this TLD for this contact type. This is not to replace the validation/verification that the registrar is currently conducting, this is to systematically confirm the server side policies for this contact, contact type and TLD combination.

I don't know if it will come as a surprise to many, but registrars are not given all the specific validation/syntax rules for each contact field for each contact type of each TLD, and when these rules/polices change registrars don't always receive adequate notice.

The main issue that we are trying to solve is a domain create failure due to contact issues. Some server policies will let us create a contact but then when we try to associate at domain create time that previously created valid contact is not valid for this contact type and/or TLD combination. This results in a complete customer/registrant headache. A typical scenario: registrant selects a name; provides registrar contact information; registrar creates contacts; registrar collects payment from registrant; registrar tries to create domain with contacts; receives an error associated with contact/contact type/tld; registrar must "correct" the contact (though not inline as the errors are not specific enough) or in the worst case refund the customer/registrant.

I hope that helps shed some light on the issue that we are trying to solve, please let me know if there are any additional questions or comments.

Thanks
Roger

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Hollenbeck, Scott
Sent: Tuesday, April 19, 2016 6:30 AM
To: [email-masked]
Subject: Re: [regext] I-D Action: draft-carney-regext-validate-00.txt

Scott

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 21 Apr 2016 15:15:24 +0000

> From: regext [mailto:[email-masked]] On Behalf Of Roger D
> Carney
> Sent: Tuesday, April 19, 2016 12:52 PM
> To: [email-masked]
> Thanks for the quick review. The intent here is to get the "approval"
> of the server that this specific address can be created for this TLD
> for this contact type. This is not to replace the
> validation/verification that the registrar is currently conducting,
> this is to systematically confirm the server side policies for this
> contact, contact type and TLD combination.

Roger, did you look into extending the contact <check> command? My first glance reaction is that it's perfectly suited for the purpose you described above. From RFC 5733:

"The EPP <check> command is used to determine if an object can be provisioned within a repository.  It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the <create> command"

Scott

---

From: "Gould, James" <[email-masked]>
Date: Thu, 21 Apr 2016 15:47:33 +0000

Roger,

I thought the goal of the validate extension, based on prior discussions, was to pass the same information that you would with a standard transform command, but to override the transform command to implement a no operation validate.  In draft-carney-regext-validate-00 it looks to be targeted only at validating specific contact information.   By tagging an existing transform operation with the extension as a new validate verb (e.g. “Validate Create”, “Validate Update”, “Validate Renew”, “Validate Transfer”, “Validate Update”), the complete transform operation with all of the additional extensions can be validated by the server.  It could be up to server policy what objects and transform operations would support the validate extension.  There could be some additional filtering features included in the validate extension, but in the simple form it could be a tagging extension.  If new verbs are defined, a standard EPP response could be returned with the validate response extension to provide the result of the validation similar to what was done with the claims check command and response in draft-ietf-eppext-launchphase.  In this case, you could send a Contact Create with the validate extension as a Contact Validate Create that could validate the information without creating the contact. Additionally, you could send a Domain Create with the validate extension as a Domain Validate Create that could validate the attributes passed with the domain create including any extensions, that could validate the information without creating the domain.  The ability to apply a tagging extension as a no operation validate could be flexible enough to support any object, any transform command, and any set of extensions (within reason).

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On Apr 21, 2016, at 11:15 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Roger D
Carney
Sent: Tuesday, April 19, 2016 12:52 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [regext] I-D Action: draft-carney-regext-validate-00.txt

Hi Scott,

Scott

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 21 Apr 2016 15:50:24 +0000

I really hate HTML-formatted email…

From: Gould, James
Sent: Thursday, April 21, 2016 11:48 AM
To: Hollenbeck, Scott
Cc: Roger D Carney; [email-masked]
Subject: Re: [regext] I-D Action: draft-carney-regext-validate-00.txt

Roger,

[SAH] Sure, that could work, too, and it’s probably simpler.

Scott

---

From: Roger D Carney <[email-masked]>
Date: Fri, 29 Apr 2016 21:30:25 +0000

Good Afternoon,

Thanks for the questions and input.

Great questions and great ideas (self-inflating as we did work through these scenarios internally as wellJ).

The transform commands:
As Jim mentions this was the first scenario that we worked through. One big issue that we kept coming back to was use, how this gets used/implemented in practice and in reviewing the customer/registrant typical flows we kept coming back that we need to catch the contact/eligibility issues sooner. Looking at specifics you mention: the Create Contact scenario did not seem to work, as we wanted to validate a group of contacts (Registrant, Admin, Tech, Billing) in coordination with a TLD as a whole and the contact object is singular, and making it work made the contact object somewhat unrecognizable; as for the Domain Create scenario we didn’t want to have to create the contacts ahead and then validate them with the Domain Validate Create and then correct the contacts and revalidate, rinse/repeat.

The contact <check> command:
This was the second scenario that we worked through. And our biggest stumbling block, like above, was that the contact <check> only allows one contact and we wanted the ability to validate multiple contacts as a group. And as we worked through the changes needed to support multiple contacts and just passing in the ROID (for reuse) and the other features (kv, TLD, contactType, etc) we really ended up with something that no longer looked like the <check> command, which is what lead us to our current proposal.

Thanks
Roger

From: Hollenbeck, Scott [mailto:[email-masked]]
Sent: Thursday, April 21, 2016 10:50 AM
To: Gould, James <[email-masked]>
Cc: Roger D Carney <[email-masked]>; [email-masked]
Subject: RE: [regext] I-D Action: draft-carney-regext-validate-00.txt

From: Gould, James
Sent: Thursday, April 21, 2016 11:48 AM
To: Hollenbeck, Scott
Cc: Roger D Carney; [email-masked]<mailto:[email-masked]>
Subject: Re: [regext] I-D Action: draft-carney-regext-validate-00.txt

Roger,

Scott