Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
RFC 8748

Note: This ballot was opened for revision 18 and is now closed.

(Barry Leiba) Yes

(Ignas Bagdonas) No Objection

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2019-10-24)
Thank you for addressing my DISCUSS and COMMENT items.

Two editorial matters that seem to have come up in the edits.
** To address the discuss point "Section 6.1.  This section needs a normative reference to W3C Schema as the format of the blob between the BEGIN and END tags.", [W3C.REC-xmlschema-1-20041028] was added as a reference (thank you!) but not cited in the text.  Please cite that reference in Section 6.1 (or earlier)

** Per IDnits:  "== Missing Reference: 'RFC5646' is mentioned on line 449, but not defined"

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2019-09-15 for -18)
Firstly, thank you for working with Carlos to address the OpsDir comments -- he raised some good points (and is nicer than me), so I'm going to be a bit more of a stickeler than he was.

"A <fee:fee> element MUST have a non-negative value." -- Yes, zero is a non-negative value (Hi Barry!), but not listing it explicitly seems like it's just asking for someone to do something like:
## Estimate how many transactions like this we can do:
total_balance / fee       
or something similar. Simply mentioning the word should help lazy coders take this corner case into account. 

How would:
 A <fee:fee> element MUST must have a zero or greater value
work for you?

Also, I must admit I found this bit surprising:
"A <fee:credit> element MUST have a negative value."

If I go to Payless and return a pair of shoes, they give me a **credit** of $20, not of -$20. 
I really think that the credit element should either be treated in the same way, or you could do away with the credit elemans and just have negative "fees" (if I open my credit-card bill and see a charge of -$20 I know what it means), or if you don't want to do that,  provide some clear warning text around this section.
If I were implementing this, and not paying sufficient attention I'd calculate "new_balance = old_balance - fees + credits" -- a simple phrase or two should help prevent stupid errors.

(Mirja Kühlewind) No Objection

(Alexey Melnikov) No Objection

Alvaro Retana No Objection

(Adam Roach) No Objection

Éric Vyncke No Objection

Comment (2019-09-19 for -18)
Thank you for the work put into this document. I have only one COMMENT and one NITS see below.




-- Section 3.4 --
C.1) Any reason to have a negative value for <fee:credit> ? This seems counter-intuitive to me.

== NITS ==

Introducing <fee:cd> earlier in the text would improve the readability of the document.

(Magnus Westerlund) No Objection

Benjamin Kaduk (was Discuss) Abstain

Comment (2019-10-31)
No email
send info
I continue to be confused as to why it's desired to require a server to have
a single global policy knob for whether to return certain (e.g.) balance information,
and to rely on an underdocumented convention for how this requirement interacts
with error responses that would otherwise reflect an internal inconsistency in the
document.  But the description seems to be as intended, so I will not hold up publication.