Subject: [regext] Warren Kumari's No Objection on draft-ietf-regext-epp-fees-18: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Sun, 15 Sep 2019 12:33:57 -0700

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?

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.