Subject: Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

From: "Gould, James" <[email-masked]>
Date: Tue, 28 Mar 2017 13:09:09 +0000

I agree that the entire check command should not fail due to passing of an incorrect domain name, currency, command, period, or phase, but instead the extension should return the fee as unable for the specific domain name with a reason.  This is similar to how the availability check works, where if an invalid domain name is passed in the list of domain names, the availability check returns successfully but with the avail=”false” for the invalid domain name.  The check command should return a success with the appropriate availability (object or fee) indicated in the response for each object.    

I had an action item from the working session yesterday to describe the proposal for the extension to the check response that matches Option C discussed at IETF-95.  The “more complex option” outlined in the list message https://www.ietf.org/mail-archive/web/eppext/current/msg00883.html provides an example of the extension to the check command and response for what was called Option C.  Option C included a single currency and a list of commands that is applied to all the domains in the availability check.  In the case of an invalid currency, the <fee:cd avail=”false”> with a <fee:reason>Invalid currency</fee:reason> could be returned for each of the domain names in the check instead of returning a failure to the availability check.  In this case Option C truly is an extension of the check with a single set of requested fee information.  

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
[email-masked]

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

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

On 3/28/17, 5:55 AM, "regext on behalf of Thomas Corte" <[email-masked] on behalf of [email-masked]> wrote:

    However, for wrong currencies detected within some <fee:object> elements
    of a <fee:check> extension, I'm not sure whether letting the entire
    check command fail with a 2306 error is the best approach.
    
    Instead, the server could still return useful results for other
    <fee:object> elements in the command (which may have contained a correct
    currency), or even return additional information in the <reason>
    elements returned within the <fee:command avail="false"> elements
    returned for all nested <fee:command> affected by the wrong currency.
    I think the draft should be clarified regarding when to create an EPP
    error result as opposed to <fee:command avail="false"> results in the
    response to a <domain:check> command with fee extension.

---

From: Jody Kolker <[email-masked]>
Date: Tue, 28 Mar 2017 15:28:48 +0000

Thanks James.

In the example listed below, reserved.domain is unavailable and apparently does not have any pricing information for the domain.  However, if fee information were available for the reserved domain, I would expect that fee information to be returned in this command even though the domain is not available for registration. 

Thanks,
Jody Kolker
319-294-3933 (office)
319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall ([email-masked]) with any feedback.

This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments.

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Tuesday, March 28, 2017 8:09 AM
To: Thomas Corte <[email-masked]>; Bernhard Reutner-Fischer <[email-masked]>; regext <[email-masked]>
Subject: Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

    

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

---

From: Thomas Corte <[email-masked]>
Date: Tue, 28 Mar 2017 17:34:27 +0200

Hello,

On 2017-03-28 15:09, Gould, James wrote:

> I had an action item from the working session yesterday to describe
> the proposal for the extension to the check response that matches
> Option C discussed at IETF-95.  The “more complex option” outlined in
> the list message
> https://www.ietf.org/mail-archive/web/eppext/current/msg00883.html
> provides an example of the extension to the check command and
> response for what was called Option C.  Option C included a single
> currency and a list of commands that is applied to all the domains in
> the availability check.  In the case of an invalid currency, the
> <fee:cd avail=”false”> with a <fee:reason>Invalid
> currency</fee:reason> could be returned for each of the domain names
> in the check instead of returning a failure to the availability
> check.  In this case Option C truly is an extension of the check with
> a single set of requested fee information.

I like this approach better than the current fee-0.15 solution, which allows/requires restricting the fee checks to a subset of the checked object, and supports a different currency and set of commands for every object. While this may come in handy sometimes, the most common usage would probably select all checked objects and a single currency and set of commands. Most servers will probably only support a single currency anyway.

What I don't like is that the "avail" attribute has been moved to the framing <fee:cd> element, while it's an attribute of <fee:command> in the current fee-0.15 draft. The latter has the big advantage of the server being able to report e.g. the availability of a fee (and the domain in general) for different launch phases.

For example, with fee-0.15, this response could indicate that the domain premium-500.example is available in the launch phase "custom/open-500", but not in "open".

S: <?xml version="1.0"?>
S: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema-instance">
S:   <response>
S:     <result code="1000">
S:       <msg>Command completed successfully</msg>
S:     </result>
S:     <resData>
S:       <domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S:         <domain:cd>
S:           <domain:name avail="false">premium-500.example</domain:name>
S:           <domain:reason>not registrable in this phase</domain:reason>
S:         </domain:cd>
S:       </domain:chkData>
S:     </resData>
S:     <extension>
S:       <chkData xmlns="urn:ietf:params:xml:ns:fee-0.15">
S:         <cd>
S:           <objID>premium-500.example</objID>
S:           <currency>EUR</currency>
S:           <command avail="false" name="create" phase="open">
S: 	       <reason>the requested launch phase is not suitable for the domain</reason>
S: 	     </command>
S:           <command name="create" phase="custom" subphase="open-500">
S:             <period unit="y">1</period>
S:             <fee applied="immediate" description="domain creation in phase 'open-500'" grace-period="PT1M" refundable="true">500.00</fee>
S:           </command>
S:         </cd>
S:       </chkData>
S:     </extension>
S:     <trID>
S:       <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID>
S:       <svTRID>1490271424463-9</svTRID>
S:     </trID>
S:   </response>
S: </epp>

