Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Thu, 12 February 2015 01:39 UTC

Return-Path: <alexander.mayrhofer@nic.at>
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 D8FA91A89F6 for <eppext@ietfa.amsl.com>; Wed, 11 Feb 2015 17:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.741
X-Spam-Level:
X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 MJDU-H5UXehS for <eppext@ietfa.amsl.com>; Wed, 11 Feb 2015 17:39:37 -0800 (PST)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685C21A89B5 for <eppext@ietf.org>; Wed, 11 Feb 2015 17:39:36 -0800 (PST)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Thu, 12 Feb 2015 02:39:30 +0100
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Thu, 12 Feb 2015 02:39:25 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
Thread-Index: AdBCEn+vvcyzjjByRt6JTgZTR3aSZAEUMAKQ
Date: Thu, 12 Feb 2015 01:39:24 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE0754674EED8@NICS-EXCH2.sbg.nic.at>
References: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49F3C5DD@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.3.37]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/jQLv8FHzoorb6kRa2mFfuj6FgNA>
Subject: Re: [eppext] Extension Registration Request: Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
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: Thu, 12 Feb 2015 01:39:39 -0000

All,

> I have no issue with the extension itself. Given that this request refers to an
> existing Internet-Draft document, I believe it would be more appropriate for
> the document to include an IANA Considerations section that includes a
> request to register the extension if the document becomes an RFC. My
> recommendation to IANA would be to hold off on processing the request
> until the document is either submitted to and approved by the IESG or it is
> published outside the IETF process.

I do agree with Scott that the registration details should go into the IANA considerations section of the document, using the template from RFC7451. Basically, i also agree that the registration should be held off until publication, if the intended goal of the document is publication as an RFC. 

I understand the document describes one of the candidate extensions that could be adopted as WG items once EPPEXT recharters. My recommendation above is based on this assumption. However, i'm slightly concerned about the current level of progress of the rechartering / scope work, and hence i do also recommend that the author should consider restarting the registration request once the final direction for the publication path of the document  is clear.

Alex