Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

From: [email-masked]
Date: Tue, 25 Apr 2017 14:31:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions of the IETF.

        Title           : Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
        Authors         : Roger Carney
                          Gavin Brown
                          Jothan Frakes
	Filename        : draft-ietf-regext-epp-fees-03.txt
	Pages           : 33
	Date            : 2017-04-25

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-epp-fees-03
https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Roger D Carney <[email-masked]>
Date: Tue, 25 Apr 2017 21:40:10 +0000

Good Afternoon,

Here is the update draft document. This should include all of the agreed upon changes from the Chicago meeting (biggest change was the simplification of the <check> call).

One topic that was discussed in Chicago (and not resolved) was on the concept of "premium names" and what is returned from the server if no fee extension was passed into the <check>. Many thought to be more "backwards compatible"/"user friendly", especially for those registrars that do not and may not be participating in the allocation of "premium names", that the server should respond as unavailable. Others expressed that if it is available then the server should respond available. Please share your thoughts on the list on this topic and if this draft should even try to account for this concept.

Please let me know if you have any questions.

Thanks

Roger

-----Original Message-----
From: regext [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, April 25, 2017 4:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

        Authors         : Roger Carney

                          Gavin Brown

                          Jothan Frakes

                Pages           : 33

                Date            : 2017-04-25

Abstract:

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.

_______________________________________________

regext mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/regext

---

From: Thomas Corte <[email-masked]>
Date: Wed, 26 Apr 2017 11:16:22 +0200

Hello Roger,

On 25/04/2017 23:40, Roger D Carney wrote:

> One topic that was discussed in Chicago (and not resolved) was on the
> concept of “premium names” and what is returned from the server if no fee
> extension was passed into the <check>. Many thought to be more “backwards
> compatible”/”user friendly”, especially for those registrars that do not
> and may not be participating in the allocation of “premium names”, that
> the server should respond as unavailable. Others expressed that if it is
> available then the server should respond available. Please share your
> thoughts on the list on this topic and if this draft should even try to
> account for this concept.

I believe that responding "unavailable" is the best option here.

The rationale is: if a <domain:check> without special precautions (such
as an extension) yields "available", then a subsequent <domain:create>
without special precautions should succeed. Conversely, if a
<domain:create> fails because the registrar didn't indicate (via the fee
extension, for example) that he's aware of the higher price of the
domain, then a corresponding <domain:check> should yield "not available"
if that check doesn't somehow indicate the same awareness of the higher
price. The semantics of that check result are: "You can't create the
domain name just like that, more data is needed."

Now I'm aware that the fee extension isn't currently suited for
signalling awareness of a higher price in a <domain:check>, but that's OK
since it provides other means to find out under which circumstances a
<domain:create> for a checked domain will succeed.

As a side note, I should mention that in our own TANGO registry system,
the pricing of premium domains is closely tied to *launch phases* (since
launch phases readily provide a means to classify domains, we decided to
use it rather than creating an additional proprietary classification). A
registrar may create a premium domain by either providing correct fee
information *or* specifying the correct launch phase when creating the
domain.
In this setup, a <domain:check> for a premium domain yields "unavailable"
without specification of that launch phase, but it yields "available" if
the correct launch phases is passed along in the <domain:check> command.
Yet I'm aware that this kind of signalling ("what if I created that
domain specifying these fees in an extension?") isn't within the fee
extension's scope at the moment, and it probably won't need to be.

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: Andreas Huber <[email-masked]>
Date: Wed, 26 Apr 2017 17:12:30 +0200

Hi Roger,

thanks for version 0.17! This one should solve most of our "registrar" issues (Hopefully, some registries plan to implement this version soon).

Some thoughts to open questions:

* Premium Domain Availability without Fee-Ext.

I would also vote to respond with "unavailable".

The status "premium" of a domain could be understood in a similar way to the domain status reserved, blocked or registered. Without using the fee extension, it's not possible to register such names, therefore they're "unavailable" for the registrar just like reserved names.
If we don't want to use the Fee-Ext. for a specific registry (because of contractual reasons or something else), we're not interested in the availability of premium names which we can't/won't register anyway.

Second thought: From a registry's perspective, I understand a name is always "available" if it is not registered, blocked or reserved, independent of any fees. But, ;) since EPP is a personalized communication protocol (client needs to login and register extensions to use), then responses should be
personalized to the client. For a client not using the fee extension, a premium name is technically "unavailable".

* <fee:class> in check responses

The last weeks a question regarding the <fee:class> element came up a couple of times.

<fee:class> is a child of <fee:command> since version 0.13, therefore section 3.7. should be clarified.

Is <fee:class> an attribute of a specific fee or an object? There are some misunderstandings, especially before version 0.13, which describes "class" as a child of <fee:cd>. Several discussions with registries pointed out, that they understand <fee:class> as "attribute" of the object. This results
in conditions where a domain has a premium create but a standard renewal fee to be both tagged with "premium", because an object can only have one value of the same attribute.

As an example (from section 3.7): "The <fee:class> element which appears in <check> responses is used to indicate the classification of an object." should be changed to something like "... the classification of a command fee".

As a registrar, we need to know if a "command fee" (not an object) is premium (e.g. <fee:class>premium</fee:class>) or standard, if one wants to respond standard fees at all. Responding standard fees are in fact unnecessary, btw.

Thanks,
Andreas

