Re: [regext] AD Review: draft-ietf-regext-epp-fees-15

[Roger D Carney <[e-mail]>]

Good Morning,



Thanks for the review and input Adam.



·       Abstract updated with some more introductory verbiage.

·       Updated 1.1 with lower “required”

·       Updated 3.1 with “that” in place of “which”

·       Updated 3.4 with “lang” attribute for consistency

·       Question on 3.4.1:  I thought the intent was your #1 interpretation “If a <fee:fee> element has a "grace-period" attribute but does not also contain "refundable='1'", then it is malformed”. I would like the list to provide thoughts.

·       Interesting question on 3.5. I agree that either way would be ok, my thought was that the balance would not include “delayed”. I would like the list to provide thoughts.

·       Updated 3.6 with “that” in place of “which”

·       Updated 3.7 with “that” in place of “which”



I will release revision 16 after some list discussion on 3.4.1 and 3.5.





Thanks

Roger





-----Original Message-----
From: Adam Roach <[e-mail]>
Sent: Friday, January 4, 2019 9:08 PM
To: [e-mail]
Cc: [e-mail]
Subject: AD Review: draft-ietf-regext-epp-fees-15



This is my AD review of draft-ietf-regext-epp-fees. It looks to be in generally good shape, although I have marked two of my feedback items below as "DISCUSS".

This doesn't necessarily mean they need to result in document changes (as I might be mistaken), but I would like to make sure we address them in some way before I put the document into IETF last call.



The remainder of my comments should be treated the same as any IETF last call comments.



Thanks to everyone who has worked on this document, and I apologize for the longer-than-usual processing time on my part.



---------------------------------------------------------------------------



Abstract:



This section should probably be a bit longer, incorporating some of the background from the introduction.



---------------------------------------------------------------------------



§1.1:



>  Indentation and

>  white space in examples are provided only to illustrate element  >  relationships and are not a REQUIRED feature of this protocol.



This is a somewhat unconventional use of RFC-2119-style language. I would recommend using a lowercase "required" in this case.



---------------------------------------------------------------------------



§3.1:



>  The <fee:command> element is used in the EPP <check> command to  >  determine the fee which is applicable to the given command.



Nit: "...the fee that is applicable..."



---------------------------------------------------------------------------



DISCUSS:



§3.4:



>  description: an OPTIONAL attribute which provides a human-readable  >  description of the fee.  Servers should provide documentation on the  >  possible values of this attribute, and their meanings.



Since this string is human-readable, localization considerations apply.

Minimally, this needs to include the ability to add a "lang" attribute, similar to what is done for <fee:reason>



---------------------------------------------------------------------------



DISCUSS:



§3.4.1 says:



>  If the "refundable" attribute is omitted, then clients SHOULD NOT  >  make any assumption about the refundability of the fee.



§3.4.3 says:



>  If a <fee:fee> element has a "grace-period" attribute then it MUST  >  also be refundable.



This second statement is a bit confusing in the context of the first one.

There's two ways to read it:



1. If a <fee:fee> element has a "grace-period" attribute but does not also

   contain "refundable='1'", then it is malformed; or



2. If a <fee:fee> element has a "grace-period" attribute but does not also

   contain "refundable='1'", then the client is required to make an

   assumption that the fee is refundable.



If the intention is #1, then the language in 3.4.3 needs to be more explicit.



If the intention is #2, then it contradicts the language in §3.4.1, and the language in §3.4.1 needs to be adjusted to indicate this exception.



---------------------------------------------------------------------------



§3.5:



>  If a server includes a <fee:balance> element in response to transform  >  commands, the value of the element MUST reflect the client's account  >  balance after any fees or credits associated with that command have  >  been applied.



I'm confused about how this value interacts with applied="delayed".

Since the

charge won't happen during the course of the transaction, does the balance include the effect of applying the fee? I don't think it matters much whether the answer is "yes" or "no," as long as implementations are consistent (which I believe requires the behavior to be clearly specified in this section).



---------------------------------------------------------------------------



§3.6:



>  line of credit to the client.  A server MAY also include a  >  <fee:creditLimit> element in responses which indicates the maximum  >  credit available to a client



Nit: "...in responses that indicates..."



---------------------------------------------------------------------------



§3.7:



>  Servers which make use of this element MUST use a <fee:class> element



Nit: "Servers that make use..."