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

From: Roger D Carney <[email-masked]>
Date: Fri, 6 Sep 2019 14:48:12 +0000

Good Morning,

Thank you for your comments Carlos, please see my responses below. A new version of the draft will be published shortly and will address all of the review comments that needed edits.

Thanks

Roger

-----Original Message-----

From: Carlos Pignataro via Datatracker <[email-masked]>

Sent: Wednesday, July 3, 2019 2:51 AM

To: [email-masked]

Cc: [email-masked]; [email-masked]; [email-masked]

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

Notice: This email is from an external sender.

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.

[RDC] Agree, Note will be removed.

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

[RDC] Added clarifying text to section 3.4 “A fee will result in subtracting from the Account Balance (described section 3.5) and a credit will result in adding to the Account Balance (described in section 3.5).”

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

[RDC] Text updated.

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.

[RDC] This was discussed in another email but for completeness, this does state fee can be zero (a non-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.

[RDC] This allows server policy flexibility, allows a server to deny a transaction when the limit is reached or exceeded.

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?

[RDC] BEGIN/END is the standard that has been used in EPP RFCs. The copyright information in this section has been removed..

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.

[RDC] “Security Services” are any related security features/functions. “on-the-wire” monetary information has been addressed through secdir comments, an additional line of text for clarity was added.

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.

[RDC] The removal text also states to remove the reference.

Thanks!

Carlos Pignataro.

---

From: Roger D Carney <[email-masked]>
Date: Fri, 6 Sep 2019 14:48:16 +0000

Good Morning,

Thank you for your follow-up Carlos, please see my responses below. A new version of the draft will be published shortly and will address all of the review comments that needed edits.

Thanks

Roger

-----Original Message-----

From: Carlos Pignataro (cpignata) <[email-masked]>

Sent: Wednesday, July 3, 2019 11:38 AM

To: Barry Leiba <[email-masked]>

Cc: [email-masked]; IETF discussion list <[email-masked]>; [email-masked]; [email-masked]

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

Hi, Barry,

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

> Thanks, Carlos, for the review.

Anytime!

> On one item in your list:

>> 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.

> 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?

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?

[RDC] Yes, the currencies are the same and the schema enforces this rule.

Thanks,

-- Carlos.

> Barry

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 6 Sep 2019 16:15:39 +0000

Many thanks for following up, Roger. Ack on all your responses below!

— Carlos.

On Sep 6, 2019, at 10:48 AM, Roger D Carney <[email-masked]<mailto:[email-masked]>> wrote:

Good Morning,

Thanks
Roger

-----Original Message-----
From: Carlos Pignataro via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, July 3, 2019 2:51 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Opsdir last call review of draft-ietf-regext-epp-fees-16

[RDC] Text updated.

   A <fee:fee> element MUST

6. Section 6.1

Thanks!

Carlos Pignataro.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 Sep 2019 17:02:09 -0400

Thanks for making the updates, Roger.  I do have an issue with the
change to "non-negative" in Section 3.4:

> 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

Indeed, it was discussed, and the thing is that the text change is wrong:

New text:
   A <fee:fee> element MUST
   have a zero or non-negative value.  A <fee:credit> element MUST have
   a zero or negative value.

1. "Non-negative" already includes zero.  It does.  So "zero or
non-negative" is redundant and sounds silly.  But it's not wrong, so
if you really want that I'm not going to object further.  But...

2. By adding "zero or" to the credit part, you have changed the
meaning.  The original text said that it MUST be negative... so you
can't have a zero credit.  The new text allows that.  Is it really the
intent that a zero credit is permissible?

Barry

---

From: Roger D Carney <[email-masked]>
Date: Mon, 9 Sep 2019 12:04:48 +0000

Good Morning,

Thanks so much for catching this Barry. This was a mistake on my part, this was an in-process edit that should not have been published (it was some early thoughts on how to respond that we eventually decided to not make). You are completely correct and we did intend to leave the original language as it was, I will publish a new draft with this verbiage returned to its original text.

Sorry for the confusion everyone! And thanks again Barry for catching.

Thanks

Roger

-----Original Message-----
From: Barry Leiba <[email-masked]>
Sent: Friday, September 6, 2019 4:02 PM
To: Roger D Carney <[email-masked]>
Cc: Carlos Pignataro <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Opsdir last call review of draft-ietf-regext-epp-fees-16

Thanks for making the updates, Roger.  I do have an issue with the change to "non-negative" in Section 3.4:

> 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.

New text:

   A <fee:fee> element MUST

1. "Non-negative" already includes zero.  It does.  So "zero or non-negative" is redundant and sounds silly.  But it's not wrong, so if you really want that I'm not going to object further.  But...

2. By adding "zero or" to the credit part, you have changed the meaning.  The original text said that it MUST be negative... so you can't have a zero credit.  The new text allows that.  Is it really the intent that a zero credit is permissible?

Barry