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

[Pat Moroney <[e-mail]>]

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]> 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
>
>
>
>
>
> *James Gould *Distinguished Engineer
> [e-mail]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com
>
> On Dec 7, 2015, at 4:53 PM, Pat Moroney <[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]>
> 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]] *On Behalf Of *Gould,
>> James
>> *Sent:* vrijdag 4 december 2015 23:55
>> *To:* Pat Moroney
>> *Cc:* Roger D Carney; [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
>>
>>
>>
>>
>>
>> *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]> 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]> 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
>>
>>
>>
>>
>>
>> *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]> 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]>
>> 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]] *On Behalf Of *Gould,
>> James
>> *Sent:* Friday, December 04, 2015 7:37 AM
>> *To:* Gavin Brown
>> *Cc:* [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]>
>> 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]
>> To: Gavin Brown <[e-mail]>, Jothan Frakes
>> <[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.
>>
>> 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]
>> https://www.ietf.org/mailman/listinfo/eppext
>>
>>
>>
>> _______________________________________________
>> EppExt mailing list
>> [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]
>> 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]
>> https://www.ietf.org/mailman/listinfo/eppext
>>
> --
> -Pat Moroney
> Sr. Software Engineer
> Name.com
> http://www.youtube.com/watch?v=V1GKGXXF12c
> 720-663-0025
> <image001.png><image001.png>
> _______________________________________________
> EppExt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eppext
>
>
> --
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025