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

From: Gavin Brown <[email-masked]>
Date: Tue, 17 Feb 2015 11:47:54 +0000

I've just submitted a new version of the fee extension draft for your
review.

9.4. Changes from 03 to 04

   1.  Changed Intended Status to Standards Track.

   2.  As per suggestion from Michael Bauland, the <fee:period> element
       is no longer included in <check> and <info> responses for
       "restore" commands.  It's still mandatory for all other commands.

   3.  Added summary of the attributes for the <fee:fee> element.

   4.  Clarified that the "refundable" and "grace-period" attributes of
       the <fee> fee elements are dependant on each other and cannot
       appear on their own.

   5.  Removed the option of returning a 1001 response when the fee is
       incorrect.

   6.  Forbidden the inclusion of extension elements in transform
       responses if no fee/credit has been assessed.

   7.  Made the <fee:currency> element optional in transform commands.

   8.  Amended XML Namespace section of IANA Considerations, added EPP
       Extension Registry section.

10. TODO

   (Note to RFC Editor: remove this section before publication as an
   RFC.)

   1.  Make the extension object-agnostic so it can be used with other
       objects, not just vanilla domains.

   2.  Change the <check> command so that availability data is not
       returned.

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: [email-masked]
To: Gavin Brown <[email-masked]>

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

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

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, 17 Feb 2015 19:37:37 +0000

Gavin,

Thanks for posting the 04 update to the draft.  In reviewing the changes, I have the following feedback:

  1.  I believe you can remove the sentence “The <fee:period> element MUST be present in <check> and <info> commands and responses”, since it conflicts with the start of the paragraph “The <fee:period> element is OPTIONAL in <check> and <info> commands”.  The <fee:period> is OPTIONAL but has a default value of 1 year if omitted.
  2.  The infDataType type supports an OPTIONAL list of <fee:credit> elements, but section 5.1.2 does not include a description of it.
  3.  The domainCDType type supports an OPTIONAL list of <fee:credit> element, but section 5.1.1. does not include a description of it.
  4.  The transfer response as defined in section 5.1.3 does not define the added OPTIONAL <fee:credit> elements.  The use case for inclusion of a <fee:credit> element covers providing any applicable credits to the losing client of a transfer.  For example, an auto renew happened, then a transfer request is executed that applies a credit to the losing client for the auto renew.  Based on this use case, the <fee:fee> element should OPTIONAL, so minOccurs=0 should be defined.  The same holds true for the transfer response in section 5.2.4.  Does it make sense to include the same <fee:credit> information for the losing client for a transfer op=“approve”?
  5.  Support for the OPTIONAL list of <fee:credit> elements in the create, renew, and update responses is supported in the XML schema, but is not described in section 5.2.1, section 5.2.3, and section 5.2.5, respectively.
  6.  The <fee:currency> is required for the <fee:delData> element in the XML schema, but is defined as OPTIONAL in section 5.2.2.  I’m assuming that the XML schema is correct.
  7.  Since the response to the transform commands (create, renew, update) can include both fees and credits, the text “If no fee or credit has been assessed by the server for this transaction, a <fee:XXXData) element MUST NOT be included in the response” should be updated.

To note, I believe making the <fee:fee> element OPTIONAL in item #4 above is the only item that would require a change to the XML schema.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On Feb 17, 2015, at 6:47 AM, Gavin Brown <[email-masked]<mailto:[email-masked]>> wrote:

10. TODO

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: [email-masked]<mailto:[email-masked]>
To: 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

---

From: Ed Pascoe <[email-masked]>
Date: Wed, 18 Feb 2015 08:01:50 +0200

While I think this extension is well written and valuable I do have to
question if a standards track is appropriate?

The competing version of this is the UnitedTLD "Price Categories Guide"
http://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pdf
which has not been formally published. However its in active use by
Rightside, Donuts and Domain Name Services (that I know of) meaning that
around 190 new TLDs are using it or about to do so.

So the question is where do we go to from here? Do we try and get Rightside
to have the original author publish it to the EPP extension registry or do
we pretend it doesn't exist and ignore the significant percentage of new
TLDs using it?

---

From: Michael Holloway <[email-masked]>
Date: Wed, 18 Feb 2015 10:04:30 +0100

Ed, Good point.

The UnitedTLD is also used ZACR, while this extension is in use by 
CentralNIC, GMO, Charleston, Minds and Machines - albeit they are using 
varying versions. Ignoring the fact that the big 3 all have their their 
own alternatives (and 1 or 2 more), these two extensions already have a 
large coverage. UnitedTLD's extension is much simpler while this one is 
much more complex (due to registry input to Gavin indicating they want 
the flexibility).

I do not believe that any registry that has already implemented one or 
the other will switch, which means both of the extensions will continue 
to be used even if one were to take the lead.

