Thomas,
My feedback is included below. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com <http://verisigninc.com/> On 5/2/17, 5:39 AM, "Thomas Corte" <thomas.co...@knipp.de> wrote: James, On 2017-04-28 22:55, Gould, James wrote: > Thomas, > > I’m sorry, I missed the existence of a reason under the command since I > thought the “avail” attribute and the reason element moved from the > command level to the object level. My main concern with providing a > highly feature rich fee extension to the domain check is ensuring that > the domain check continues to meet the performance requirements, and > that we don’t start down the path of creating extension upon extension > of the domain check that will transition it into a domain “everything” > command. True, that should be avoided. On the other hand, the currently defined functionality (even without a fast fail) IMO still closely relates to checking a domain's availability, in that it merely provides more information about the precise circumstances in which the domain is available (as long the correct fees or the correct launch phases are used), or why it is not available. JG – I don’t see how the fee information is tied to availability. The only case that has recently come up is returning a non-standard domain as unavailable when the fee extension is not passed. We’ve debated the extension of the check command / response, and I agreed to support the check command / extension; although we need to ensure that the fee extension does not become too heavyweight. As for the performance impact, I'm not overly concerned with that, especially since the server can avoid any fee-related efforts if the fee extension is not specified in the <fee:check> command. As long as a "plain" check command still completes fast enough to meet e.g. ICANN's gTLD SLAs, there should be no problem (otherwise, both options #1 and #2 are out of the question). I wouldn't expect ICANN's monitoring nodes to use the fee extension for their measurements. Also, the fast fail you're describing for option #1 wouldn't even save that much computing since, by the time the server determines that a certain launch phase isn't feasible for the domain/period/..., it will most likely already have checked some others and would only have to discard that information. I'd rather provide it to the registrar in that case, or at least put wording in the draft that allows the server to do so. Overall, there seems to be a JG – I agree that inclusion of the fee extension for the SLA monitors is highly unlikely. My main concern is extending the heaviest hit command in the registry independent of SLA monitors. Extending the check command / response should be the exception to the rule and should not be considered a general conduit for getting information in bulk. I see the importance of the fee information, so an exception is being made in this case. As a community we should not set this up as a future pattern of morphing the check command / response into a bulk info command / response. I'm not a fan of option #3 since the <domain:info> command IMO should not return anything but an "object does not exist" error when a non-existing domain is queries. JG – This would be the case if it were a true extension of the info command / response. What is proposed in option #3 is consistent with extending an empty domain update for the restore command in RFC 3915. In this case, if you see an info command with a fee extension, it is routed to a fee information handler that will return the fee information independent of the existence of the objects (e.g., domain). So I'd still prefer my original suggestion, i.e., to allow a "mixed" result (commands with fees and without) within a <cd> element, and to let avail on the <cd> element be "true" as long as at least one nested command contains fees, i.e. signals the name's availability. This is essentially your option #2, but without introducing a dedicated "fee check command form" (though I wouldn't be opposed of that; it's just that I'd like to see this draft getting into a usable status as soon as possible). JG – Option #2 is really no different from what you’re requesting. The main element of option #2 is in how it is described in the draft, but the XML schema and the makeup of the command and response are the same. The main difference is that you’re defining a fee check command and response that includes the availability information instead of the other way around (an availability check command that includes fee information). This makes the fee check a sibling of the availability check, which means that future availability check extensions don’t get automatically latched onto the fee check. Section 5.1.1. EPP <check> Command could read like the following if option #2 was taken: This extension defines a new command called the Fee Check Command that is used to determine whether the fee information is available and if so returns the fee information along with the availability check information. …, now include the following use cases in the response: 1. Return a 2306 error if the server policy does not support the <fee:currency> element value specified in the command. 2. Return avail=”0” in the <fee:cd> element for any object that does not have fee data with a <fee:reason> child element that describes the reason. 3. Return avail=”0” in the <fee:command> element for a command that does not have fee data with a <fee:reason> child element that describes the reason. The only time that avail=”0” would be returned for the <fee:cd> element is if there is an issue returning fee information for the object, like if the domain name is invalid. Issues with the commands would be handled at the command level via the <fee:command> avail attribute. Global errors like passing an invalid currency based on the server policy would be handled at the fee check command layer. Thoughts? Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
