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. 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 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. 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). 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
