Subject: Re: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)

From: Roger D Carney <[email-masked]>
Date: Tue, 1 Oct 2019 14:41:20 +0000

Good Morning,

Thanks for your comments Benjamin, 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: Benjamin Kaduk via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Monday, September 16, 2019 11:26 AM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; James Gould <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)

Notice: This email is from an external sender.

Benjamin Kaduk has entered the following ballot position for

draft-ietf-regext-epp-fees-18: Discuss

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/

----------------------------------------------------------------------

DISCUSS:

----------------------------------------------------------------------

I think (at least with the present formulation) we need greater clarity on when the "it's up to server policy whether to include, but that policy must be the same for all transactions" elements (<fee:balance> and <fee:creditLimit>) are returned, as at present there seems to be an internal inconsistency in the text.  Section 3.5 and 3.6 just talk about including them "in responses to all 'transform' or billable commands", but then we have more qualified text such as (but not limited to) in Section 5.2.5 that only has <fee:updData> (and its children) included when the <update> has been processed successfully.  So, are <fee:balance> and <fee:creditLimit> supposed to be included in error responses or not?

[RDC] I am not sure I see the real issue as I don’t read a conflict here (technically 5.2.5 [and others] don’t say “<fee:updData> (and its children)” can only be included in successful responses, the sections just don’t discuss if “<fee:updData> (and its children)” should/shouldn’t be included in errors. I would assume a server would most likely not return these data on errors, but I also don’t see harm if they do and the extension allows for both.

----------------------------------------------------------------------

COMMENT:

----------------------------------------------------------------------

It might be helpful to note somewhere that <fee:cd> stands for "check data", as per stock EPP, since we use the term a few times before we get to the <fee:chkData> context and its definition.

[RDC] “(check data)” will be added to section 5.1.1 where <fee:cd> is defined.

Section 1

   Given the expansion of the DNS namespace, and the proliferation of

   novel business models, it is desirable to provide a method for EPP

It's not clear to me whether all readers (whether now or in ten years) will have the context to appreciate what is meant by these background clauses.

[RDC] I think that is true that not all clients will have the context to appreciate it, but the proliferation of novel business models did lead to the creation of the extension, so it seems like the context is relevant and needed.

Section 3.3

   When querying for fee information using the <check> command, the

   <fee:period> element is used to indicate the units to be added to the

   registration period of objects by the <create>, <renew> and

   <transfer> commands.  This element is derived from the

   <domain:period> element described in [RFC5731].

The word "units" here is really confusing me.  Even after reading the rest of the document (and 5731's definition of periodType) it still feels like there's some words missing here.

[RDC] Section 3.3 will be updated for clarity: “When querying for fee information using the <check> command, the <fee:period> element is used to indicate the period measured in years or months, with the appropriate units specified using the “unit” attribute, to be added to the registration period of objects by the <create>, <renew> and <transfer> commands.”

Section 3.4

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

   applies to the total additional validity period applied to the object

   (where applicable) rather than to any incremental unit.

"unit" here is also confusing to me, though less so.  I think what's going on here is just the common-sense "the sum of all fees/credits applies for the conceptual 'sum' of all the indicated registry operations taken together", in which case I might suggest to s/incremental unit/individual component of the transaction/.

[RDC] Section 3.4 will be updated for clarity: “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.  This amount applies to the total additional validity period applied to the object (where applicable).”

   description: an OPTIONAL attribute which provides a human-readable

   description of the fee.  Servers should provide documentation on the

   possible values of this attribute, and their meanings.  An OPTIONAL

   "lang" attribute MAY be present to identify the language of the

   returned text and has a default value of "en" (English).

I assume we're reusing the "lang" semantics from 5730 (which in turn relies on 4646), but it's probably worth being explicit about it.

[RDC] “Language identifiers MUST be structured as documented in [RFC4646].” Will be added to the end of the paragraph.

Section 3.4.3

   If a <fee:fee> element has a "grace-period" attribute then it MUST

   also be refundable and the "refundable" attribute MUST be true.  If

   the "refundable" attribute of a <fee:fee> element is false then it

   MUST NOT have a "grace-period" attribute.

If a client receives a response that contravenes these requirements, what should it do?

[RDC] I think as with any non-conformance the client should notify the server of RFC non-compliance and have the server fix the issue.

Section 3.5, 3.6

For these elements that the server MUST include in all responses if it chooses to include them in (any) responses, do we expect that to be global server policy, or potentially tailored to individual clients?

(Also, I'm vaguely curious how much it could increase the response footprint, not that XML is a terribly concise representation to start

with.)

[RDC] Inclusion of these elements is up to server policy.  A server may define a client-specific setting for inclusion or exclusion of this information, but that is unlikely and out-of-scope for the extension.  The EPP packets in general are relatively small (<1k).  The increase in size is not impactful.

Section 3.7

   If a server makes use of this element, it should provide clients with

   a list of all the values that the element may take via an out-of-band

   channel.  Servers MUST NOT use values which do not appear on this

   list.

I think we generally dislike to rely on out-of-band channels to quite this extent, though it's not clearly wrong for this case.  I'm somewhat curious (not necessarily to include in the document) what existing out-of-band channels for this look like, though.

[RDC] There are several “channels”: contract, report, spreadsheet, reference manuals, etc.

Section 4

   The server MUST return avail="0" in its response to a <check> command

   for any object in the <check> command that does not include the

   <fee:check> extension for which the server would likewise fail a

   domain <create> command when no <fee> extension is provided for that

   same object.

nit: this wording makes it sound like avail="0" is scoped to the object, as opposed to the check data.  So maybe s/for any object/if any object/?

[RDC] The <check> command in RFC 5731 supports checking the availability of multiple objects, where RFC 5730 does not specify whether the <check> command is associated with one or more objects.  The language in section 4 addresses both one object or many objects by using “for any object”.  Changing “for any object” to “if any object” will not cover the many object case.

   If a server receives a <check> command from a client, which results

   in no possible fee combination but where a fee is required, the

   server MUST set the "avail" attribute of the <fee:cd> element to

   false and provide a <fee:reason>.

nit: I'm not sure how to interpret "where a fee is required" just given what's in this document.

[RDC] Section 4 will be updated to remove “but where a fee is required” as it is not needed.

   If the currency or total fee provided by the client is less than the

   server's own calculation of the fee for that command, then the server

   MUST reject the command with a 2004 "Parameter value range" error.

How can a currency be "less than the server's own calculation"?  (I assume this is supposed to be "currency is different".)

[RDC] Two separate ideas: “currency” or “total fee provided by the client is less than the…”

Section 5.1.1

   When the server receives a <check> command that includes the

   extension elements described above, its response MUST contain an

   <extension> element, which MUST contain a child <fee:chkData>

   element.  The <fee:chkData> element MUST contain a <fee:currency>

   element and a <fee:cd> for each element referenced in the client

   <check> command.

Can we be more precise about "for each element referenced in the client <check> command"?  ("No" is a valid answer.)  Specifically, does this apply to the <domain:check> child elements in the <check>, or to the <fee:check> extension elements, or something else?  (My guess from the examples is the former.)

[RDC] Correct it applies to the <check> child elements. The last sentence will be updated: “The <fee:chkData> element MUST contain a <fee:currency> element and a <fee:cd> element for each object referenced in the client <check> command”.

   o  A <fee:command> element matching each <fee:command> (unless the

      "avail" attribute of the <fee:cd> if false) that appeared in the

      corresponding <fee:check> of the client command.  This element MAY

      have the OPTIONAL "standard" attribute, with a default value of

      "0" (or "false"), which indicates whether the fee matches the fee

      of the "standard" classification (see section 3.7).  This element

      MAY have the OPTIONAL "phase" and "subphase" attributes, which

      SHOULD match the same attributes in the corresponding

      <fee:command> element of the client command if sent by the client.

I don't think I see how the SHOULD could be applicable -- doesn't Section 3.8 place tight requirements on server behavior and errors regarding phase/subphase in requests?  That is, I think the descriptive "will match" would be appropriate here.

[RDC] Agreed, section will be updated.

   The <fee:command> element(s) MAY have the following child elements:

   o  An OPTIONAL <fee:period> element (as described in Section 3.3),

      which contains the same unit that appeared in the <fee:period>

      element of the command.  If the value of the preceding

      <fee:command> element is "restore", this element MUST NOT be

      included, otherwise it MUST be included.  If no <fee:period>

      appeared in the client command (and the command is not "restore")

      then the server MUST return its default period value.

I think we need some caveat language ("if present"?) for "the same unit that appeared in the <fee:period> element of the command", since that element is OPTIONAL in the command in question.

[RDC] Agreed, this section will be updated, changing the first sentence of this bullet to: “An OPTIONAL <fee:period> element (as described in Section 3.3), which contains the same unit, if present, that appeared in the <fee:period> element of the command.”

nit: is this the "preceding <fee:command> element" or "parent <fee:command> element"?  Also, the rhetorical value of the "OPTIONAL" is unclear, as there's no server choice in the matter -- its presence/absence is fully determined by the <fee:command> value.

[RDC] Section will be updated, changing to “parent <fee:command> element”.  The “OPTIONAL” indicator reflects what’s defined in the XML schema, where the client will not fail processing the response if the <fee:period> element is not returned.

   If the "avail" attribute of the <fee:cd> element is true and if no

   <fee:fee> elements are present in a <fee:command> element, this

   indicates that no fee will be assessed by the server for this

   command.

   If the "avail" attribute is true, then the <fee:command> element MUST

   NOT contain a <fee:reason> element.

In this second quoted paragraph, is this the "avail" attribute only of <fee:command> or does it apply to <fee:cd> as well?

[RDC] For clarity this will be updated as: “If the "avail" attribute of the <fee:cd> element is true, then the <fee:command> element MUST NOT contain a <fee:reason> element.”

Section 5.2.1

   The server MUST fail the <create> command if the <fee:fee> provided

   by the client is less than the server fee.

I think we are more specific about this ("Parameter value range" error) in Section 4, which is also a MUST-level requirement.

[RDC] Sentence will be removed, already covered by section 4.

It's perhaps a bit anachronous to have a domain-creation example from

1999 when the -00 of this document's precedessor wasn't until 2013.

Section 5.2.3

[The examples here are only from 2005; progress!]

[RDC] Dates will be updated accordingly.

Section 7

Thank you for addressing the points discussed in the secdir review.

That said, the text of this section still feels a bit sparse, with it mostly being bare statements without much discussion of the motivation for or consequences of many of the requirements at hand.  For example, we could say something about why it's important to provide confidentiality/integrity protection for financial data, say more about what the "needed level of [...] protection" is, and reiterate that the transport protocol has to do so because there are no in-band EPP mechanisms to do so.  It would also be fine to reiterate any key considerations from 5730/5731, if there are any that seem particularly relevant (but it's also fine to not do so).

Also, I think that it's important to add "peer authentication" to the list of protections provided by the transport -- it's important to know who you're talking to when sending financial information!  (Though, the client is just sending its estimate of the server's fee schedule, which is a lot less sensitive than sending its current balance.)

