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

From: "Gould, James" <[email-masked]>
Date: Wed, 3 May 2017 20:15:05 +0000

Thomas,

My feedback is included below.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

On 5/2/17, 5:39 AM, "Thomas Corte" <[email-masked]> 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: [email-masked]

    Germany

---

From: Thomas Corte <[email-masked]>
Date: Thu, 4 May 2017 12:46:07 +0200

Hello James,

On 03/05/2017 22:15, Gould, James wrote:

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

Arguably, in a situation where many TLDs are now offering domains at
various pricing tiers (with no further policy requirements), general
availability is no longer just a matter of "domain
taken/reserved/valid?", but also of "how much is the registrant willing
to pay?".
>From that point of view, providing fee information in a <check> response
seems vital for enabling registrars to offer such domains to their customers.
But I agree that it's a matter of how broad the term "availability"
should be interpreted.

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

Agreed.

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

Another solution which I've never really liked, but it looks like that
ship has sailed.

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

Ok, so it would essentially morph the <info> command's semantics into
something slightly different, from, as the RFC says, "retrieve
information associated with a domain object" to "retrieve information
associated with potential domain objects". Acceptable, even though I'd
personally still consider this closer to the <check> command's
responsibility.

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

Ok, understood.

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

Sounds like a good solution to me, and schema-wise we already have in
place what we need for this, i.e. only the description text would need
the above clarifications.

Best regards,

Thomas