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

[Gavin Brown <[e-mail]>]

Hi Alex,

Thanks for the feedback. My apologies for the delay in responding.

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

I take your point, and I've updated my working draft to remove the
default value, and have added text to the effect that if the element is
missing, clients should not infer anything about refundability.

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

Agreed as above.

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

I disagree: whether the client has sufficient funds to perform billable
commands directly relates to EPP as a provisioning protocol. Plus there
is clearly a demand on the part of client implementers to have a way to
track and monitor the credit they have with servers.

> There's also a conflict with the different use of the word "credit" in the "fee:credit" element.

I believe I've already fixed this in my working draft.

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

The sentences in question are:

	3.5: If present, it can be used by the client to determine the
remaining credit at the
	server.

	3.6: As described above, if a server returns a response containing a
<fee:balance>
	with a negative value, then the server has extended a line of credit to
the client.

It is not clear to me what "issues" these sentences might raise.

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

Agreed - changed.

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

Because, in the strictest sense, the the client has failed to send a
parameter "whose value is outside the range of values specified by the
protocol" (RFC 5730). The 2104 error is defined as occurring when "a
server attempts to execute a billable operation and the command cannot
be completed due to a client-billing failure." There is no definition of
"client-billing failure" that I'm aware of, but I believe that this is
primarily used to indicate that the client has exhausted its credit. The
two conditions (sending the wrong fee, and not having enough money on
account) seem different enough to me that using the same error code is
inappropriate.

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

The <fee:period> element is mandatory in responses so yes, servers must
support this element. Do you feel that this needs to be made explicit?

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

This design arose from the scenario where a client sends a <fee:check>
element like this:

  <check xmlns="urn:ietf:params:xml:ns:fee-0.7">
    <domain>
      <currency>BTC</currency>
      <name>this is clearly an invalid domain!!!!.$(*&£"$</name>
      <command>create</command>
      <period unit="1">1</period>
    </domain>
  </check>

Should the server send a response saying "to create 'this is clearly an
invalid domain!!!!.$(*&£"$' please send 150 BTC kthbye"? That seems
misleading to me. Additionally, some implementations (for example,
CentralNic's) cannot calculate the fee for a domain without first
validating it: in such situations we were throwing the command back with
a 2004 error which was causing problems for some registrars.

So (with feedback from others on this list) I made the decision that the
absence of <fee:fee> elements in the <fee:cd> element in the response
indicates that the command described in the <fee:domain> element is not
permitted.

> 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 believe the <fee:class> element provides that mechanism.

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

That would cripple implementations that store no local state but rely on
being able to get the fee from the server every time they perform a
<check>: these implementations exist right now and I would not be keen
on breaking them.

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

Section 3.4 states categorically that "the net fee or credit applicable
to the transaction is the arithmetic sum of the values of each of the
<fee:fee> and/or <fee:credit> elements. This amount applies to the total
additional validity period applied to the domain (where applicable)
rather than to any incremental unit." So if you <renew> a domain for 10
years, the server will return <fee:fee> elements equal to the 10-year
renewal fee.

Thanks,

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