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

"Gould, James" <> Fri, 04 December 2015 13:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C0931B3192 for <>; Fri, 4 Dec 2015 05:36:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jpcXB2oWtTn1 for <>; Fri, 4 Dec 2015 05:36:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c04::263]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B10911B3196 for <>; Fri, 4 Dec 2015 05:36:44 -0800 (PST)
Received: by qgeb1 with SMTP id b1so7179479qge.0 for <>; Fri, 04 Dec 2015 05:36:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-type:mime-version; bh=A/KEGo2fAGhUG8Mv3UOuw5MuI4QD/d8gY9VyZ63STcg=; b=Q4PjWxsFqcZ1S4USjErgwEUPKtm6r9yCbObPO7S/uN/g7StLutjBaqp70rgmyH6fiY GgAfo9HR2tEziN5rNFrc6JwK5GQAyTcZw5MgVVY3/p9dFJckjlLNFRlUZyBYwM1EPbFb ILiXMLGx8RxCaRc6nhNqyst5XYvAnK1tr4+D0DP66QrYcKaVSiGaRAwfzijuooh1qmWJ 9Xd/EHIfXzZ0fI5rEY2hbb6sNikODGiwJiQJGZGvzWIqxfeeFzj+MrUJAw0HxosXbJVh cSwbq4kGwkfUWKooDC5QlV6m0goP/Ksv/9sOTwaU+iVBns1+IxUn0LqxOJt7oZem0uUP oaAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-type:mime-version; bh=A/KEGo2fAGhUG8Mv3UOuw5MuI4QD/d8gY9VyZ63STcg=; b=l0S9DWsZyeNSAuN+/oRrFQ9i9WFv1Jez6/4/4V0ruPwdzBbgTAi9qMncn91JaYhx4T +8ct064pRNpiQosHU+V4t1Axwij1UvmgC2oipc8hIvUO4V4xZqfMURYXTCgL2auBx1x8 zLduvGH4RMi6bn7iNpIJRcqPDlsv3Jr3cdYxJ3THc9kH8NWGMxvK6pmFEHwEKOMlGqcf 7mlCJ3fwKNQs4FJQ7mFmWIml7Gz5RpTsJ2uC2zkQFhvmgWQcMuwum5MU4uLx7tVDUOtf V60CtxUPa8vK2WUz68mtqO6MIcaQfe/GADrUP34i8igN5qSHkKvY1mk4rojNHLfYgNeS Kiuw==
X-Gm-Message-State: ALoCoQkWeYS/94XdS+3hL2OO3mGlKqkutPmwfG8/gKN9NJmtfy9cTe5Xq8jgiocZ29/zn1o2qQd/K2T6eOpbUJeTFZkxYls8/Q==
X-Received: by with SMTP id 97mr6796253qkp.98.1449236203409; Fri, 04 Dec 2015 05:36:43 -0800 (PST)
Received: from ( []) by with ESMTPS id y145sm462365qka.12.2015. (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 04 Dec 2015 05:36:43 -0800 (PST)
Received: from (brn1wnexcas02 []) by (8.13.8/8.13.8) with ESMTP id tB4DagID027094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Dec 2015 08:36:42 -0500
Received: from ([::1]) by ([::1]) with mapi id 14.03.0174.001; Fri, 4 Dec 2015 08:36:42 -0500
From: "Gould, James" <>
To: Gavin Brown <>
Thread-Topic: [eppext] New Version Notification for draft-brown-epp-fees-06.txt
Thread-Index: AQHRLpjPedOBw7486ESUYzj49wjAtA==
Date: Fri, 04 Dec 2015 13:36:42 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/related; boundary="_004_CA1DDA3CE21E4BDB95F31CE92585A7A4verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [eppext] New Version Notification for draft-brown-epp-fees-06.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 13:36:49 -0000


In reviewing draft-brown-epp-fees-06, I have the following feedback:

  1.  The fee check extension is really not a good fit for extension of the available check.  They have different purposes and there is really no relationship between the two, where the availability check can include a completely different set of domain names from getting the fee extension.  My recommendation is to separate the two and define the fee check as a new verb similar to the claims check in draft-ietf-eppext-launchphase.  Another option is truly extend the object identifiers (e.g. domain:names) in the check command with a set of fee attributes to get the fee information for.  Have the extension only specify the command and the optional currency and fee that applies to all of the names in the availability check command.  The response would include the same list of object identifiers in the extension, but it would be a one-to-one relationship.  In this way there is no need for the “objURI” attribute, the <fee:objID> element, and <fee:objID> “element” attribute in the check command, since the object and identifying element is already defined by the availability check object that is being extended.
  2.  What should be returned when the client passes invalid data in the check command for the the “objURI” attribute (e.g. “urn:made:up:uri”), the <fee:objID> element (e.g. invalid domain name), the “element” attribute of <fee:objID> (e.g. “madeup”), the <fee:currency> element (e.g. “MUP”), and the <fee:period> element (e.g. “99" when max is “10”)?  An invalid <fee:command> is covered by not returning the fee information, but it’s unclear whether the server should return an error or not return the fee information for other invalid data.  To follow the semantics of a check command and response, my recommendation is to add an “avail” attribute to either <fee:cd> or <fee:objID> to explicitly indicate that the fee information is available along with an optional <fee:reason> to indicate the reason that the fee information is not available.  The reason the fee information is not available for a particular object could be due to the passing of invalid input in the check command <fee:object> element.  If you went with a single set of fee elements in the check command that is applied to all of the object identifiers in the availability check, then an invalid fee element could result in a failure of the check command itself instead of being an error (e.g. not available) on a per domain basis.
  3.  Since the check response supports returning a “0.00” value to indicate no fee, doesn’t make sense to do the same with all transform command responses?




James Gould
Distinguished Engineer

12061 Bluemont Way
Reston, VA 20190<>

On Nov 4, 2015, at 5:58 PM, Gavin Brown <<>> wrote:

Changes from 05 to 06:

  1.  The specification is now object-agnostic, but works with RFC5731
      [RFC5731] domains by default.

  2.  Renamed the <fee:domain> element to <fee:object>.  Added the
      "objURI" attribute.

  3.  Removed the default value for the "refundable" attribute of
      <fee:fee> elements, and added text about how clients should
      handle such cases.  Added similar text to the documentation of
      the "grace-period" attribute.

  4.  Removed references to the defunct <info> command syntax.

  5.  "MUST" requirements regarding documentation have been changed to

  6.  Created separate "Correlation between Refundability and Grace
      Periods" section describing how the "refundable" and "grace-
      period" attributes work together.

Feedback welcome as always!

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-06.txt
Date: Wed, 04 Nov 2015 14:52:30 -0800
To: Gavin Brown <<>>, Jothan Frakes

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

Name: draft-brown-epp-fees
Revision: 06
Title: Registry Fee Extension for the Extensible Provisioning Protocol
Document date: 2015-11-04
Group: Individual Submission
Pages: 36

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

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

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,

EppExt mailing list