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

From: Gavin Brown <[email-masked]>
Date: Mon, 29 Sep 2014 17:11:46 +0100

Hi all,

I've just published a new version of the EPP fee extension draft.
Feedback is welcome.

Changes in this version:

   1.  Added the "applied" attribute to to <fee:fee> elements.

   2.  Simplified the wording in relation to when a server can return an
       error for extended <info> commands.

   3.  Added the <fee:period> element to transfer query responses.

   4.  Removed wording about how servers behave when receiving incorrect
       fee information from transform commands, and put it into a single
       section at the top of the document.

   5.  Allow servers to omit <fee:fee> elements from <fee:cd> elements
       if the command specified by the client is forbidden.

Many thanks to those who gave feedback on the previous version.

The long-term roadmap has two items suggested by Jim Gould:

* make the extension object-agnostic so it can be used for billable
transactions against any object, not just standard domain names

* use a special <check> form that's similar to the Claims Check form in
draft-ietf-eppext-launchphase, so availability check results are
excluded when doing a fee check (and vice versa).

Regards,

-------- Original Message --------
Subject: New Version Notification for draft-brown-epp-fees-03.txt
Date: Mon, 29 Sep 2014 06:52:20 -0700
From: [email-masked]
To: Gavin Brown <[email-masked]>, Gavin Brown
<[email-masked]>

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

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

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.

---

From: "Gould, James" <[email-masked]>
Date: Tue, 30 Sep 2014 15:19:04 +0000

Gavin,

Thanks for moving this draft along.  I provide rationale for the roadmap items that you attributed to me below.  One other item discussed privately that I would like to bring up publicly is the addition of an enumerated “type” attribute for the <fee:fee> element that even the <fee:credit> element specifies the type of fee or credit without having to rely on an out-of-band mechanism to map the “description” attribute to something meaningful to the client.  The text could state that the <fee:fee> value is always a sum of any unit based fee.  Possible values for the <fee:fee> “type” attribute could include values like:

  *   “fixed” - A fixed fee charged independent of the period.
  *   “unit” - Total unit fee charged based on the period.
  *   “tax” - Tax charged
  *   “custom” - Support for a custom fee, where the “description” or another attribute like “name” could be used to specify the custom fee type.
  *   “total” - Total fee based by applying all of the fees and credits.  This could be the default “type” value.

—

JG

James Gould
Principal Software Engineer
[email-masked]

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

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

On Sep 29, 2014, at 12:11 PM, Gavin Brown <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

Changes in this version:

New billable objects can and have been defined using EPP, where de-coupling the fees extension from the single domain name object, will make it more generic and applicable to existing and future EPP objects.  For example in .NAME, there is the definition of three additional billable EPP objects with Defensive Registration, Email Forwarding, and NameWatch.  The fees extension could be made object agnostic with some text changes and some minor schema changes.  For example, it is pretty straight forward to change the <fee:domain> element to the <fee:entity> element in the extension to the domain check command, where all billable objects / entities would need to support a name attribute along with the other fees attributes.  In the case of .NAME the three objects of Defensive Registration, Email Forwarding, and NameWatch all support a name attribute, so they could be supported with the fees extension.  This way there would be no need to define yet another fees / price extension to support other EPP billable objects or ignore the reference to “domain” in the <fee:domain> element for non-domain objects.

I actually question the applicability of extending the check command at all for the fee extension, since I view the fee information as the responsibility of the info command / response and not the check command.   I believe that the check command should be used to answer a boolean question like "is the domain available?" or "is there a mark associated with the domain name?” or “is the fee correct?".  In this case, the boolean question of whether a domain name is available is being mixed with a non-boolean question listing the fee information based on a list of domain names, each with the command, and optionally the period and currency.  If the fee check was changed into an actual boolean question like checking if the passed fee information is correct ahead of the future execution of a billable transform command (create, renew, transfer, restore), then I would view it as a different verb that would be handled in a similar fashion to the claims check command of draft-ietf-eppext-launchphase.  For example, I would make the fee check command to be an extension of a check command (domain or any object) that adds a single set of fee check properties that are applied to each of the objects to validate by the server and return whether the fee passed is valid in the response and if not optionally return the correct fee information.  In this case the fee check command is used to answer the boolean question of whether the fee of 5.00 USD passed by the client is correct for a create of one year, during sunrise.  The info command and response extension can be used to get the fee information ahead of time if not already known.

   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>example.com<http://example.com></domain:name>
   C:         <domain:name>example.net<http://example.net></domain:name>
   C:         <domain:name>example.org<http://example.org></domain:name>
   C:       </domain:check>
   C:     </check>
   C:     <extension>
   C:       <fee:check
   C:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.6">
   C:         <fee:currency>USD</fee:currency>
   C:         <fee:command phase="sunrise">create</fee:command>
   C:         <fee:period unit="y">1</fee:period>

   S:         <fee:fee>5.00</fee:fee>

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:     <extension>

   S:       <fee:chkData
   S:         xmlns:fee="urn:ietf:params:xml:ns:fee-0.6">
   S:         <fee:cd>
   S:           <fee:name valid=“1">example.com<http://example.com></fee:name>
   S:         </fee:cd>
   S:         <fee:cd>
   S:           <fee:name valid=“0">example.net<http://example.net></fee:name>
   S:           <fee:currency>USD</fee:currency>
   S:           <fee:fee>10.00</fee:fee>
   S:         </fee:cd>
   S:         <fee:cd>
   S:           <fee:name valid=“0">example.org<http://example.org></fee:name>
   S:           <fee:currency>USD</fee:currency>
   S:           <fee:fee description=“Fixed Fee">2.50</fee:fee>
   S:           <fee:fee description=“Annual Fee”>7.00</fee:fee>

   S:           <fee:fee>9.50</fee:fee>

S: </fee:cd> S: <fee:cd> S: <fee:name valid=“0">example.xyz</fee:name> S: <fee:currency>USD</fee:currency>

   S:           <fee:fee>15.00</fee:fee>

S: <fee:class>premium-tier1</fee:class> 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>

Regards,

-------- Original Message --------
Subject: New Version Notification for draft-brown-epp-fees-03.txt
Date: Mon, 29 Sep 2014 06:52:20 -0700
From: [email-masked]<mailto:[email-masked]>
To: Gavin Brown <[email-masked]<mailto:[email-masked]>>, Gavin Brown
<[email-masked]<mailto:[email-masked]>>

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<http://tools.ietf.org>.

The IETF Secretariat

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