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. 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. 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. 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]”. 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. 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. 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. 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”. 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. 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”. 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. 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:image001.png@01D2BF6E.C0559E30] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Roger Carney <rcar...@godaddy.com> Date: Tuesday, April 25, 2017 at 5:40 PM To: "regext@ietf.org" <regext@ietf.org> 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:regext-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Tuesday, April 25, 2017 4:31 PM To: i-d-annou...@ietf.org Cc: regext@ietf.org 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 regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
