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

From: "Gould, James" <[email-masked]>
Date: Mon, 4 May 2015 23:13:05 +0000

Gavin,

I wanted to point out one item that may require more text in the draft to address.  The <fee:fee> element described in section 3.4 “Fees and Credits” covers its use when created by the server in the responses, but does not cover its use when created by the client in the transform commands (create, renew, transfer, and update).  My recommendation is to add text to section 3.4 covering the use case of the <fee:fee> element in the commands, since I don’t believe that the “description”, “refundable”, “grace-period”, and “applied” attributes are applicable in the command.  Both the “refundable” and “applied” attributes include defaults, so they will have values even if they are not explicitly set by the client.  I’m assuming that the server should ignore these attributes if they are set in the command, but I just want to confirm the expectation.

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:

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]<mailto:[email-masked]>
To: Gavin Brown <[email-masked]<mailto:[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.

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

---

From: Rubens Kuhl <[email-masked]>
Date: Mon, 4 May 2015 20:28:32 -0300

Perhaps it might not ignore, if the extension is being used to verify that client and server agree on the conditions for a specific name (its fee, whether a fraction of the application is refundable or not etc.)

Rubens

> Em 04/05/2015, à(s) 20:13:000, Gould, James <[email-masked]> escreveu:
> 
> Gavin, 
> 
> <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
> 
> James Gould
> Distinguished Engineer
> [email-masked] <x-msg://32/[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:
>> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: Gavin Brown <[email-masked] <mailto:[email-masked]>>
>> 
>> http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt <http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt>

---

From: Pat Moroney <[email-masked]>
Date: Mon, 4 May 2015 17:29:53 -0600

When performing a query command, if I receive a <fee:fee> in the response,
I would expect to be able to pass the exact <fee:fee> element back in the
appropriate transform command. I would also expect that all parameters that
were passed would be validated.

This would allow us to know that the parameters of that fee have not been
changed in the interval between the query command and the transform command.

On Mon, May 4, 2015 at 5:13 PM, Gould, James <[email-masked]> wrote:

>  Gavin,
>
>  I wanted to point out one item that may require more text in the draft
> to address.  The <fee:fee> element described in section 3.4 “Fees and
> Credits” covers its use when created by the server in the responses, but
> does not cover its use when created by the client in the transform commands
> (create, renew, transfer, and update).  My recommendation is to add text to
> section 3.4 covering the use case of the <fee:fee> element in the commands,
> since I don’t believe that the “description”, “refundable”, “grace-period”,
> and “applied” attributes are applicable in the command.  Both the
> “refundable” and “applied” attributes include defaults, so they will have
> values even if they are not explicitly set by the client.  I’m assuming
> that the server should ignore these attributes if they are set in the
> command, but I just want to confirm the expectation.
>
>  Thanks,
>
>  —
>
>
>  JG
>
>
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com
>
>  On Feb 17, 2015, at 6:47 AM, Gavin Brown <[email-masked]>
> wrote:
>
> From: [email-masked]
> To: Gavin Brown <[email-masked]>
>

-- 
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025

---

From: Keith Gaughan <[email-masked]>
Date: Mon, 18 May 2015 16:47:54 +0100

On 17/02/15 11:47, Gavin Brown wrote:

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

To make it easier for a registrar to tell whether or not a domain is
being given premium pricing (as opposed to some pricing tier), I would
suggest the following change regarding the <fee:class> element in §3.7:

    If the domain is being charged at the standard fee, then the
    reserved fee class 'standard' class MUST be used. Omitting the
    <fee:class> element indicates that the domain is subject to bespoke
    pricing.

I'm open to ideas on this change. My main reason for suggesting this is
to ensure that for domains subject to standard pricing, there's a single
standard mechanism for indicating this. I tried formulating it in such a
way as to minimise potential incompatibility with existing
implementations. I also wanted to clarify what omitting the <fee:class>
element might mean, as this is left undefined and could mean anything.

K.

-- 
Keith Gaughan, Development Lead; PGP/GPG key ID: D5FC9D23
Blacknight Internet Solutions Ltd. <http://blacknight.host/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845