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

From: Jody Kolker <[email-masked]>
Date: Mon, 1 May 2017 16:25:07 +0000

I am good with option #1; the response returns “avail=0” if one of the commands fails.  However, the command could either return the reason code for the one failing command, or any commands that had been checked with their reason codes.  If all commands were considered invalid, would the response return all the commands or only the first command that failed?  James can you provide an example of a fast fail response?

Jody.

From: regext [mailto:[email-masked]] On Behalf Of Rubens Kuhl
Sent: Friday, April 28, 2017 4:14 PM
To: Gould, James <[email-masked]>
Cc: Roger D Carney <[email-masked]>; Thomas Corte <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

James,

I understand your concern with option #1, but I think option #3 goes into a different set of issues where we mix the domain sales pipeline with domain management activities, for which domain:info is commonly used.
I'm neutral between option #1 and option #2, but while both work me, I would really like to know which option has more chance of being implemented by registrars; and if they favor either #1 or #2, I would favor that as well.

Rubens

Em 28 de abr de 2017, à(s) 17:55:000, Gould, James <[email-masked]<mailto:[email-masked]>> escreveu:

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.  I view the options for providing fee information in the fee extension as follows:

1.       Extend the check command, as defined in draft-ietf-regext-epp-fees-03, with object level availability and unavailability reasons.
a.       Your use case would be handled by returning <cd avail=”0”> for example.tld with no commands and with the reason “domain name not available as a promotion name”.  The server would fast fail the fee extension for the domain example.tld.  This keeps the check command lighter weight, but it is still much heavier weight than a standard check command.
2.       Extend the check command by defining a new command called the “fee check command”.
a.       The “fee check command” can include the availability along with the fee information, but it is treated differently from a standard check command and future extensions of the check command would not automatically apply to the “fee check command”.  This change is strictly associated with the wording in the draft like defining the “claims check command” in section 3.1.1 of draft-ietf-regext-launchphase.  In this case, we can provide for a more robust set of features targeted to the fee, which could include extension level availability (currency is invalid or some other crosscutting attribute), object level availability (domain name is invalid or class is invalid), and command level availability (command is invalid or command not applicable to domain).  This removes the concern over the performance of the check command, since this is a fee check command and it does not encourage future heavyweight extensions.
3.       Implement #1 and extend the info command by defining a new command called the “fee info command” that supports getting fee information for existing and non-existing objects, but it does not return the standard info response.
a.       The fee info command could include a more robust set of features targeted to the fee, which could include extension level availability (currency is invalid or some other crosscutting attribute), object level availability (domain name is invalid or class is invalid), and command level availability (command is invalid or command not applicable to domain).  This supports getting more complex fee information without making the check command too complex.  An example of a similar info command extension is defined with the Related Domain Info Command in our Related Domain Extension (http://www.verisign.com/assets/epp-sdk/verisign_epp-extension_related-domain_v00.html#relatedInfoForm ).

Thoughts?

—
JG

James Gould
Distinguished Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

On 4/28/17, 10:09 AM, "Thomas Corte" <[email-masked]<mailto:[email-masked]>> wrote:

    James,

    On 28/04/2017 15:27, Gould, James wrote:

    > Thomas,
    >
    > There are three classifications of errors that can occur with the fee
    > extension to the check command:
    >
    > 1.       Syntax error – This should result in an error for the entire
    > check command.
    >
    > 2.       Object (domain) name error (incorrect domain name, reserved
    > domain name, blocked domain name, etc.) – This should result in returning
    > avail=”0” for the associated fee:cd element for the object in the response.

    Agreed.

    >  My recommendation
    > is to fast fail the processing of the fee information and return back
    > avail=”0” for each of the objects in the response with an appropriate
    > reason like “Invalid currency XXX”, “Invalid command XXX”, or “Invalid
    > command XXX period YYY”.  I don’t believe that it will help to attempt to
    > put a higher level avail attribute and reason for the entire fee check
    > response extension, since the client would be expecting a fee result for
    > each object in the check command on a successful response.  The check
    > command should not fail based on a data issue, so I would apply that same
    > approach with the fee extension to the check command.
    >
    > a.       Since we’re extending the check command and response, I don’t
    > believe that the processing should flag errors below the object level.
    > This means that if one command is valid and another command is invalid,
    > the fee information is not available for the object.  The server will
    > fast fail the processing of the fee extension in the event of a failure
    > to one command, class, period, phase, subphase, or currency.  If there is
    > an expectation that the server should not fast fail, then we should
    > consider adding or moving the fee extension to the info command and
    > response.

    Agreed, even if the response would in this case not really reflect the
    server's internal fast failure, since it would still return the same
    error message for each checked object. But I can live with that.

    The question remains how to respond in situations where, for the same
    name, some <command> report assessed fees (since the name is e.g. OK for
    a certain phase or period), but some others have a <reason> indicating an
    error.
    Which value should the <cd> element's "attribute" have? Here's the
    example from yesterday's e-mail again:

     <chkData xmlns="urn:ietf:params:xml:ns:fee-0.17">
            <currency>EUR</currency>
            <cd avail="???">
              <objID>example.tld</objID>
              <command name="create" phase="open">
                <period unit="y">1</period>
                <fee applied="immediate"
                  description="domain creation in phase 'open'"
    grace-period="PT1M" refundable="true">60.00</fee>
              </command>
              <command name="create" phase="custom" subphase="defensive">
                <period unit="y">1</period>
                <fee applied="immediate"
                  description="domain creation in phase
    'defensive-registration'"
                  grace-period="PT1M" refundable="true">30.00</fee>
              </command>
              <command name="create" phase="custom" subphase="promotion">
                <reason>domain name not available as a promotion name</reason>
              </command>
            </cd>
          </chkData>

    My suggestion would be to always include all <command> results in the
    <cd> element (whether they have fees or reason), and to have <cd
    avail="true"> as long as at least one <command> does not have a <reason>
    indicating an error. I.e., only if all the <command> elements in the
    response contain a reason indicating an error, the <cd> element should
    indicate the non-availability of fees.

    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]<mailto:[email-masked]>
    Germany

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Mon, 1 May 2017 18:30:42 +0000

