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

[Benjamin Kaduk <[e-mail]>]

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

On Mon, Oct 28, 2019 at 03:44:11PM +0000, Roger D Carney wrote:
> 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 <[e-mail]>
> Sent: Wednesday, October 23, 2019 5:40 PM
> To: Roger D Carney <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-regext-epp-fees-18: (with DISCUSS and COMMENT)
> 
> 
> 
> Notice: This email is from an external sender.
> 
> 
> 
> 
> 
> 
> 
> On Fri, Oct 04, 2019 at 12:25:23PM -0700, Benjamin Kaduk wrote:
> 
> > 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
> 
> > > <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>
> 
> > > Sent: Monday, September 16, 2019 11:26 AM
> 
> > > To: The IESG <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>
> 
> > > Cc:
> 
> > > [e-mail]<mailto:draft-ietf-regext-epp-fee<mailto:[e-mail]%3cmailto:draft-ietf-regext-epp-fee>
> 
> > > [e-mail]<mailto:[e-mail]>>; James Gould
> 
> > > <[e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>>;
> 
> > > [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>;
> 
> > > [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>;
> 
> > > [e-mail]<mailto:[e-mail]<mailto:[e-mail]%3cmailto:[e-mail]>>
> 
> > > 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.
> 
> 
> 
> 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