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

Michael Holloway <michael.holloway@comlaude.com> Wed, 18 February 2015 09:04 UTC

Return-Path: <michael.holloway@comlaude.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 9E4E71A6FFF for <eppext@ietfa.amsl.com>; Wed, 18 Feb 2015 01:04:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 9B_Fa5G1fmFr for <eppext@ietfa.amsl.com>; Wed, 18 Feb 2015 01:04:33 -0800 (PST)
Received: from smtp107.iad3a.emailsrvr.com (smtp107.iad3a.emailsrvr.com [173.203.187.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9691A00A9 for <eppext@ietf.org>; Wed, 18 Feb 2015 01:04:33 -0800 (PST)
Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6FA3D28042F for <eppext@ietf.org>; Wed, 18 Feb 2015 04:04:32 -0500 (EST)
X-SMTPDoctor-Processed: csmtpprox beta
Received: from smtp14.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp14.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6C525280487 for <eppext@ietf.org>; Wed, 18 Feb 2015 04:04:32 -0500 (EST)
Received: by smtp14.relay.iad3a.emailsrvr.com (Authenticated sender: m4bh-AT-comlaude.com) with ESMTPSA id B6F9C28042F for <eppext@ietf.org>; Wed, 18 Feb 2015 04:04:31 -0500 (EST)
X-Sender-Id: m4bh@comlaude.com
Received: from [192.168.1.10] (p578E6A76.dip0.t-ipconnect.de [87.142.106.118]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA) by 0.0.0.0:465 (trex/5.4.2); Wed, 18 Feb 2015 09:04:32 GMT
Message-ID: <54E4559E.4050109@comlaude.com>
Date: Wed, 18 Feb 2015 10:04:30 +0100
From: Michael Holloway <michael.holloway@comlaude.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: eppext@ietf.org
References: <20150217101609.7180.94307.idtracker@ietfa.amsl.com> <54E32A6A.2050905@centralnic.com> <CAKk34LSEW7Gr2RyA1z_-aM1ajeLwxkL+4v25PLg+_TUR_TeRqQ@mail.gmail.com>
In-Reply-To: <CAKk34LSEW7Gr2RyA1z_-aM1ajeLwxkL+4v25PLg+_TUR_TeRqQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010108050909040809020200"
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/-F3wzCq9ALy9KwTNQZy6ZAIpaFA>
Subject: Re: [eppext] Fwd: New Version Notification for draft-brown-epp-fees-04.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: <http://www.ietf.org/mail-archive/web/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: Wed, 18 Feb 2015 09:04:36 -0000

Ed, Good point.

The UnitedTLD is also used ZACR, while this extension is in use by 
CentralNIC, GMO, Charleston, Minds and Machines - albeit they are using 
varying versions. Ignoring the fact that the big 3 all have their their 
own alternatives (and 1 or 2 more), these two extensions already have a 
large coverage. UnitedTLD's extension is much simpler while this one is 
much more complex (due to registry input to Gavin indicating they want 
the flexibility).

I do not believe that any registry that has already implemented one or 
the other will switch, which means both of the extensions will continue 
to be used even if one were to take the lead.

So is there an argument to propose two standards for the same purpose or 
do we back the one that pushes in the interest of having a standard? Two 
standards are better than none which results in several alternative 
custom extensions, so I would back either or both if they are going down 
standards track.

Cheers,
Michael


*
Michael Holloway
Senior Systems Administrator**| Com Laude*
E: michael.holloway@comlaude.com <mailto:michael.holloway@comlaude.com>




On 02/18/2015 07:01 AM, Ed Pascoe wrote:
> While I think this extension is well written and valuable I do have to 
> question if a standards track is appropriate?
>
> The competing version of this is the UnitedTLD "Price Categories 
> Guide" 
> http://rightside.co/fileadmin/downloads/policies/Rightside_Price_Categories.pdf 
> which has not been formally published. However its in active use by 
> Rightside, Donuts and Domain Name Services (that I know of) meaning 
> that around 190 new TLDs are using it or about to do so.
>
> So the question is where do we go to from here? Do we try and get 
> Rightside to have the original author publish it to the EPP extension 
> registry or do we pretend it doesn't exist and ignore the significant 
> percentage of new TLDs using it?
>
>
> On Tue, Feb 17, 2015 at 1:47 PM, Gavin Brown 
> <gavin.brown@centralnic.com <mailto:gavin.brown@centralnic.com>> wrote:
>
>     I've just submitted a new version of the fee extension draft for your
>     review.
>
>     9.4. Changes from 03 to 04
>
>        1.  Changed Intended Status to Standards Track.
>
>        2.  As per suggestion from Michael Bauland, the <fee:period>
>     element
>            is no longer included in <check> and <info> responses for
>            "restore" commands.  It's still mandatory for all other
>     commands.
>
>        3.  Added summary of the attributes for the <fee:fee> element.
>
>        4.  Clarified that the "refundable" and "grace-period"
>     attributes of
>            the <fee> fee elements are dependant on each other and cannot
>            appear on their own.
>
>        5.  Removed the option of returning a 1001 response when the fee is
>            incorrect.
>
>        6.  Forbidden the inclusion of extension elements in transform
>            responses if no fee/credit has been assessed.
>
>        7.  Made the <fee:currency> element optional in transform commands.
>
>        8.  Amended XML Namespace section of IANA Considerations, added EPP
>            Extension Registry section.
>
>     10. TODO
>
>
>        (Note to RFC Editor: remove this section before publication as an
>        RFC.)
>
>        1.  Make the extension object-agnostic so it can be used with other
>            objects, not just vanilla domains.
>
>        2.  Change the <check> command so that availability data is not
>            returned.
>
>     -------- Forwarded Message --------
>     Subject: New Version Notification for draft-brown-epp-fees-04.txt
>     Date: Tue, 17 Feb 2015 02:16:09 -0800
>     From: internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
>     To: Gavin Brown <gavin.brown@centralnic.com
>     <mailto:gavin.brown@centralnic.com>>
>
>     A new version of I-D, draft-brown-epp-fees-04.txt
>     has been successfully submitted by Gavin Brown and posted to the
>     IETF repository.
>
>     Name:           draft-brown-epp-fees
>     Revision:       04
>     Title:          Registry Fee Extension for the Extensible
>     Provisioning Protocol
>     (EPP)
>     Document date:  2015-02-17
>     Group:          Individual Submission
>     Pages:          36
>     URL:
>     http://www.ietf.org/internet-drafts/draft-brown-epp-fees-04.txt
>     Status: https://datatracker.ietf.org/doc/draft-brown-epp-fees/
>     Htmlized: http://tools.ietf.org/html/draft-brown-epp-fees-04
>     Diff: http://www.ietf.org/rfcdiff?url2=draft-brown-epp-fees-04
>
>     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 <http://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 <mailto:EppExt@ietf.org>
>     https://www.ietf.org/mailman/listinfo/eppext
>
>
>
>
> _______________________________________________
> EppExt mailing list
> EppExt@ietf.org
> https://www.ietf.org/mailman/listinfo/eppext