So is there an argument to propose two standards for the same purpose or 
do we back the one that pushes in the interest of having a standard? Two 
standards are better than none which results in several alternative 
custom extensions, so I would back either or both if they are going down 
standards track.

Cheers,
Michael

*
Michael Holloway
Senior Systems Administrator**| Com Laude*
E: [email-masked] <mailto:[email-masked]>

On 02/18/2015 07:01 AM, Ed Pascoe wrote:
> Rightside, Donuts and Domain Name Services (that I know of) meaning 
> that around 190 new TLDs are using it or about to do so.
>
> So the question is where do we go to from here? Do we try and get 
> Rightside to have the original author publish it to the EPP extension 
> registry or do we pretend it doesn't exist and ignore the significant 
> percentage of new TLDs using it?
>
>
> On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     From: [email-masked] <mailto:[email-masked]>
>     until the htmlized version and diff are available at
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>
>     --
>     Gavin Brown
>     Chief Technology Officer
>     [email-masked] <mailto:[email-masked]>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 18 Feb 2015 12:09:34 +0000

From: EppExt [mailto:[email-masked]] On Behalf Of Ed Pascoe
Sent: Wednesday, February 18, 2015 1:02 AM
To: Gavin Brown
Cc: [email-masked]
Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.txt

While I think this extension is well written and valuable I do have to question if a standards track is appropriate?

The competing version of this is the UnitedTLD "Price Categories Guide" http://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pdf which has not been formally published. However its in active use by Rightside, Donuts and Domain Name Services (that I know of) meaning that around 190 new TLDs are using it or about to do so.

[SAH] I’d rather focus on number of operators/implementations than number of TLDs.

We can’t do nothing because some operators are doing their own thing and documenting their own extensions outside the IETF. We should focus on doing the best we can with what we have.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Feb 2015 14:26:27 +0000

I was the one that proposed that draft-brown-epp-fees be defined as Standards Track based on it being a published Internet Draft, based on the incorporation of community input, and based on interest to implement it by multiple independent parties.  I believe that we will find many extensions that privately exist with overlap.  We too have proprietary extensions that exist that have overlap with draft-brown-epp-fees, but these extensions were not targeted for Standards Track and there is little case for attempting to create competing Standards Track drafts.   In this case I see a lot of overlap between draft-brown-epp-fees and the private Price Categories Guide extension.  My recommendation is to register the Price Categories Guide extension as an Informational extension in the Extension Registry and contribute to the discussion around draft-brown-epp-fees to reconcile the material differences.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

On Feb 18, 2015, at 4:04 AM, Michael Holloway <[email-masked]<mailto:[email-masked]>> wrote:

Ed, Good point.

The UnitedTLD is also used ZACR, while this extension is in use by CentralNIC, GMO, Charleston, Minds and Machines - albeit they are using varying versions. Ignoring the fact that the big 3 all have their their own alternatives (and 1 or 2 more), these two extensions already have a large coverage. UnitedTLD's extension is much simpler while this one is much more complex (due to registry input to Gavin indicating they want the flexibility).

I do not believe that any registry that has already implemented one or the other will switch, which means both of the extensions will continue to be used even if one were to take the lead.

So is there an argument to propose two standards for the same purpose or do we back the one that pushes in the interest of having a standard? Two standards are better than none which results in several alternative custom extensions, so I would back either or both if they are going down standards track.

Cheers,
Michael

Michael Holloway
Senior Systems Administrator | Com Laude
E: [email-masked]<mailto:[email-masked]>

So the question is where do we go to from here? Do we try and get Rightside to have the original author publish it to the EPP extension registry or do we pretend it doesn't exist and ignore the significant percentage of new TLDs using it?

On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown <[email-masked]<mailto:[email-masked]>> wrote:
I've just submitted a new version of the fee extension draft for your
review.

10. TODO

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: [email-masked]<mailto:[email-masked]>
To: 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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

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

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

---

From: Roger D Carney <[email-masked]>
Date: Wed, 18 Feb 2015 15:18:23 +0000

Thanks for bringing this forward Ed!

I agree with Jim and think that we should encourage the author(s) of the "Price Categories Guide" to publish this document as an Informational extension to the Extension Registry.

Thanks
Roger

From: EppExt [mailto:[email-masked]] On Behalf Of Gould, James
Sent: Wednesday, February 18, 2015 8:26 AM
To: Michael Holloway
Cc: [email-masked]
Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.txt

-

JG

James Gould
Distinguished Engineer
[email-masked]

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

Ed, Good point.

Cheers,
Michael

Michael Holloway

10. TODO

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-04.txt
Date: Tue, 17 Feb 2015 02:16:09 -0800
From: [email-masked]<mailto:[email-masked]>
To: Gavin Brown <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

EppExt mailing list