Re: [eppext] New Version Notification for draft-brown-epp-fees-06.txt

Pat Moroney <pmoroney@name.com> Fri, 04 December 2015 20:20 UTC

Return-Path: <pmoroney@name.com>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1AC1A016A for <eppext@ietfa.amsl.com>; Fri, 4 Dec 2015 12:20:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAzuYqiRJClb for <eppext@ietfa.amsl.com>; Fri, 4 Dec 2015 12:20:35 -0800 (PST)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9F71A008A for <eppext@ietf.org>; Fri, 4 Dec 2015 12:20:35 -0800 (PST)
Received: by ykdv3 with SMTP id v3so137397320ykd.0 for <eppext@ietf.org>; Fri, 04 Dec 2015 12:20:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=name-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=1Z5ssyZWn7yk0PW8X1dUMrl0WhxLaldCQUUCri6Myn8=; b=kBxea7tfeDW9LlkOg0M18LwPK+1YKE3m/oVO9gOcdHBQDQB51I7LU+bSTL9JfBy9nh GIcTidq2mol04sIFWVHS+wysyfxGgM37XODNb8DF3bxhgPXBgUP1jZ5tT5Lo3ZGugKR9 gs6otJJgkBtC3POUhDASIe9LLmB3so8NFiKW09NNccvxUWQZNxzL31shAW6/EtTwKwmd mX578dOTrVMaXRGx6cdYnjegAP3JlCASKwW6R1zLfoqWe5iFikfwyNtDYqHl2HEcVXyI vo49qE/njkipyBQrq1Txrr3D6G+e4wrTsxr688fYx9+AgFv5LzVdUilM+BDQl5U+vBtg 7mHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=1Z5ssyZWn7yk0PW8X1dUMrl0WhxLaldCQUUCri6Myn8=; b=QDWhZONNT5y2zed0FExMB0jM5ZNdRSEu8b8ZkgqVsJMPsZOjS3Q8zPsh28EkxYLZsw wB88PPq2opLGShuXbS5nvAvukkS9l8v3l1rJJHrrMfcdKR/yWzsIv041I1SmRrinJkTW H3ypYUGphJ6VDsA8dM46pUJL9ODPPzeTRoObIUhQf6XMmPUX2tLckzSBwKW62NloV6yr VtXoL4dCg0iI/bEiTfV5BPm1p5376/UIgFeULNRYXHcZXkwNcR2jJVMWkP2mrGhHYSxb ulAqvAcUY//SV/u+csdvVp1fBKzpwhJZqMRmiCPUZs5v5O47jWQn9iWo1VvdWQFUf1es ur9g==
X-Gm-Message-State: ALoCoQkT6wtvJ2VUM1cc8WwlbBvDGrrQv9QcosPG+8fXYJAxgio3WqMMS5rTM+157CnHnTCxJgGc
X-Received: by 10.13.200.134 with SMTP id k128mr12610603ywd.62.1449260434545; Fri, 04 Dec 2015 12:20:34 -0800 (PST)
MIME-Version: 1.0
References: <BY2PR0201MB0773743330736FD94E5F4A1CB10C0@BY2PR0201MB0773.namprd02.prod.outlook.com> <CA+GUe4-CGPWycDWUWPg1UE5HRpQUjq_vZsTH_kgXBnZ6QEzx7Q@mail.gmail.com> <D79FEB2C-5633-478F-80E6-E88E04FD6AB6@verisign.com>
In-Reply-To: <D79FEB2C-5633-478F-80E6-E88E04FD6AB6@verisign.com>
From: Pat Moroney <pmoroney@name.com>
Date: Fri, 04 Dec 2015 20:20:24 +0000
Message-ID: <CA+GUe49Mv2Gf3oENN3W0cSh49ynbfPeuVpPtJC5zMB_T6c_SAg@mail.gmail.com>
To: "Gould, James" <JGould@verisign.com>
Content-Type: multipart/related; boundary="001a114d3a1a63eeec0526183dc4"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/y65D-SqqR4BSd7Bfc6V4hzPu4es>
Cc: Roger D Carney <rcarney@godaddy.com>, "eppext@ietf.org" <eppext@ietf.org>
Subject: Re: [eppext] New Version Notification for draft-brown-epp-fees-06.txt
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Dec 2015 20:20:40 -0000

James,

The pragmatist version is of course favorable to me, but the ability to ask
for fees relating to multiple commands and/or phases is incredibly useful.
Without that ability we would still have to send multiple commands since we
also request the fees for renewals as well as registrations when we perform
a check. This allows us to provide pricing for purchasing and give our
customers an idea of the renewal pricing that they will see next year.
Multiple phases is also useful that way we can calculate the price for
pre-registrations and pre-landrush while in the sunrise phase with only one
command.

So removing the <fee:objID> objects and having a <fee:period> and one or
more <fee:command> and optionally many <fee:period> elements that apply to
the list of objects referenced in the check command. The response format
can stay the same. Would that be your pragmatic suggestion?

Thanks,
-Pat

On Fri, Dec 4, 2015 at 12:11 PM Gould, James <JGould@verisign.com> wrote:

