Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
RFC 8748
Yes
No Objection
Abstain
Note: This ballot was opened for revision 18 and is now closed.
Alvaro Retana No Objection
Roman Danyliw (was Discuss) No Objection
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"
Warren Kumari No Objection
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.
Éric Vyncke No Objection
Thank you for the work put into this document. I have only one COMMENT and one NITS see below. Regards, -éric == COMMENT == -- 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.
(Barry Leiba; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) Abstain
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.