[RDC] I don’t think there is a need for this extension to duplicate or attempt to redefine the security defined in RFC 5730.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 4 Oct 2019 12:25:23 -0700

> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

I'm still at a point where I don't even know what the expected behavior is,
so I can't comment on which text is correct or confusing.  It is sounding
like you think it's okay to not have <fee:balance> returned in error
responses, though, in which case Sections 3.5/3.6 would benefit from
another couple words (e.g., "MUST be included in non-error responses") to
make that clear.

I'm not saying you shouldn't give the extra background information; if
anythin I'm saying to give more of it, to record some of what is currently
common knowledge but will probably not be common knowledge in 10 or 20
years.

> [RDC] Section 3.3 will be updated for clarity: “When querying for fee information using the <check> command, the <fee:period> element is used to indicate the period measured in years or months, wit…

Thanks!

> [RDC] Section 3.4 will be updated for clarity: “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…

That matches what I thought the meaning was and doesn't make me confused;
thanks!

> [RDC] Two separate ideas: “currency” or “total fee provided by the client is less than the…”

Clearly.  But that's not what the quoted text says, so I assume there is a
text change queued up.

> [RDC] I don’t think there is a need for this extension to duplicate or attempt to redefine the security defined in RFC 5730.

This wass a non-blocking comment, so you're free to ignore it, but I will
note that I proposed several changes that in my opinion are doing neither
of those things.

