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..."
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
