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 18:10:32 +0000

Jody, 

Yes, the fee information should be returned for a reserved domain if pricing information does exist.  
  
—
 
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, 10:28 AM, "Jody Kolker" <[email-masked]> wrote:

    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
    
    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.

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

---

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

Hello James,

> Yes, the fee information should be returned for a reserved domain if pricing information does exist.  

Not sure what this would mean. If a domain is reserved, that usually
means that it's not available for registration under *any* circumstances.
Therefore there should never be a pricing information available for such
a domain.

The alternative would be to return the *fictitious* price for the domain
should it ever *become* available in the future, but that's impossible to
assess and would not provide useful information to the registrar.

In our current implementation, the fee information returned by a
<fee:check> is generally identical to the fee information that would be
returned if the registrar actually tried to execute the given transform
command on the given domain name, in the given launch phase, with the
given period. That includes a check for the name's actual availability.
It's essentially a simulation of the given operation on the name.

While I agree that the availability check is already a task that the
standard <check> command accomplishes, the fee extension provides the
opportunity to extend its basic functionality. If e.g. a registry
releases premium names by allowing their registration in specific launch
phases, each with specific prices, the fee extension provides (at least
in version fee-0.15) a way to tell the registrar in which of these phases
a name is available, and at which price.

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: Jody Kolker <[email-masked]>
Date: Wed, 29 Mar 2017 13:23:35 +0000

Hi Thomas,

Not sure what this would mean. If a domain is reserved, that usually means that it's not available for registration under *any* circumstances.
Therefore there should never be a pricing information available for such a domain.

With the launch of the new gTLDs, we have numerous examples of domains that are reserved by the registry, but are available for sale given some circumstances.  For this reason, we would like all reserved domains to be assigned a fee.

Thanks,
Jody Kolker
319-294-3933 (office)

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of Thomas Corte
Sent: Wednesday, March 29, 2017 3:42 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [regext] draft-ietf-regext-epp-fees-02.txt: currency error handling, command wildcard

Hello James,

> Yes, the fee information should be returned for a reserved domain if pricing information does exist.  

Not sure what this would mean. If a domain is reserved, that usually means that it's not available for registration under *any* circumstances.
Therefore there should never be a pricing information available for such a domain.

The alternative would be to return the *fictitious* price for the domain should it ever *become* available in the future, but that's impossible to assess and would not provide useful information to the registrar.

In our current implementation, the fee information returned by a <fee:check> is generally identical to the fee information that would be returned if the registrar actually tried to execute the given transform command on the given domain name, in the given launch phase, with the given period. That includes a check for the name's actual availability.
It's essentially a simulation of the given operation on the name.

While I agree that the availability check is already a task that the standard <check> command accomplishes, the fee extension provides the opportunity to extend its basic functionality. If e.g. a registry releases premium names by allowing their registration in specific launch phases, each with specific prices, the fee extension provides (at least in version fee-0.15) a way to tell the registrar in which of these phases a name is available, and at which price.

Best regards,

Thomas

---

From: Thomas Corte <[email-masked]>
Date: Wed, 29 Mar 2017 15:48:32 +0200

Hello Jody,

On 29/03/2017 15:23, Jody Kolker wrote:

> Hi Thomas,
> 
> With the launch of the new gTLDs, we have numerous examples of domains
> that are reserved by the registry, but are available for sale given
> some circumstances.  For this reason, we would like all reserved
> domains to be assigned a fee.

That sounds like a weird interpretation of "reserved" to me. In TANGO,
we're avoiding that term unless a domain is really unavailable to registrars.

If previously reserved names are released in a TLD run by TANGO, we're
setting up special launch phases (with appropriate tariffs attached) in
which the names become available. Registrars can announce they're aware
of the special pricing when creating domains by either using the launch
phase extension to specify the correct phase, or by using the fee
extension to specify the correct fees. A normal domain create will fail.
A check for the domain without specifying the correct launch phase would
result in a "not registrable in this phase" reason and avail="false", but
would not call the domain "reserved" anymore.

Best regards,

Thomas