Thanks for all the updates,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 23 Oct 2019 15:40:13 -0700

> another couple words (e.g., "MUST be included in non-error responses") to

To attempt to clarify my understanding (in the hope that the flaws therein
will become more clear), I read this text from Section 3.5:

   Whether or not the <fee:balance> is included in responses is a matter
   of server policy.  However, if a server chooses to offer support for
   this element, it MUST be included in responses to all "transform" or
   billable commands (e.g. <create>, <renew>, <update>, <delete>,
   <transfer op="request">).

as saying that the server has a single yes/no policy knob that is global
for all clients and requests, that controls whether <fee:balance> is
included in responses to [the listed] commands.  It doesn't say anything
about success vs. error, so I assume it applies to all (both types of)
responses.

This is kind of a weird requirement to me, absent further context, since it
doesn't give the server any discretion to omit it when it doesn't make
sense or provide it only sometimes; it also seems pretty hard to enforce,
and provides only a minimum level of interoperability gain that I can see
(unless we expect a large population of clients that only ever talk to one
server).  But, that's what the current text seems to say.

Then, in Section 5.2.5, we say that:

   When the <update> command has been processed successfully, and the
   client included the extension in the <login> command service
   extensions, the server MAY include in the <extension> section of the
   EPP response a <fee:updData> element, which contains the following
   child elements:
   [... things including <fee:balance>]

