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

From: Gavin Brown <[email-masked]>
Date: Wed, 12 Aug 2015 10:59:42 +0100

Colleagues,

I appreciate that I've been rather quiet on the fee extension front
recently, but since the old draft was about to expire, I've pulled my
finger out and updated it based on feedback and discussions on this
list. Thanks to all who gave feedback.

Notable changes in this version:

   1.  Removed the extended <info> command.  The <check> command is the
       only command that can be used now.

   2.  Introduced a mandatory-to-implement "standard" class for non-
       premium domains.

   3.  The decision was made to keep availability info in <check>
       responses as registrars have indicated that it is very useful as
       it avoids unnecessary round trips to the server.

   4.  Allow <fee:credit> elements to be present in <check> responses.

   5.  Allow the number of <fee:fee> which can appear in transform
       responses to be zero.

   6.  Removed the <fee:balance> and <fee:creditLimit> elements from
       transfer query responses.  The reason is that these elements are
       defined as containing the values after the transform command has
       taken place - which means that it is not appropriate to include
       them in a query response.

   7.  Added Implementation Status section.

The only remaining item in the TODO list is to change the extension to
be object-agnostic. I am working on that at the moment.

If anyone out there has an implementation of this extension, I'd
appreciate it if you could email me the details for inclusion in the draft.

Thanks,

-------- Forwarded Message --------
Subject: New Version Notification for draft-brown-epp-fees-05.txt
Date: Wed, 12 Aug 2015 02:44:14 -0700
From: [email-masked]
To: Gavin Brown <[email-masked]>, Gavin Brown
<[email-masked]>

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

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

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: Alexander Mayrhofer <[email-masked]>
Date: Wed, 12 Aug 2015 13:24:27 +0000

Gavin,

i've done a quick review of the current version. I have not looked through earlier versions of the extension recently, so please excuse my points are not related to changes of the -05 version. Ok, here we go:

- 3.4.1: I have a strong opinion against "refundable" defaulting to "1". There are situations (like the Add-grace-period) where refunds depend on a complicated policy framework, and potentially cannot be determined in real time. This would lead to a situation where (just to be on the safe side) a server would always return "refundable=0", just to evade the potential legal implications of promising a refund that in the end could not be performed for policy reasons (and therefore, giving out false information in many cases where a fee would be refundable). Therefore, I think the best option would be to define that a client MUST NOT make any assumtions about the "refundability" (if that word exists) of a certain fee UNLESS an explicit value is given. The second best choice would be to default to "0", obviously. 

- 3.4.2: Same for the grace periods. Requiring a server MUST indicate to the client the grace periods significantly complicates the implementation of this extension. If I can't tell for sure whether a certain fee is refundable, or not (see ICANN AGP, again), what is the point of indicating the time period?

- 3.5 / 3.6: Generally, I feel that this extension reaches a bit too far into the f* word area ("financial", that is, in the IETF context - oh, no, he said it!) - this is partly be nature, but sometimes I feel it's inappropriate. For example: whether or not a "server has extended a line of credit" is out of scope of this specification. There's also a conflict with the different use of the word "credit" in the "fee:credit" element. I suggest removing the second sentence in 3.5  - it doesn't add value, but might raise issues.  And remove the first sentence from section 3.6.

- 4: The requirement for documentation is proably not an RFC2119 MUST - because then the IESG would probably ask the question what the mechanics behind are to ensure that this documentation is available. In this case, a lowercase "must" is better.

- 4: Why is the error code of disagreement between client and server calculated fees a "2004"? Wouldn't a 2104 ("billing failure") be more appropriate?

- 3.3: Is there a requirement that a server MUST support the "fee:period" element, or is implementation on the server side OPTIONAL as well?

- 5.1.1: I'm unsure about whether the chosen semantics of the presence/absence of the "fee:fee" element are good.  There's two reasons:

a) Reflecting whether or not a certain command is permitted sounds out of scope of a premium pricing extension to me. 
b) Registrars really want an easy way to identify whether "standard pricing" (negotiated out of band) applies to a command. Comparing the price in the "fee:fee" element with that standard pricing is a bad option, since there can be (out of band agreed) promotions that are not reflected in the registry system on a technical level.

I think it makes sense to change the semantics of the missing "fee:fee" element to "Standard pricing applies", and be silent on whether that command is available or not. 

- 5.2.3: Is the "fee" element in the renew command supposed to contain the *whole* fee for the selected period, or is this supposed to be the "1y" fee? Same for the transfer, obviously.

Tia,
Alex

> -----Ursprüngliche Nachricht-----
> Von: EppExt [mailto:[email-masked]] Im Auftrag von Gavin
> Brown
> Gesendet: Mittwoch, 12. August 2015 12:00
> An: [email-masked]
> Betreff: [eppext] Fwd: New Version Notification for draft-brown-epp-
> fees-05.txt
> 
> Colleagues,
>