Good Morning,
Thanks for your comments Warren, please see my responses below, a new revision will be published shortly to address issues brought up in this latest round of comments. Thanks Roger -----Original Message----- From: Warren Kumari via Datatracker <nore...@ietf.org> Sent: Sunday, September 15, 2019 2:34 PM To: The IESG <i...@ietf.org> Cc: draft-ietf-regext-epp-f...@ietf.org; James Gould <jgo...@verisign.com>; regext-cha...@ietf.org; jgo...@verisign.com; regext@ietf.org; cpign...@cisco.com Subject: Warren Kumari's No Objection on draft-ietf-regext-epp-fees-18: (with COMMENT) Notice: This email is from an external sender. Warren Kumari has entered the following ballot position for draft-ietf-regext-epp-fees-18: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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? [RDC] With a couple of reviewers suggesting clarity, the document will be updated to " A <fee:fee> element MUST have a zero or greater value (non-negative)." 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. [RDC] The fee and credit elements are separated to handle the positive and negative cases associated with a billable operation. I believe from a non-accounting mind it is much easier and consistent for the client to add the fees and credit values together. The fee values are positive values and the credit values are negative values. In the Payless example, the customer may see a positive credit value, but mathematically it is a negative value. It's best to keep the positive fees and the negative credits in the protocol for clarity.
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
