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

["Gould, James" <[e-mail]>]

Roger,

In reviewing the items.  I provide my feedback embedded within your list, prefixed with “JG – “.

—

JG

[cid:[e-mail]933A30]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Roger Carney <[e-mail]>
Date: Monday, February 11, 2019 at 7:29 AM
To: Adam Roach <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] RE: AD Review: draft-ietf-regext-epp-fees-15
Resent-From: <[e-mail]>
Resent-To: Roger Carney <[e-mail]>, Gavin Brown <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, James Gould <[e-mail]>, James Gould <[e-mail]>
Resent-Date: Monday, February 11, 2019 at 7:29 AM


Good Morning,



Thanks for the review and input Adam.



·         Abstract updated with some more introductory verbiage.


JG - Simple fix


·         Updated 1.1 with lower “required”


JG - Simple fix

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


JG - Simple fix



·         Updated 3.4 with “lang” attribute for consistency


JG - I assume that you’re going to add <attribute name="lang" type="language" default="en"/> to the feetype element of the XML schema, along with a description of the “lang” attribute in 3.4.  Would you also need to add the same “lang” attribute to the “creditType” element in the XML schema, and include it for the description of the <fee:credit> element in section 3.4?



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


JG - I would simply say “If a <fee:fee> element has a “grace-period” attribute then it must be refundable and the “refundable” attribute MUST be true.”



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


JG - This one is interesting, since I view the <fee:balance> as being the balance as of a point of time.  The point in time should be when the response is created, so if the “applied” attribute is “immediate”, then the <fee:balance> MUST reflect the client’s account balance after any fees or credits associated with that command have been applied.  If the “applied” attribute is “delayed”, then the <fee:balance> MUST reflect the client’s account balance without any fees or credits associated with that command.



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


JG - Simple fix


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


JG - Simple fix



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