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 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 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 element, and to
let avail on the 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
