Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-11.txt

From: [email-masked]
Date: Wed, 11 Apr 2018 13:24:11 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the IETF.

        Title           : Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
        Authors         : Roger Carney
                          Gavin Brown
                          Jothan Frakes
	Filename        : draft-ietf-regext-epp-fees-11.txt
	Pages           : 37
	Date            : 2018-04-11

Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for registry fees.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-fees/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-epp-fees-11
https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-fees-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 13 Apr 2018 08:52:10 +0200

> https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-fees-11

I see that this includes some of my latest comments
(but not all of them, for example required attributes still
do not have use="required" in the schema, and I have not seen
an explanation about that), so thanks for taking them into account.

However I still think there is a big problem for the "standard" attribute.

For me even this new version does not define it really.

Where it appears it says now:
 The <fee:command> element(s) contain(s) a "name" attribute (see
   Section 3.1), an OPTIONAL "standard" attribute with a default value
   of false (0) (see section 3.7), an OPTIONAL "phase" attribute, and an
   OPTIONAL "subphase" attribute (see Section 3.8).  The <fee:command>
   element(s) MAY have the following child elements:

so it references the section 3.7, which is new.

But the problem is that this section only speaks about classes
and the <fee:class> element in responses. There is again nothing there about
the "standard" attribute of a <fee:command> in requests.

There is specifically a need to explain things in relation to last line
of this section. What happens/What does it mean/Is it allowed or not
when fee:class=standard but standard=false
or when fee:class=premium but standard=true?

Especially since both elements are optional.

I believe that this lack of explanations can cause major interoperability
problems, even more so because this attribute was added very late in the draft lifecycle.

Maybe people in favor (I am not) of this attribute
should chime in and provide some useful text to add in the specification.

I do not think it can pass LC without this fixed.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 13 Apr 2018 13:09:11 +0000

