Re: [provreg] WG Review: Extensible Provisioning Protocol Extensions (eppext)

Patrik Fältström <paf@frobbit.se> Sat, 23 November 2013 07:48 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F2E1AE0FA for <provreg@ietfa.amsl.com>; Fri, 22 Nov 2013 23:48:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.776
X-Spam-Level:
X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.525, 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 9qTnXTIuF3cW for <provreg@ietfa.amsl.com>; Fri, 22 Nov 2013 23:48:45 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4351AE01D for <provreg@ietf.org>; Fri, 22 Nov 2013 23:48:45 -0800 (PST)
Received: from [10.1.6.196] (unknown [37.205.61.203]) by mail.frobbit.se (Postfix) with ESMTPSA id ACBD02032D; Sat, 23 Nov 2013 08:48:35 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Patrik Fältström <paf@frobbit.se>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Date: Sat, 23 Nov 2013 08:48:34 +0100
Message-Id: <DE2BEABF-6E77-464E-A290-E87D723C13C3@frobbit.se>
References: <20131122171808.16557.95825.idtracker@ietfa.amsl.com> <831693C2CDA2E849A7D7A712B24E257F492EAD28@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
To: Scott Hollenbeck <shollenbeck@verisign.com>
X-Mailer: Apple Mail (2.1822)
Cc: "provreg@ietf.org" <provreg@ietf.org>
Subject: Re: [provreg] WG Review: Extensible Provisioning Protocol Extensions (eppext)
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Nov 2013 07:48:47 -0000

+1

On 22 nov 2013, at 18:20, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

> Yay!
> 
> Scott
> 
> -----Original Message-----
> From: IETF-Announce [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
> Sent: Friday, November 22, 2013 12:18 PM
> To: IETF-Announce
> Cc: eppext WG
> Subject: WG Review: Extensible Provisioning Protocol Extensions (eppext)
> 
> A new IETF working group has been proposed in the Applications Area. The
> IESG has not made any determination yet. The following draft charter was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.
> 
> Extensible Provisioning Protocol Extensions (eppext)
> ------------------------------------------------
> Current Status: Proposed WG
> 
> Assigned Area Director:
>  Pete Resnick <presnick@qti.qualcomm.com>
> 
> Charter:
> 
> The Extensible Provisioning Protocol (EPP) was a work product of the IETF
> Provisioning Registry Protocol (provreg) working group. EPP was published
> as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March
> 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934)
> in May 2007, and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733,
> and 5734) in August 2009. It is the standard domain name provisioning
> protocol for generic top-level domain name registries that operate under
> the auspices of the Internet Corporation for Assigned Names and Numbers
> (ICANN). It is also used by a number of country code top-level domain
> registries.
> 
> Domain name registries implement a variety of business models. The
> difference in these models made it very difficult to come up with a "one
> size fits all" provisioning protocol, so the provreg working group made a
> conscious decision to focus on a minimal set of common functionality. EPP
> was designed to be extensible to allow additional features to be
> specified on an "as needed" basis. Guidelines for extending EPP were
> published as Informational RFC 3735 in March 2004.
> 
> The provreg working group was chartered to develop EPP, but not these
> additional extensions. The working group was closed in 2004 after
> producing a number of Proposed Standard specifications. As registries
> began to implement and deploy EPP the need for extensions became real,
> and the user community found itself facing a situation in which multiple
> extensions were being developed by different registries to solve the same
> basic problems, such as registering additional contact information.
> 
> EPP is widely implemented by generic top-level domain name registry
> operators. It is also used by multiple country-code top-level domain name
> registry operators. The Internet Corporation for Assigned Names and
> Numbers (ICANN) has an active program to delegate a large number of new
> generic top-level domains. EPP will be used to provision those domains,
> and new registry operators are expected to develop additional protocol
> extensions. With no way to coordinate the development of these
> extensions, the problem of non-standard extension duplication by multiple
> operators is only expected to become worse.
> 
> The goal of the EPP Extensions (eppext) working group is to create an
> IANA registry of EPP extensions and to review specifications of
> extensions for inclusion in the registry. It will accomplish this goal in
> two steps:
> 
> 1. Develop a specification for a registry of and corresponding
> registration procedures for EPP extensions. One proposal is documented in
> https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/.
> 
> 2. Produce a small number of extensions based on existing Internet Draft
> documents and use the IANA registration process as developed in 1 to
> register those extensions, as follows:
> 
> DNSSEC key relay: draft-gieben-epp-keyrelay
> (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)
> 
> Internationalized domain names: draft-obispo-epp-idn
> (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)
> 
> New TLD launch phases: draft-tan-epp-launchphase
> (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)
> 
> Trademark Clearinghouse: draft-lozano-tmch-smd
> (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)
> 
> Note: draft-tan-epp-launchphase has a normative dependency on
> draft-lozano-tmch-smd.
> 
> Only the development of the registration process and the
> publication/registration of the four extensions noted above are in scope
> for the working group. The working group can choose not to publish or
> register one or more of the extensions noted above, but it is out of
> scope to work on other extensions.
> 
> 
> Milestones:
>  May 2014 - Extensions registry document to IESG  
>  Jul 2014 - DNSSEC key relay extension to IESG
>  Jul 2014 - New TLD launch phases extension to IESG
>  Sep 2014 - Internationalized domain names extension to IESG
> 
> 
> _______________________________________________
> provreg mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg