Re: [eppext] New Version Notification for draft-brown-epp-fees-06.txt

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

Gavin,

Any thoughts to this thread?


—


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 Dec 8, 2015, at 6:23 PM, Pat Moroney <[e-mail]<mailto:[e-mail]>> wrote:

Hey James,

That complex version meets all of my criteria and I would not be opposed to its inclusion in the draft.

Thanks again,
-Pat

On Tue, Dec 8, 2015 at 3:57 PM Gould, James <[e-mail]<mailto:[e-mail]>> wrote:
Pat,

How about if the check command extension and the check command response extension were true extensions of the check command and followed the semantics of a check, meaning a successful response is expected and each object (domain) returns an availability attribute.  In the case of the fee extension the “avail” attribute would indicate whether the fee information is available for the object (domain) and if not a reason is provided.  I provide two different examples of a check command and response extension.  The first example is the simpler form, where in the use case that you describe you would need to invoke the domain check 4 times to get the information that you want during sunrise, but the check command a response would meet the “simple” criteria.  I’m assuming that you prefer the more complex option, since it would require a single check command and response to get the information that you need.

Simple check command and response extension - Uses a single currency, command, and period for all objects (domains) in the check command:

C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:   <command>
C:     <check>
C:       <domain:check
C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:         <domain:name>domain.example</domain:name>
C:         <domain:name>reserved.example</domain:name>
C:       </domain:check>
C:     </check>
C:     <extension>
C:       <fee:check
C:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.9">
C:         <fee:currency>USD</fee:currency>
C:         <fee:command phase="sunrise">create</fee:command>
C:         <fee:period unit="y">1</fee:period>
C:       </fee:check>
C:     </extension>
C:     <clTRID>ABC-12345</clTRID>
C:   </command>
C: </epp>


S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:   <response>
S:     <result code="1000">
S:       <msg>Command completed successfully</msg>
S:     </result>
S:     <resData>
S:       <domain:chkData
S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:         <domain:cd>
S:           <domain:name avail="1">domain.example</domain:name>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail="0">reserved.example</domain:name>
S:           <domain:reason>Reserved domain</domain:reason>
S:         </domain:cd>
S:       </domain:chkData>
S:     </resData>
S:     <extension>
S:       <fee:chkData
S:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.9">
S:         <fee:currency>USD</fee:currency>
S:         <fee:command phase="sunrise">create</fee:command>
S:         <fee:period unit="y">1</fee:period>
S:         <fee:cd avail="1">
S:           <fee:objID>domain.example</fee:objID>
S:           <fee:fee description="Application Fee"
S:             refundable="0">5.00</fee:fee>
S:           <fee:fee description="Registration Fee"
S:             refundable="1"
S:             grace-period="P5D">5.00</fee:fee>
S:         </fee:cd>
S:         <fee:cd avail="0">
S:           <fee:objID>reserved.example</fee:objID>
S:           <fee:reason>Reserved domain</fee:currency>
S:         </fee:cd>
S:       </fee:chkData>
S:     </extension>
S:     <trID>
S:       <clTRID>ABC-12345</clTRID>
S:       <svTRID>54322-XYZ</svTRID>
S:     </trID>
S:   </response>
S: </epp>


More complex check command and response extension that enables getting the fee information for a list of commands and period settings for the objects (domains) in the check command.  The default period for the command could be set to 1 year, but it can be specified using the <fee:period> child-element of the <fee:command> element.  I believe server policy would need to define the maximum number of commands supported, similar to defining the maximum number of domains in a domain check command.  I included your use case for a domain name in sunrise:

C: <?xml version="1.0" encoding="utf-8" standalone="no"?>
C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C:   <command>
C:     <check>
C:       <domain:check
C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C:         <domain:name>domain.example</domain:name>
C:         <domain:name>reserved.example</domain:name>
C:       </domain:check>
C:     </check>
C:     <extension>
C:       <fee:check
C:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.9">
C:         <fee:currency>USD</fee:currency>
C:         <fee:command name="create"/>
C:         <fee:command phase="open" name="renew">
C:           <fee:period unit="y">1</fee:period>
C:         </fee:command>
C:         <fee:command phase="open" name="create"/>
C:         <fee:command phase="claims" subphase="landrush" name="create"/>
C:         </fee:command>
C:       </fee:check>
C:     </extension>
C:     <clTRID>ABC-12345</clTRID>
C:   </command>
C: </epp>