I'd like to retain this feature. I'm aware that this somewhat "abuses" the fee extension to determine which launch phase is suitable for a domain (and there is an overlap with the extension's "domain class" concept), but it's not too far from the intended use in my opinion.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: "Gould, James" <[email-masked]>
Date: Tue, 28 Mar 2017 18:09:34 +0000

Thomas,

Putting the avail attribute at the level of fee:cd addresses use cases where the domain name is invalid, reserved (without pricing), and the currency is invalid.  In these cases, you would not want to return all the commands with an avail=false to indicate that the fee information is not available for the domain.  If the server needs to get down to the detail of providing availability at the command level, then the avail attribute could be added there as well, but there is an extra level of complexity to handle it at the command level.  If the command is invalid, the period is invalid, having the avail flag only at the fee:cd level would fast-fail to not provide any of the fee information.  Although this may not be as functional, it allows the server to fast fail the fee check which is important to keep the availability check more lightweight.   I would prefer to fast fail if possible.  

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 3/28/17, 10:34 AM, "Thomas Corte" <[email-masked]> wrote:

    Hello,

    

    
    S: <?xml version="1.0"?>

    Best regards,
    
    Thomas

---

From: Alexander Mayrhofer <[email-masked]>
Date: Tue, 28 Mar 2017 22:37:03 +0000

Thomas,

> What I don't like is that the "avail" attribute has been moved to the framing
> <fee:cd> element, while it's an attribute of <fee:command> in the current
> fee-0.15 draft. The latter has the big advantage of the server being able to
> report e.g. the availability of a fee (and the domain in general) for different
> launch phases.

i think you have mentioned an important argument *against* your own proposal. You write  "availability of a fee (and the domain in general)", which means that your proposal tries to mix in two different semantics into the same element - which, in turn, seems ambigious and probably even dangerous. The "avail" attribute can *either* indicate whether fee information is available, *or* whether a certain commmand on a certain domain in a certain phase (at the current point in time?) is "available". 

I think it's easy to see that the second "type" of availability would entail all kinds of problems. Therefore i'd rather not go down that path. It would pack too much logic into the command (eg. "is a transfer on that domain available for that client during the given phase at the current time?" - i don't want to be in the position to decide about such cases..)

James, what is your most recent proposal for the descriptive text of the "avail" attribute at the "fee:cd" level?

best,
Alex

---

From: Thomas Corte <[email-masked]>
Date: Wed, 29 Mar 2017 10:14:23 +0200

Hello Alexander,

On 29/03/2017 00:37, Alexander Mayrhofer wrote:

> i think you have mentioned an important argument *against* your own
> proposal. You write  "availability of a fee (and the domain in
> general)", which means that your proposal tries to mix in two
> different semantics into the same element - which, in turn, seems
> ambigious and probably even dangerous. The "avail" attribute can
> *either* indicate whether fee information is available, *or* whether a
> certain commmand on a certain domain in a certain phase (at the
> current point in time?) is "available".
> 
> I think it's easy to see that the second "type" of availability would
> entail all kinds of problems. Therefore i'd rather not go down that
> path. It would pack too much logic into the command (eg. "is a
> transfer on that domain available for that client during the given
> phase at the current time?" - i don't want to be in the position to
> decide about such cases..)

Good point, but it seems that we'll need a clearer definition of what
"fee information is available" is really supposed to mean. To me, it was
always implicitly clear that it essentially means "the domain can be
created/renewed/transferred/... with the given parameters, and it costs
this much", whereas avail="false" means "the operation isn't possible
because some parameter is wrong, hence no costs can be determined".

The current wording matches that interpretation in my opinion: "If the
value of this attribute evaluates to false, this indicates that the
server cannot calculate the relevant fees, because the object, command,
currency, period or class is invalid according to server policy."

So this does essentially boil down to an extended availability check,
which happens to also provide cost information. Not sure what the
alternative would be; if a combination of domain name, command, launch
phase, period and currency is valid, the server should be be able to tell
the costs. Simply replying "don't know" for a viable operation would not
provide useful information to the registrar.

Best regards,

Thomas

---

From: Thomas Corte <[email-masked]>
Date: Wed, 29 Mar 2017 10:51:23 +0200

Hello James,

On 28/03/2017 20:09, Gould, James wrote:

> Thomas,
> 
> Putting the avail attribute at the level of fee:cd addresses use cases
> where the domain name is invalid, reserved (without pricing), and the
> currency is invalid.  In these cases, you would not want to return all
> the commands with an avail=false to indicate that the fee information
> is not available for the domain.  If the server needs to get down to
> the detail of providing availability at the command level, then the
> avail attribute could be added there as well, but there is an extra
> level of complexity to handle it at the command level.  If the command
> is invalid, the period is invalid, having the avail flag only at the
> fee:cd level would fast-fail to not provide any of the fee
> information.  Although this may not be as functional, it allows the
> server to fast fail the fee check which is important to keep the
> availability check more lightweight.   I would prefer to fast fail if
> possible.

I agree that a fast fail is preferable if the domain name or currency
prevent the name from being available in any case.

The use case I'm thinking of refers to the provision in fee-0.15 that
allows the server to return availability information for all active
launch phases. In fee-0.15, this is possible by returning <fee:command>
elements with avail="true" for launch phases permitting the name, and
elements with avail="false" for launch phases not permitting it. But I
guess in the new approach (with avail in the framing element) this is
still possible by simply omitting the non-available results and only
including <fee:command> elements for the phases that support the
operation. The registrar doesn't need to learn about existing launch
phases that do not allow the registration of the name.

Best regards,

Thomas