On Tue, Oct 01, 2019 at 02:41:20PM +0000, Roger D Carney wrote:
> 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
> <nore...@ietf.org<mailto:nore...@ietf.org>>
> Sent: Monday, September 16, 2019 11:26 AM
> To: The IESG <i...@ietf.org<mailto:i...@ietf.org>>
> Cc:
> draft-ietf-regext-epp-f...@ietf.org<mailto:draft-ietf-regext-epp-f...@ietf.org>;
> James Gould <jgo...@verisign.com<mailto:jgo...@verisign.com>>;
> regext-cha...@ietf.org<mailto:regext-cha...@ietf.org>;
> jgo...@verisign.com<mailto:jgo...@verisign.com>;
> regext@ietf.org<mailto:regext@ietf.org>
> 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.
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.
>
>
>
>
> ----------------------------------------------------------------------
>
> 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.
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.
>
>
> 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.”
Thanks!
>
> 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).”
That matches what I thought the meaning was and doesn't make me confused;
thanks!
>
>
> 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…”
Clearly. But that's not what the quoted text says, so I assume there is a
text change queued up.
>
>
> 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.
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
