Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

["Gould, James" <[e-mail]>]

Jody,

My feedback is included inline below prefixed with “JG-“.

—

JG

[cid:[e-mail]24700]

James Gould
Distinguished Engineer
[e-mail]

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

VerisignInc.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of Jody Kolker <[e-mail]>
Date: Friday, April 28, 2017 at 3:41 PM
To: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Thanks James.

Comments in line below.


From: regext [mailto:[e-mail]] On Behalf Of Gould, James
Sent: Thursday, April 27, 2017 2:56 PM
To: Roger D Carney <[e-mail]>; [e-mail]
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

Roger,

Thanks for posting the updated draft and the draft looks very close to what was discussed in Chicago.  Below is my feedback to the latest version:


1.       Section 3.1 “Client Commands”

a.       It may be useful to include an enumerated list of commands that is extensible like what was done in draft-ietf-regext-change-poll, which includes an enumerated list of operations with one of the values being “custom” and with an optional “op” attribute to define the custom operation name.  This way the XML parser will validate the command names prior to hitting the business logic, except for the “custom” command that would need to be manually validated.

This section appears to be enumerated already but does need to have the “custom” command added.  Can you be provide an example of the enumeration?

JG – I mean defined as an enumerated list in the XSD, as in the following:

   <simpleType name="commandEnum">
     <restriction base="token">
       <enumeration value="create"/>
       <enumeration value="delete"/>
       <enumeration value="renew"/>
       <enumeration value="transfer"/>
       <enumeration value="restore"/>
       <enumeration value="custom"/>
     </restriction>
   </simpleType>

   <complexType name=”commandType”>
       …
      <attribute name=”name” type=”fee:commandEnum”/>
      <attribute name=”customName” type=”token”/>
      …
    </complexType>


In this case, the “Example <check> command” would be the same except a new custom command example could be added:

   C:         <fee:command name="create">
   C:           <fee:period unit="y">2</fee:period>
   C:         </fee:command>
   C:         <fee:command name="renew"/>
   C:         <fee:command name="transfer"/>
   C:         <fee:command name="restore"/>
   C:         <fee:command name="custom" customName=”sync”/>



2.       Section 5.1.1 “EPP <check> Command”

a.       The OPTOINAL <fee:period> element should be fully defined.  For example, what happens if the <fee:period> is not provided?  I assume that if the <fee:period> is not provided that the default period would be used.  The default period may be dependent on the command itself.  For example, a restore does not have a period and therefore there is no default.  Should the default period be defined by command in the protocol, or should it be up to server policy?  My thought is to leave it up to server policy, since that is what was done in EPP RFC 5732.

The <fee:period> is defined in 3.3 – should that text also be added to 5.1.1?
From the document:
The <fee:period> element is OPTIONAL in <check> commands: if omitted,the server MUST determine the fee(s) using a validity period of 1 year.  The <fee:period> element MUST be present in <check> responses.

 JG – You could provide a short description in 5.1.1 and then link to the full description in 3.3.  It may be worth updating 3.3 to make the default for the <create>, <renew>, and <transfer> command 1 year, but to leave the default for the remainder of the commands up to server policy.  For example, if command extensibility is supported, the default period for the custom “sync” command would be up to server policy.


b.       The OPTIONAL <fee:class> element should be fully defined.  What does providing the <fee:class> mean.  Is the <fee:class> a filter to indicate whether the domain name matches the specified classification?  If the <fee:class> does not match, is the fee returned as unavailable due to something like “mismatching class”?  Since classification is handled at the object level and not the command level, does it make sense to set it at the object level in the XML, like placing it at the level of the <fee:currency> and the <fee:command> elements instead of placing it under the <fee:command> element?  The same holds true for the check response extension.

I believe the <fee:class> should be removed from the check command request as it does not seem to have a purpose.  It should only be included in the response.

JG – I agree.


c.       I would not directly refer to the <domain:name> or the <domain:check> except as an example, since the fee extension could be applied to other billable EPP objects (e.g., email forwarding, defensive registration).  My recommendation is to be generic in stating something like “and a <fee:cd> for each element referenced in the check command, like for each <domain:name> element in RFC 5731 [RFC5731]”.  Similarly, I would change “A <fee:objID> element, which MUST match an element name from the client command, like the <domain:name> element in RFC 5731 [RFC5731]”.

