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

[Thomas Corte <[e-mail]>]

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.

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

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


-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: [phone]
Martin-Schmeisser-Weg 9                       Fax: [phone]
D-44227 Dortmund                       E-Mail: [e-mail]
Germany