There does not seem to be any treatment anywhere in the document about
<fee:updData> for error responses, so I assume that what is not explicitly
specified is ... not specified, and therefore not part of this spec.

So on the one hand, I have this global knob that, if set to "yes", says I
have to include <fee:balance> on error responses, and on the other hand no
specification of an element in which to include <fee:balance> for error
responses.  Were I to implement this spec as-written, I'd be forced to
assume that the "yes" case is unimplementable and only support the "no"
variant, or try to come up with something on my own for how to do the error
case.  I want to avoid making implementers face such a choice, as "come up
with something on my own" has a history of being really bad for
interoperability.

Hope this helps,

Ben

---

From: Roger D Carney <[email-masked]>
Date: Mon, 28 Oct 2019 15:44:11 +0000

Good Morning,

Thank you for your clarification remarks Benjamin.

By convention the extensions are not included in EPP error responses unless it's explicitly stated or obvious based on the purpose of the extension.  We don't see any scenario that a server that supports returning the draft-ietf-regext-epp-fees balance information will return it in an error response.  We do not recommend changing the language of the draft to explicitly state the convention for an optional response attribute.

Thanks

Roger

-----Original Message-----
From: Benjamin Kaduk <[email-masked]>
Sent: Wednesday, October 23, 2019 5:40 PM
To: Roger D Carney <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)

> > From: Benjamin Kaduk via Datatracker

> > <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

> > To: The IESG <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>

> > Cc:

> > [email-masked]<mailto:draft-ietf-regext-epp-fee<mailto:[email-masked]%3cmailto:draft-ietf-regext-epp-fee>

> > [email-masked]<mailto:[email-masked]>>; James Gould

> > <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>;

> > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>;

> > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>;

> > [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>

> > Subject: Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18:

> > (with DISCUSS and COMMENT)

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

> > --------------------------------------------------------------------

> > --

> > --------------------------------------------------------------------

> > --

> I'm still at a point where I don't even know what the expected

> behavior is, so I can't comment on which text is correct or confusing.

> It is sounding like you think it's okay to not have <fee:balance>

> returned in error responses, though, in which case Sections 3.5/3.6

> would benefit from another couple words (e.g., "MUST be included in

> non-error responses") to make that clear.

To attempt to clarify my understanding (in the hope that the flaws therein will become more clear), I read this text from Section 3.5:

as saying that the server has a single yes/no policy knob that is global for all clients and requests, that controls whether <fee:balance> is included in responses to [the listed] commands.  It doesn't say anything about success vs. error, so I assume it applies to all (both types of) responses.

This is kind of a weird requirement to me, absent further context, since it doesn't give the server any discretion to omit it when it doesn't make sense or provide it only sometimes; it also seems pretty hard to enforce, and provides only a minimum level of interoperability gain that I can see (unless we expect a large population of clients that only ever talk to one server).  But, that's what the current text seems to say.

   child elements:

There does not seem to be any treatment anywhere in the document about <fee:updData> for error responses, so I assume that what is not explicitly specified is ... not specified, and therefore not part of this spec.

So on the one hand, I have this global knob that, if set to "yes", says I have to include <fee:balance> on error responses, and on the other hand no specification of an element in which to include <fee:balance> for error responses.  Were I to implement this spec as-written, I'd be forced to assume that the "yes" case is unimplementable and only support the "no"

variant, or try to come up with something on my own for how to do the error case.  I want to avoid making implementers face such a choice, as "come up with something on my own" has a history of being really bad for interoperability.

Hope this helps,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 31 Oct 2019 13:49:16 -0700

Hi Roger,

Thanks for the additional explanation.  I could ask where these conventions
are documented, but it seems more expedient to concede that I'm in the
rough and change my ballot position to Abstsain, to let the document get
published without further delay.

-Ben