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
- [eppext] Extension Registration Request: Registry… Hollenbeck, Scott
- Re: [eppext] Extension Registration Request: Regi… Ning Kong
- Re: [eppext] Extension Registration Request: Regi… Alexander Mayrhofer
- Re: [eppext] Extension Registration Request: Regi… Gavin Brown
- Re: [eppext] Extension Registration Request: Regi… Gould, James
- Re: [eppext] Extension Registration Request: Regi… Keith Gaughan