Rubens,

Just to clarify option #3 is not a domain info but a fee info, so there should be no issue with domain management activities.  By extending an info command (domain, email forward, defensive registration, or any billable object), to get the fee information and defining a new command, there is more flexibility with providing more fee information for an existing or non-existing object.

If we can’t keep the fee availability at the object level with fast fail in option #1, then my preference would to option #2 to meet the functional needs without having to deal with the performance concerns to the availability check, and without encouraging additional heavyweight extensions being latched onto the same availability check command.  Option #3 would be needed only if we want to keep the check command lighter as defined in option #1 but still have a need for more complete fee information.

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

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

From: Rubens Kuhl <[email-masked]>
Date: Friday, April 28, 2017 at 5:14 PM
To: James Gould <[email-masked]>
Cc: Thomas Corte <[email-masked]>, Roger Carney <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-epp-fees-03.txt

James,

Rubens

Thomas,

Thoughts?

—
JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

    James,

    Agreed.

    Thoughts?

    Best regards,

    Thomas

---

From: Thomas Corte <[email-masked]>
Date: Tue, 2 May 2017 11:39:31 +0200

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

D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: Thomas Corte <[email-masked]>
Date: Tue, 2 May 2017 14:12:07 +0200

Hello,

> so. Overall, there seems to be a

Meant to write: Overall, there seems to be a high demand among
registrars for conveniently obtain comprehensive information about how
exactly a certain domain name may be registered, and the <fee:check>
command (as currently defined) seems very suited for that purpose.

Best regards,

Thomas