S: <?xml version="1.0" encoding="utf-8" standalone="no"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S:   <response>
S:     <result code="1000">
S:       <msg>Command completed successfully</msg>
S:     </result>
S:     <resData>
S:       <domain:chkData
S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:         <domain:cd>
S:           <domain:name avail="1">domain.example</domain:name>
S:         </domain:cd>
S:         <domain:cd>
S:           <domain:name avail="0">reserved.example</domain:name>
S:           <domain:reason>Reserved domain</domain:reason>
S:         </domain:cd>
S:       </domain:chkData>
S:     </resData>
S:     <extension>
S:       <fee:chkData
S:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.9">
S:         <fee:currency>USD</fee:currency>
S:         <fee:cd avail="1">
S:           <fee:objID>domain.example</fee:objID>
S:           <fee:command phase="sunrise" name="create">
S:             <fee:period unit="y">1</fee:period>
S:             <fee:fee description="Application Fee"
S:               refundable="0">5.00</fee:fee>
S:             <fee:fee description="Registration Fee"
S:               refundable="1"
S:               grace-period="P5D">5.00</fee:fee>
S:           </fee:command>
S:           <fee:command phase="open" name="renew">
S:             <fee:period unit="y">1</fee:period>
S:             <fee:fee description="Renewal Fee"
S:               refundable="1"
S:               grace-period="P5D">5.00</fee:fee>
S:           </fee:command>
S:           <fee:command phase="open" name="create">
S:             <fee:period unit="y">1</fee:period>
S:             <fee:fee description="Registration Fee"
S:               refundable="1"
S:               grace-period="P5D">5.00</fee:fee>
S:           </fee:command>
S:           <fee:command phase="claims" subphase="landrush" name="create">
S:             <fee:period unit="y">1</fee:period>
S:             <fee:fee description="Registration Fee"
S:               refundable="1"
S:               grace-period="P5D">10.00</fee:fee>
S:           </fee:command>
S:         </fee:cd>
S:         <fee:cd avail="0">
S:           <fee:objID>reserved.example</fee:objID>
S:           <fee:reason>Reserved domain</fee:currency>
S:         </fee:cd>
S:       </fee:chkData>
S:     </extension>
S:     <trID>
S:       <clTRID>ABC-12345</clTRID>
S:       <svTRID>54322-XYZ</svTRID>
S:     </trID>
S:   </response>
S: </epp>




—

JG


[cid:[e-mail]]

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

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

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

On Dec 7, 2015, at 4:53 PM, Pat Moroney <[e-mail]<mailto:[e-mail]>> wrote:

James, Marc,

Currently for our check commands sent for searches, this is what we request for fees:
create command for 1 year in the current phase
renew command for 1 year in the GA phase
create command for 1 year in the GA phase if the current phase is sunrise or landrush.
create command for 1 year in the landrush phase if the current phase is sunrise.

We never request a fee for a domain that is not included in the check command.

We do this because we calculate prices for each of these in our search results. Removing the ability to get this data in a check response will require us to perform multiple commands for searches, which will always be slower then performing a single command that gets the same information.

The check command is the only command that operates on non-existent objects. Combining that with the fact that the check command can return the availability of multiple domains in a single command makes it better suited to return data that is necessary for search results.
Modifying the info command to respond without an error when an object does not exist upsets the idealist in me more then returning more information in the check command. Also the idea of sending additional multiple millions of info commands per day upsets the pragmatic in me.

Performing a fee check on a domain that does not exist happens a couple of orders of magnitude more times then performing a fee check on a domain that exists. That is why removing the extension from the info command wasn't a big deal.
In our case, performing an availability check without performing these fee checks never happens, so removing the extension from the check command would be a big deal.

Thanks,
-Pat

On Mon, Dec 7, 2015 at 2:13 AM Marc Groeneweg <[e-mail]<mailto:[e-mail]>> wrote:
Pat, James, etal.,

I have to agree with James on this one. Shouldn’t we create a simple check for checking availability of a domain name (as supposed) extended with the current fee (given the period the registry/domain phase is in). And extend the info command with more complex fee information. The perceived response time for a check command is very, very small ‘cause its such a small, and powerful command.

Regards,
Marc