I made the proposal for the optional "standard" attribute with the list message (https://mailarchive.ietf.org/arch/msg/regext/7E6X5xCdt3DhqL7p7CFupm9bAAY/?qid=e4f712bc8e70e4d0a458971928924651) on the thread with Pat Moroney.  The description in the proposal was " Add a new optional “standard” boolean attribute to the <fee:command> element, with the default value of “0” (or “false”), that indicates whether the fees for the command and period matches the “standard” classification fees for the command and period.".  To address your concern, how about revising the description to the following:

..., an OPTIONAL "standard" attribute with a default value of false (0) that indicates whether the fees for the command and period matches the "standard" classification fees (see section 3.7), ...	

In hindsight this attribute should have been exclusively included in the <fee:command> of the check response (XSD commandDataType instead of base commandType) since I believe it's only provided by the server, but that would require a schema change.  The definition of the attribute may have to be moved as well to the check response command description.  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 
On 4/13/18, 2:52 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    

    

    -- 
      Patrick Mevzek
      [email-masked]
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 14 Apr 2018 04:30:19 +0200

On Fri, Apr 13, 2018, at 15:09, Gould, James wrote:
> I made the proposal for the optional "standard" attribute with the list 
> message 
> (https://mailarchive.ietf.org/arch/msg/regext/7E6X5xCdt3DhqL7p7CFupm9bAAY/?qid=e4f712bc8e70e4d0a458971928924651) 
> on the thread with Pat Moroney.  

Yes, but that was not included in the document and noone replied to your
request for thoughts.

> The description in the proposal was " 
> Add a new optional “standard” boolean attribute to the <fee:command> 
> element, with the default value of “0” (or “false”), that indicates 
> whether the fees for the command and period matches the “standard” 
> classification fees for the command and period.".  To address your 
> concern, how about revising the description to the following:
> 
> ..., an OPTIONAL "standard" attribute with a default value of false (0) 
> that indicates whether the fees for the command and period matches the 
> "standard" classification fees (see section 3.7), ...	

Maybe it is just me, but I still think that for someone new (or even not so new) this is confusing.

If client stays standard=false does that mean that the reply can not have class=standard?
On the opposite with standard=true, should? must? the reply have a class=standard reply?

This all seems under specified to me.

> In hindsight this attribute should have been exclusively included in the 
> <fee:command> of the check response (XSD commandDataType instead of base 
> commandType) since I believe it's only provided by the server, but that 
> would require a schema change.  The definition of the attribute may have 
> to be moved as well to the check response command description.  

The fact that there is a need to change the schema at the last time clearly
shows to me that something is half-baked and should not be shipped as is.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 16 Apr 2018 14:19:05 +0000

Patrick,

There were plenty of responses on the thread to the request for thoughts.  See Pat Moroney's response that is next in the thread (https://mailarchive.ietf.org/arch/msg/regext/ftCDAgAQMyXDPPbvKYN3px5cG_Y).  

Do you support the inclusion of the "standard" attribute and revising the draft to place it's use and description in the check response only?  There is no need for the client to specify the "standard" attribute in the check command.  

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 
On 4/13/18, 10:30 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    
    -- 
      Patrick Mevzek
      [email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 18 Apr 2018 08:28:39 +0200

On Mon, Apr 16, 2018, at 16:19, Gould, James wrote:
> There were plenty of responses on the thread to the request for 
> thoughts.  See Pat Moroney's response that is next in the thread 
> (https://mailarchive.ietf.org/arch/msg/regext/ftCDAgAQMyXDPPbvKYN3px5cG_Y).  

Sorry I trusted the web interface of the archive, and it does not display threads nicely. I should have trusted by own email client instead.
 
> Do you support the inclusion of the "standard" attribute

I do not and said so in the past:
https://mailarchive.ietf.org/arch/msg/regext/HY1aRTOvT0om6IL4vP6EgBoQaT4/?qid=46a1b6e6f1f01ab50b68a5f44c48f5cf

I think its addition only create more complexity without a real use case.

The fact that it has no clear definition in the current draft seem to prove that.

> There is no need for the client to specify the "standard" attribute in 
> the check command.  

It is the way it is currently defined.

The proponents of having it in the client request should maybe say something.

But I see no more reasons to have it in a reply: class=standard already
conveys the meaning.

In short, if someone cares for this, in the client request and/or in server reply, they should provide specific and detailed definition in the document.
If there is noone willing to define this element clearly in the specification, I think it means that it need to be removed altogether.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Apr 2018 17:04:58 +0000

In re-reviewing the mailing list thread, as the document shepherd I'm unsure if there is consensus on this.  The two items discussed on the list include:

  1.  Location of the <fee:class> element at the object-level (<fee:cd>) or at the command-level (<fee:command>).  Draft draft-ietf-regext-epp-fees-09 moved the <fee:class> from under the <fee:command> element to the <fee:cd> element.
  2.  Support for the optional “standard” attribute in the <fee:command> element to indicate that the command matches the standard fee, which is independent to the object-level <fee:class> value.  Draft draft-ietf-regext-epp-fees-09 added support for this attribute; although it was added for the check command (commandType) instead of just the check response (commandDataType).

This topic started back at IETF-100 and was discussed on the list starting with Roger Carney's message (https://mailarchive.ietf.org/arch/msg/regext/E_oE3luLvB6B2c082-0PHvYZP9o).

I ask the chairs to take a look at this to define the next step.

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/18/18, 2:28 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    >     > I made the proposal for the optional "standard" attribute with the

    > list

    conveys the meaning.

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]

---

From: "James Galvin" <[email-masked]>
Date: Fri, 20 Apr 2018 09:55:26 -0400

I want to acknowledge that the chairs have seen your request to define 
the next step.

We are reviewing the issue and will propose something as soon as we can.

Thanks,

Antoin and Jim

On 18 Apr 2018, at 13:04, Gould, James wrote:

> In re-reviewing the mailing list thread, as the document shepherd I'm 
> unsure if there is consensus on this.  The two items discussed on the 
> list include:
>
>
>
>   1.  Location of the <fee:class> element at the object-level 
> (<fee:cd>) or at the command-level (<fee:command>).  Draft 
> draft-ietf-regext-epp-fees-09 moved the <fee:class> from under the 
> <fee:command> element to the <fee:cd> element.
>   2.  Support for the optional “standard” attribute in the 
> <fee:command> element to indicate that the command matches the 
> standard fee, which is independent to the object-level <fee:class> 
> value.  Draft draft-ietf-regext-epp-fees-09 added support for this 
> attribute; although it was added for the check command (commandType) 
> instead of just the check response (commandDataType).
>
>
> This topic started back at IETF-100 and was discussed on the list 
> starting with Roger Carney's message 
> (https://mailarchive.ietf.org/arch/msg/regext/E_oE3luLvB6B2c082-0PHvYZP9o).
>
> On 4/18/18, 2:28 AM, "regext on behalf of Patrick Mevzek" 
> <[email-masked] on behalf of [email-masked]> wrote:
>
>
>
>     Sorry I trusted the web interface of the archive, and it does not 
> display threads nicely. I should have trusted by own email client 
> instead.
>
>
>
>     In short, if someone cares for this, in the client request and/or 
> in server reply, they should provide specific and detailed definition 
> in the document.
>
>     If there is noone willing to define this element clearly in the 
> specification, I think it means that it need to be removed altogether.
>
>
>
>     --
>
>       Patrick Mevzek
>
>       [email-masked]
>
>
>