Subject: [regext] Opsdir last call review of draft-ietf-regext-epp-fees-16

From: Carlos Pignataro via Datatracker <[email-masked]>
Date: Wed, 03 Jul 2019 00:51:08 -0700

Reviewer: Carlos Pignataro
Review result: Has Nits

Reviewer: Carlos Pignataro
Review Result: Has Nits

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

I hope these comments are useful and clear.

>From an operational point of view, the document describes protocol interactions
for dealing with failure conditions, and sets default behaviors. For example,
the RFC 2119 language explaining the use of <fee:currency> is super useful.

Minor comments, questions, and nits for your consideration follow:

1. Section 2 -- Migrating to Newer Versions of This Extension

   (Note to RFC Editor: remove this section before publication as an
   RFC.)

Since forward compatibility is a key operational consideration, why should this
section be removed? Especially when it contains RFC 2119 language.

2. Please do not treat as a pedantic comment, but I did not see an actual
definition for what "fee" and "credit" mean. Since these words have specific
context, it might not hurt to have a formal definition in Section 1.1

3. Should the citation / reference for "ISO 4217" be "ISO 4217:2015"?

4. S3.4. Does this text imply there is no zero fee or credit possible? Might be
useful to explicitly set guidance for the use of 0/null fee/credit.

   A <fee:fee> element MUST
   have a non-negative value.  A <fee:credit> element MUST have a
   negative value.

5. S3.6, why "equal to" and not only "exceed"?

   A server MAY reject certain
   transactions if the absolute value of the <fee:balance> is equal to
   or exceeds the value of the <fee:creditLimit> element.

6. Section 6.1

  * Should <CODE BEGINS> and <CODE ENDS> markers be used as per the TLP?
  * Should the (c) year be 2019?
  * And should the BSD License be part of the code?

7. Section 7, Security Considerations.

What are "security services"? Further, this protocol deals with on-the-wire
monetary information. I suspect there might be specific such considerations.

8. Section 9.  Implementation Status

If this section is removed, the reference to [RFC7942] would result hanging
without citations to it. ALthough the RFC Editor would catch, might want to
indicate removal of the Normative Reference as well.

Thanks!

Carlos Pignataro.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Jul 2019 09:17:42 -0400

Thanks, Carlos, for the review.

>    have a non-negative value.  A <fee:credit> element MUST have a

The text says the fee can be zero ("non-negative"), but the credit
can't (has to be negative).  That makes general sense, doesn't it?  Do
you really think there needs to be further explanation of that?

Barry

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 3 Jul 2019 16:38:01 +0000

Hi, Barry,

> On Jul 3, 2019, at 9:17 AM, Barry Leiba <[email-masked]> wrote:
> 

Anytime! 

> you really think there needs to be further explanation of that?

Since zero is neither negative nor positive, I thought it was potentially a source of misinterpretation.

But you are correct, the text as-is is accurate and perfect.

That is why I marked these as “Minor comments, questions, and nits for your consideration”. As this is an Ops-Dir review, Appendix A of RFC 5706 is detailed about defaults, boundary conditions, hence asking :-)

BTW, re-reading that section, I noticed:

   A server MAY respond with multiple <fee:fee> and <fee:credit>
   elements in the same response.  In such cases, the net fee or credit
   applicable to the transaction is the arithmetic sum of the values of
   each of the <fee:fee> and/or <fee:credit> elements.

Do these need to include the same <fee:currency> or otherwise how would the arithmetic sum work?

Thanks,

-- Carlos.