Will review with Roger.


d.       I would update the text for the <fee:period> returned in the check response extension.  I would keep the text generic to return the period that was requested in the command extension, the default period if there is one for the command, or no period if the command is not associated with a period like with the “restore” command in RFC 3915 [RFC3915].  Since we can create new verbs in EPP like what was done with the “restore” command in RFC 3915, I recommend keeping the language in the extension as generic as possible to cover the full set of options for any type of command.

Will review with Roger.


e.       I recommend describing the <fee:fee>, <fee:credit>, <fee:class>, and <fee:reason> elements either directly with the element or via a reference to somewhere else within the draft.

Will review with Roger.


f.        The <check> response example is missing the “avail” attribute in the <fee:cd> elements when avail=”1”.  I realize that the default is “1” in the XML schema, so I would specify that there is a default value of “1” in the text and I would include examples of explicitly including the avail=”1” for clarity.

Agree.


g.       You may need to support the “lang” attribute for the <fee:reason> to be consistent with the other EPP RFCs.

h.       In the example, I don’t believe any <fee:cd> elements other than <fee:objID> and <fee:reason> would be returned when avail=”0”.  I recommend removing the <fee:period> from the example when avail=”0”.

Could this be left to server preference?

JG – I believe it’s best to clearly define what is expected server behavior for both cases.  If the fee information is not available for an object, it does not make any sense for the server to provide and the client to look for additional elements.


i.         I believe it is important to include text describing how a compliant server should handle non-standard fee objects in the check command when the fee extension is not passed.  It is best to return the non-standard fee object as unavailable in the check response.  If the client does not know the fee, then the create will fail downstream, so it’s best to address it upfront.

Agree – If the fee extension is not passed in the check command for a domain that is non standard pricing, the check command should return unavailable for backwards compatibility for registrars that will not be selling premium domains.  To these registrars these domains are not available to be registered.

3.       Section 5.1.1.1 “Server Handling of Elements”

a.       I believe the first element on the tiers of classes, it looks like it assumes that the avail flag is at the level of the <fee:command> element, but it is now at the level of <fee:cd>.  My recommendation is to define the <fee:class> at the object level, and if the <fee:class> does not match, return avail=”0” at the <fee:cd> level with a <fee:reason> “fee class mismatch”.

If the <fee:class> is removed from the request, this would not be an issue.  I recommend removing <fee:class> from the check request.

JG-Agreed


b.       The second element also assumes that the avail flag is at the <fee:command> level.  This element is not clear to me.  I believe in general if the <fee:class> is passed it must be validated as a supported classification and compared with the classification assigned to the object, and if the classification is invalid or there is a mismatch the fee should be returned as unavailable (avail=”0”) for the fee object with a reason.

Let’s remove <fee:class> from the check request.


c.       I’m not sure that it’s good for the server to ignore an element passed by the client.  If the client passes an invalid element, then it should return as unavailable with a reason.




—

JG

[cid:[e-mail]24700]

James Gould
Distinguished Engineer
[e-mail]

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

VerisignInc.com<http://verisigninc.com/>

From: regext <[e-mail]<mailto:[e-mail]>> on behalf of Roger Carney <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, April 25, 2017 at 5:40 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt


Good Afternoon,



Here is the update draft document. This should include all of the agreed upon changes from the Chicago meeting (biggest change was the simplification of the <check> call).



One topic that was discussed in Chicago (and not resolved) was on the concept of “premium names” and what is returned from the server if no fee extension was passed into the <check>. Many thought to be more “backwards compatible”/”user friendly”, especially for those registrars that do not and may not be participating in the allocation of “premium names”, that the server should respond as unavailable. Others expressed that if it is available then the server should respond available. Please share your thoughts on the list on this topic and if this draft should even try to account for this concept.



Please let me know if you have any questions.





Thanks

Roger





-----Original Message-----
From: regext [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Tuesday, April 25, 2017 4:31 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt





A New Internet-Draft is available from the on-line Internet-Drafts directories.

This draft is a work item of the Registration Protocols Extensions 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-03.txt

                Pages           : 33

                Date            : 2017-04-25



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

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



A diff from the previous version is available at:

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





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/



_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext