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

[Alexander Mayrhofer <[e-mail]>]

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:[e-mail]] Im Auftrag von Gavin
> Brown
> Gesendet: Mittwoch, 12. August 2015 12:00
> An: [e-mail]
> Betreff: [eppext] Fwd: New Version Notification for draft-brown-epp-
> fees-05.txt
> 
> 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: [e-mail]
> To: Gavin Brown <[e-mail]>om>, Gavin Brown
> <[e-mail]>
> 
> 
> 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.
> 
>