> Pat & Roger,
>
> Let me clarify from two different perspectives:
>
> Idealist:
> The fee information really doesn’t follow the semantics of a check, but
> follows the semantics of an info.  The check command is setup as a
> container of boolean checks of the existence or availability of something
> (domain, claim, contact identifier, etc.).  The info command provides the
> query information for general information.  The fee extension is not asking
> for the existence or availability of something, but is asking for fee
> information given query inputs.  The query inputs may be invalid, so one of
> my questions is what should the server return for each of the invalid
> inputs (objID, objURI, objID, element, currency, command, and period)?  The
> check command should be simple and fast, where extending it with additional
> query or separate check information runs the risk of making it complex and
> slow.
>
> Pragmatist:
> If a fee is needed for every domain check, then we need a mechanism to
> support fee information as an extension to check.  To keep it a true
> extension, the only elements needed in the <fee:check> element should be
> <fee:currency>, <fee:command>, and <fee:period> that apply across all of
> the check identifiers (<domain:name>) included under the check command
> (<domain:check>).  This would result in a check response including a
> <fee:chkData> element that matches what is currently defined
> in draft-brown-epp-fees-06, except the <fee:objID> elements would always
> correspond to a response identifier (<domain:name>).  If there is invalid
> input provided with <fee:currency>, <fee:command>, or <fee:period>, the
> check command should fail with a specified EPP error code (my guess is
> 2306, since invalid input would be based on server policy).
>
> I’m assuming that the pragmatist is favorable over the idealist, but the
> idealist in me has a real concern of overloading the check command /
> response as a pattern to combine commands / responses.
>
> —
>
>
> JG
>
>
>
>
>
> *James Gould *Distinguished Engineer
> jgould@Verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> VerisignInc.com
>
> On Dec 4, 2015, at 11:29 AM, Pat Moroney <pmoroney@name.com> wrote:
>
> Hi all,
>
> I have to agree with Roger. The vast majority of check commands that we
> send are triggered by a customer searching on our website. To create the
> search results we need both the availability and the fee information in
> order to calculate the pricing. We can currently get that with one check
> command, but if it is split up our command volume will almost double.
>
> Thanks,
> -Pat
>
> On Fri, Dec 4, 2015 at 9:20 AM Roger D Carney <rcarney@godaddy.com> wrote:
>
>> Good Morning,
>>
>>
>>
>> Interesting idea Jim. Though not completely disagreeing with your premise
>> that the check and fee have different purposes, let me play devil’s
>> advocate here with some knowledge on the separate claims check in mind as
>> well. Different individual purposes maybe but when looking at the varied
>> data flow scenarios (how is this data used and presented to the end
>> customer), I believe most clients would see the purposes aligned well.
>>
>>
>>
>> I have heard from many people with the same question about claims: “Why
>> do we have to make two calls to see if a domain has a claim associated to
>> it, can’t they just tell us in the check?”
>>
>>
>>
>> I am guessing the same question will come up if it is a separate call for
>> fee information as well. People may make the argument that the additional
>> claims check is only needed for a specific period of time (except for those
>> doing indefinite claims). I think everyone would agree this same argument
>> does not apply for fees and as we see more and more varied wholesale models
>> I think an integrated call is more natural and becomes more necessary.
>>
>>
>>
>> Again, as these concepts align well from a flow perspective and as the
>> probability of expanding wholesaling models increases, I believe most
>> clients would prefer (demand) one call over multiple calls.
>>
>>
>>
>>
>>
>> Thanks
>>
>> Roger
>>
>>
>>
>>
>>
>> *From:* EppExt [mailto:eppext-bounces@ietf.org] *On Behalf Of *Gould,
>> James
>> *Sent:* Friday, December 04, 2015 7:37 AM
>> *To:* Gavin Brown
>> *Cc:* eppext@ietf.org
>> *Subject:* Re: [eppext] New Version Notification for
>> draft-brown-epp-fees-06.txt
>>
>>
>>
>> Gavin,
>>
>>
>>
>> In reviewing draft-brown-epp-fees-06, I have the following feedback:
>>
>>
>>
>>    1. The fee check extension is really not a good fit for extension of
>>    the available check.  They have different purposes and there is really no
>>    relationship between the two, where the availability check can include a
>>    completely different set of domain names from getting the fee extension.
>>    My recommendation is to separate the two and define the fee check as a new
>>    verb similar to the claims check in draft-ietf-eppext-launchphase.  Another
>>    option is truly extend the object identifiers (e.g. domain:names) in the
>>    check command with a set of fee attributes to get the fee information for.
>>    Have the extension only specify the command and the optional currency and
>>    fee that applies to all of the names in the availability check command.
>>    The response would include the same list of object identifiers in the
>>    extension, but it would be a one-to-one relationship.  In this way there is
>>    no need for the “objURI” attribute, the <fee:objID> element, and
>>    <fee:objID> “element” attribute in the check command, since the object and
>>    identifying element is already defined by the availability check object
>>    that is being extended.
>>    2. What should be returned when the client passes invalid data in the
>>    check command for the the “objURI” attribute (e.g. “urn:made:up:uri”), the
>>    <fee:objID> element (e.g. invalid domain name), the “element” attribute of
>>    <fee:objID> (e.g. “madeup”), the <fee:currency> element (e.g. “MUP”), and
>>    the <fee:period> element (e.g. “99" when max is “10”)?  An invalid
>>    <fee:command> is covered by not returning the fee information, but it’s
>>    unclear whether the server should return an error or not return the fee
>>    information for other invalid data.  To follow the semantics of a check
>>    command and response, my recommendation is to add an “avail” attribute to
>>    either <fee:cd> or <fee:objID> to explicitly indicate that the fee
>>    information is available along with an optional <fee:reason> to indicate
>>    the reason that the fee information is not available.  The reason the fee
>>    information is not available for a particular object could be due to the
>>    passing of invalid input in the check command <fee:object> element.  If you
>>    went with a single set of fee elements in the check command that is applied
>>    to all of the object identifiers in the availability check, then an invalid
>>    fee element could result in a failure of the check command itself instead
>>    of being an error (e.g. not available) on a per domain basis.
>>    3. Since the check response supports returning a “0.00” value to
>>    indicate no fee, doesn’t make sense to do the same with all transform
>>    command responses?
>>
>>
>>
>>
>>
>> —
>>
>>
>>
>> JG
>>
>>
>>
>>
>>
>> *James Gould *Distinguished Engineer
>> jgould@Verisign.com <http://jgould@verisign.com/>
>>
>> 703-948-3271
>> 12061 Bluemont Way
>> Reston, VA 20190
>>
>> VerisignInc.com <http://verisigninc.com/>
>>
>>
>>
>> On Nov 4, 2015, at 5:58 PM, Gavin Brown <gavin.brown@centralnic.com>
>> wrote:
>>
>>
>>
>> Changes from 05 to 06:
>>
>>   1.  The specification is now object-agnostic, but works with RFC5731
>>       [RFC5731] domains by default.
>>
>>   2.  Renamed the <fee:domain> element to <fee:object>.  Added the
>>       "objURI" attribute.
>>
>>   3.  Removed the default value for the "refundable" attribute of
>>       <fee:fee> elements, and added text about how clients should
>>       handle such cases.  Added similar text to the documentation of
>>       the "grace-period" attribute.
>>
>>   4.  Removed references to the defunct <info> command syntax.
>>
>>   5.  "MUST" requirements regarding documentation have been changed to
>>       "must".
>>
>>   6.  Created separate "Correlation between Refundability and Grace
>>       Periods" section describing how the "refundable" and "grace-
>>       period" attributes work together.
>>
>> Feedback welcome as always!
>>
>> -------- Forwarded Message --------
>> Subject: New Version Notification for draft-brown-epp-fees-06.txt
>> Date: Wed, 04 Nov 2015 14:52:30 -0800
>> From: internet-drafts@ietf.org
>> To: Gavin Brown <gavin.brown@centralnic.com>, Jothan Frakes
>> <jothan@jothan.com>
>>
>>
>> A new version of I-D, draft-brown-epp-fees-06.txt
>> has been successfully submitted by Gavin Brown and posted to the
>> IETF repository.
>>
>> Name: draft-brown-epp-fees
>> Revision: 06
>> Title: Registry Fee Extension for the Extensible Provisioning Protocol
>> (EPP)
>> Document date: 2015-11-04
>> Group: Individual Submission
>> Pages: 36
>> URL:
>> https://www.ietf.org/internet-drafts/draft-brown-epp-fees-06.txt
>> Status:         https://datatracker.ietf.org/doc/draft-brown-epp-fees/
>> Htmlized:       https://tools.ietf.org/html/draft-brown-epp-fees-06
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-06
>>
>> Abstract:
>>   This document describes an Extensible Provisioning Protocol (EPP)
>>   extension mapping for registry fees.
>>
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>> --
>> Gavin Brown
>> Chief Technology Officer
>> CentralNic Group plc (LSE:CNIC)
>> Innovative, Reliable and Flexible Registry Services
>> for ccTLD, gTLD and private domain name registries
>> https://www.centralnic.com/
>>
>> CentralNic Group plc is a company registered in England and Wales with
>> company number 8576358. Registered Offices: 35-39 Moorgate, London,
>> EC2R 6AR.
>>
>>
>>
>> _______________________________________________
>> EppExt mailing list
>> EppExt@ietf.org
>> https://www.ietf.org/mailman/listinfo/eppext
>>
>>
>> _______________________________________________
>> EppExt mailing list
>> EppExt@ietf.org
>> https://www.ietf.org/mailman/listinfo/eppext
>>
> --
> -Pat Moroney
> Sr. Software Engineer
> Name.com
> http://www.youtube.com/watch?v=V1GKGXXF12c
> 720-663-0025
>
> <image001.png><image001.png>
> _______________________________________________
>
>
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext
>
> --
-Pat Moroney
Sr. Software Engineer
Name.com
http://www.youtube.com/watch?v=V1GKGXXF12c
720-663-0025