Am 25.04.2017 um 23:40 schrieb Roger D Carney:
> One topic that was discussed in Chicago (and not resolved) was on the concept of “premium names” and what is returned from the server if no fee extension was passed into the <check>. Many thought to be more “backwards compatible”/”user friendly”, especially for those registrars that do not and may
> not be participating in the allocation of “premium names”, that the server should respond as unavailable. Others expressed that if it is available then the server should respond available. Please share your thoughts on the list on this topic and if this draft should even try to account for this concept.
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> 
> [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 27 Apr 2017 13:26:44 +0000

I believe the classification <fee:class> should remain at the object-level, since the concept of standard or premium is done at the object-level and not at the command level.  There may be the use case where a premium domain has a higher fee for the create but has the same fee as a standard domain for the renew and transfer, but that is based on the fee schedule defined for one or more premium domain names.  The key is that the fee is more variable for premium domains than for standard domains, so it may be misleading to return “standard” for the renew and transfer commands of a premium domain if the premium fee and standard fee happens to be the same, since there is implied variability with the premium domain.   It’s best to leave the classification as an object-level attribute and not attempt to derive it based on a comparison between the fee schedules.  

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 4/26/17, 11:12 AM, "regext on behalf of Andreas Huber" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Roger,

    

    

    

    

    Thanks,
    Andreas

---

From: Thomas Corte <[email-masked]>
Date: Thu, 27 Apr 2017 18:47:27 +0200

Hello Roger,

On 2017-04-25 23:40, Roger D Carney wrote:

> Good Afternoon,
> 
> Here is the update draft document. This should include all of the agreed
> upon changes from the Chicago meeting (biggest change was the
> simplification of the <check> call).

Thanks for this new version. Here are a couple of
comments/corrections/suggestions:

* Typo (messed up quotes) in the XSD for this "minOccurs" attribute:

  <element name="command" type="fee:commandType"
    minOccurs=""1" "maxOccurs="unbounded" />

* Typos: "elelment", "objectCheckTpye"

* The attribute "name" in commandType should really be mandatory,
  but is currently optional due to the default minOccurs=0 for XML
  attributes. I don't see a use case for a nameless command, and
  the text seems to assume that a name is always present.

* The semantics of the <cd> element's "avail" attribute in conjunction
with the fees and/or reasons of nested <command> elements seem unclear.
Take the following <check> for example:

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <check>
      <domain:check xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.tld</domain:name>
      </domain:check>
    </check>
    <extension>
      <fee:check xmlns:fee="urn:ietf:params:xml:ns:fee-0.17">
        <fee:currency>EUR</fee:currency>
        <fee:command name="create"/>
      </fee:check>
    </extension>
    <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID>
  </command>
</epp>

Since no phase/subphase is specified, the draft calls for returning data
for "all valid server combinations of currently active phase(s) and
active subphase(s)" for the "create" operation.
The period defaults to 1.
A possible response is:

<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <domain:chkData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:cd>
          <domain:name avail="true">example.tld</domain:name>
        </domain:cd>
      </domain:chkData>
    </resData>
    <extension>
      <chkData xmlns="urn:ietf:params:xml:ns:fee-0.17">
        <currency>EUR</currency>
        <cd avail="???">
          <objID>example.tld</objID>
          <command name="create" phase="open">
            <period unit="y">1</period>
            <fee applied="immediate"
              description="domain creation in phase 'open'"
grace-period="PT1M" refundable="true">60.00</fee>
          </command>
          <command name="create" phase="custom" subphase="defensive">
            <period unit="y">1</period>
            <fee applied="immediate"
              description="domain creation in phase
'defensive-registration'"
              grace-period="PT1M" refundable="true">30.00</fee>
          </command>
          <command name="create" phase="custom" subphase="promotion">
            <reason>domain name not available as a promotion name</reason>
          </command>
        </cd>
      </chkData>
    </extension>
    <trID>
      <clTRID>e1f8b4cd61f84469436bf16585f976b3</clTRID>
      <svTRID>1493309414927-16</svTRID>
    </trID>
  </response>
</epp>

In this example, there are three active phases:

* example.tld is available in phase "open" for 60.00 EUR per year
* example.tld is available in phase "defensive" for 30.00 EUR per year
* example.tld is not available in phase "promotion" since the name is
not part of that promotion phase

For this example, should the <cd> element carry avail="false" or
avail="true"? Turns out that both options are not OK since:

  "If the "avail" attribute of the <fee:cd> element is false, then the
   <fee:command> element MUST NOT contain any <fee:fee> or <fee:credit>
   child elements.  If the "avail" attribute is true, then the
   <fee:command> element MUST NOT contain a <fee:reason> element."

However, mixed cases like the above (with some phases permitting a name
and other phases not allowing it) are not unlikely in real life. Now,
according to the draft's wording

  "the server MAY eliminate some or all of the <fee:command> element(s)"

the server's only option here is to either eliminate the commands with
the <reason> element (and set avail="true") or eliminate the commands
with fee information (and set avail="false"), but it doesn't seem
prudent to withhold useful information that has probably already been
computed. This wording also leaves too much room for interpretation,
leading to uncertainty about what to expect on the client side.

I'd therefore suggest to move the "avail" attribute back to the
<command> level and allowing mixed results like the above. The avail
attribute on the <cd> may be retained, but should probably only be false
if no fees whatsoever could be assessed for any possible combination of
phases/subphase for a name.

Best regards,

Thomas