From: EppExt [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Gould, James
Sent: vrijdag 4 december 2015 23:55
To: Pat Moroney
Cc: Roger D Carney; [e-mail]<mailto:[e-mail]>

Subject: Re: [eppext] New Version Notification for draft-brown-epp-fees-06.txt

Pat,

You don’t have an issue with applying a common list of commands and periods across the list of objects in the check command?  Was your plan with draft-brown-epp-fees-06 to include multiple <fee:object> elements with the same <fee:objID> value, but with different <fee:command> and <fee:period> values to obtain a fee table or a set of fees for a domain?  My main concern is overloading the use of the check command for something that looks and feels like a query (info) interface.  It just feels odd to leverage the extended check command to get fee information for existing domain names.  My idealist side is really starting to get concerned with the mixing of the availability check with a fee query service.  It would be best to keep the check simple and provide for a limited set of fee information (one command and period along with the domain availability) as a true extension of the availability check to quickly provide the availability and create fee for each available object or provide a fee table for each available object (billable commands and fees by period ranges).  A more powerful query interface could be provided to support more elaborate searches, which is best with the info command and response that was removed in draft-brown-epp-fees-05.  I realize that it is preferred for everything to be provided in a single command and response, but the speed and simplicity of the check is really being put at risk.

—

JG

[X]

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

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

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

On Dec 4, 2015, at 3:20 PM, Pat Moroney <[e-mail]<mailto:[e-mail]>> wrote:

James,

The pragmatist version is of course favorable to me, but the ability to ask for fees relating to multiple commands and/or phases is incredibly useful. Without that ability we would still have to send multiple commands since we also request the fees for renewals as well as registrations when we perform a check. This allows us to provide pricing for purchasing and give our customers an idea of the renewal pricing that they will see next year. Multiple phases is also useful that way we can calculate the price for pre-registrations and pre-landrush while in the sunrise phase with only one command.

So removing the <fee:objID> objects and having a <fee:period> and one or more <fee:command> and optionally many <fee:period> elements that apply to the list of objects referenced in the check command. The response format can stay the same. Would that be your pragmatic suggestion?

Thanks,
-Pat

On Fri, Dec 4, 2015 at 12:11 PM Gould, James <[e-mail]<mailto:[e-mail]>> wrote:
Pat & Roger,

Let me clarify from two different perspectives:

Idealist:
The fee information really doesn’t follow the semantics of a check, but follows the semantics of an info.  The check command is setup as a container of boolean checks of the existence or availability of something (domain, claim, contact identifier, etc.).  The info command provides the query information for general information.  The fee extension is not asking for the existence or availability of something, but is asking for fee information given query inputs.  The query inputs may be invalid, so one of my questions is what should the server return for each of the invalid inputs (objID, objURI, objID, element, currency, command, and period)?  The check command should be simple and fast, where extending it with additional query or separate check information runs the risk of making it complex and slow.

Pragmatist:
If a fee is needed for every domain check, then we need a mechanism to support fee information as an extension to check.  To keep it a true extension, the only elements needed in the <fee:check> element should be <fee:currency>, <fee:command>, and <fee:period> that apply across all of the check identifiers (<domain:name>) included under the check command (<domain:check>).  This would result in a check response including a <fee:chkData> element that matches what is currently defined in draft-brown-epp-fees-06, except the <fee:objID> elements would always correspond to a response identifier (<domain:name>).  If there is invalid input provided with <fee:currency>, <fee:command>, or <fee:period>, the check command should fail with a specified EPP error code (my guess is 2306, since invalid input would be based on server policy).

I’m assuming that the pragmatist is favorable over the idealist, but the idealist in me has a real concern of overloading the check command / response as a pattern to combine commands / responses.

—

JG

[X]

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

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

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

On Dec 4, 2015, at 11:29 AM, Pat Moroney <[e-mail]<mailto:[e-mail]>> wrote:

Hi all,

I have to agree with Roger. The vast majority of check commands that we send are triggered by a customer searching on our website. To create the search results we need both the availability and the fee information in order to calculate the pricing. We can currently get that with one check command, but if it is split up our command volume will almost double.

Thanks,
-Pat

On Fri, Dec 4, 2015 at 9:20 AM Roger D Carney <[e-mail]<mailto:[e-mail]>> wrote:
Good Morning,

Interesting idea Jim. Though not completely disagreeing with your premise that the check and fee have different purposes, let me play devil’s advocate here with some knowledge on the separate claims check in mind as well. Different individual purposes maybe but when looking at the varied data flow scenarios (how is this data used and presented to the end customer), I believe most clients would see the purposes aligned well.

I have heard from many people with the same question about claims: “Why do we have to make two calls to see if a domain has a claim associated to it, can’t they just tell us in the check?”

I am guessing the same question will come up if it is a separate call for fee information as well. People may make the argument that the additional claims check is only needed for a specific period of time (except for those doing indefinite claims). I think everyone would agree this same argument does not apply for fees and as we see more and more varied wholesale models I think an integrated call is more natural and becomes more necessary.

Again, as these concepts align well from a flow perspective and as the probability of expanding wholesaling models increases, I believe most clients would prefer (demand) one call over multiple calls.


Thanks
Roger


From: EppExt [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Gould, James
Sent: Friday, December 04, 2015 7:37 AM
To: Gavin Brown
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [eppext] New Version Notification for draft-brown-epp-fees-06.txt

Gavin,

In reviewing draft-brown-epp-fees-06, I have the following feedback:


  1.  The fee check extension is really not a good fit for extension of the available check.  They have different purposes and there is really no relationship between the two, where the availability check can include a completely different set of domain names from getting the fee extension.  My recommendation is to separate the two and define the fee check as a new verb similar to the claims check in draft-ietf-eppext-launchphase.  Another option is truly extend the object identifiers (e.g. domain:names) in the check command with a set of fee attributes to get the fee information for.  Have the extension only specify the command and the optional currency and fee that applies to all of the names in the availability check command.  The response would include the same list of object identifiers in the extension, but it would be a one-to-one relationship.  In this way there is no need for the “objURI” attribute, the <fee:objID> element, and <fee:objID> “element” attribute in the check command, since the object and identifying element is already defined by the availability check object that is being extended.
  2.  What should be returned when the client passes invalid data in the check command for the the “objURI” attribute (e.g. “urn:made:up:uri”), the <fee:objID> element (e.g. invalid domain name), the “element” attribute of <fee:objID> (e.g. “madeup”), the <fee:currency> element (e.g. “MUP”), and the <fee:period> element (e.g. “99" when max is “10”)?  An invalid <fee:command> is covered by not returning the fee information, but it’s unclear whether the server should return an error or not return the fee information for other invalid data.  To follow the semantics of a check command and response, my recommendation is to add an “avail” attribute to either <fee:cd> or <fee:objID> to explicitly indicate that the fee information is available along with an optional <fee:reason> to indicate the reason that the fee information is not available.  The reason the fee information is not available for a particular object could be due to the passing of invalid input in the check command <fee:object> element.  If you went with a single set of fee elements in the check command that is applied to all of the object identifiers in the availability check, then an invalid fee element could result in a failure of the check command itself instead of being an error (e.g. not available) on a per domain basis.
  3.  Since the check response supports returning a “0.00” value to indicate no fee, doesn’t make sense to do the same with all transform command responses?


—

JG



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

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

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

On Nov 4, 2015, at 5:58 PM, Gavin Brown <[e-mail]<mailto:[e-mail]>> wrote:

Changes from 05 to 06:

  1.  The specification is now object-agnostic, but works with RFC5731
      [RFC5731] domains by default.

  2.  Renamed the <fee:domain> element to <fee:object>.  Added the
      "objURI" attribute.

  3.  Removed the default value for the "refundable" attribute of
      <fee:fee> elements, and added text about how clients should
      handle such cases.  Added similar text to the documentation of
      the "grace-period" attribute.

  4.  Removed references to the defunct <info> command syntax.

  5.  "MUST" requirements regarding documentation have been changed to
      "must".

  6.  Created separate "Correlation between Refundability and Grace
      Periods" section describing how the "refundable" and "grace-
      period" attributes work together.

Feedback welcome as always!

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-06.txt
Date: Wed, 04 Nov 2015 14:52:30 -0800
From: [e-mail]<mailto:[e-mail]>
To: Gavin Brown <[e-mail]<mailto:[e-mail]>>, Jothan Frakes
<[e-mail]<mailto:[e-mail]>>


A new version of I-D, draft-brown-epp-fees-06.txt
has been successfully submitted by Gavin Brown and posted to the
IETF repository.

Name: draft-brown-epp-fees
Revision: 06
Title: Registry Fee Extension for the Extensible Provisioning Protocol
(EPP)
Document date: 2015-11-04
Group: Individual Submission
Pages: 36
URL:
https://www.ietf.org/internet-drafts/draft-brown-epp-fees-06.txt
Status:         https://datatracker.ietf.org/doc/draft-brown-epp-fees/
Htmlized:       https://tools.ietf.org/html/draft-brown-epp-fees-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-06

Abstract:
  This document describes an Extensible Provisioning Protocol (EPP)
  extension mapping for registry fees.





Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

The IETF Secretariat


--
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



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

_______________________________________________
EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext
--
-Pat Moroney
Sr. Software Engineer
Name.com<http://name.com/>
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025
<image001.png><image001.png>_______________________________________________

EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext
--
-Pat Moroney
Sr. Software Engineer
Name.com<http://name.com/>
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025
<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png><BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
_______________________________________________
EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext
--
-Pat Moroney
Sr. Software Engineer
Name.com<http://name.com/>
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025
<image001.png><image001.png>_______________________________________________
EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext

--
-Pat Moroney
Sr. Software Engineer
Name.com<http://Name.com>
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025
<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png><BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>