Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group

Dan York <york@isoc.org> Wed, 18 September 2013 17:21 UTC

Return-Path: <york@isoc.org>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C502611E8284 for <provreg@ietfa.amsl.com>; Wed, 18 Sep 2013 10:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CftvmYFZ54Ku for <provreg@ietfa.amsl.com>; Wed, 18 Sep 2013 10:21:31 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9B711E829D for <provreg@ietf.org>; Wed, 18 Sep 2013 10:21:30 -0700 (PDT)
Received: from BLUPR06MB067.namprd06.prod.outlook.com (10.242.187.146) by BLUPR06MB066.namprd06.prod.outlook.com (10.242.187.145) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 18 Sep 2013 17:21:28 +0000
Received: from BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.71]) by BLUPR06MB067.namprd06.prod.outlook.com ([169.254.16.165]) with mapi id 15.00.0775.005; Wed, 18 Sep 2013 17:21:28 +0000
From: Dan York <york@isoc.org>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "provreg@ietf.org" <provreg@ietf.org>
Thread-Topic: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group
Thread-Index: Ac60YSDD3AqH2WpnRAOeb5Tvgs6iewAENi2A
Date: Wed, 18 Sep 2013 17:21:27 +0000
Message-ID: <CE5F5239.2D98C%york@isoc.org>
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49266AC2@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.255.101.4]
x-forefront-prvs: 09730BD177
x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(479174003)(377454003)(51704005)(189002)(199002)(81686001)(77982001)(54316002)(56776001)(74876001)(19580405001)(76796001)(59766001)(54356001)(79102001)(15975445006)(74706001)(77096001)(76786001)(83322001)(65816001)(74366001)(80976001)(76176001)(19580395003)(81816001)(76482001)(80022001)(56816003)(69226001)(63696002)(47736001)(50986001)(15202345003)(4396001)(49866001)(51856001)(47446002)(53806001)(74502001)(81342001)(83072001)(36756003)(47976001)(81542001)(31966008)(15395725003)(74662001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB066; H:BLUPR06MB067.namprd06.prod.outlook.com; CLIP:10.255.101.4; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6ECAD3CABA16414F8C48C10DBFF1E6A7@namprd06.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 18 Sep 2013 17:21:34 -0000

Scott,

I would be willing to participate and review documents.  I'll note that my
specific interest is in accelerating DNSSEC deployment and I see this
registrar/registry communication as one of the areas that needs
improvement/automation. In discussing DNSSEC deployment challenges, we've
also received feedback from registrars that they are frustrated with
having many different ways of communicating with different registries.
While I agree that the variety of business models means there will
continue to be multiple extensions for EPP, I do see value in trying to do
whatever is possible to try to limit the proliferation of a zillion new
EPP extensions by documenting existing extensions and helping new
registries find out about those extensions before inventing their own.

As I don't work with EPP on a regular basis, I don't feel I have the
background to help with the actual writing, but I would be glad to
participate in reviewing.

Dan

P.S. And I do realize that EPP extensions are about far more than DNSSEC -
I was just stating the context for where I personally am coming from.

--
Dan York
Senior Content Strategist, Internet Society
york@isoc.org <mailto:york@isoc.org>   +1-802-735-1624
Jabber: york@jabber.isoc.org <mailto:york@jabber.isoc.org>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/




On 9/18/13 7:20 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:

>I recently closed a conversation with Applications Area Director Pete
>Resnick to see what he thought about a narrowly-focused charter for a
>working group to develop a registry for EPP extensions. Pete has agreed
>with the concept in principal. I'm including the text of the proposed
>charter that I shared with Pete and I'd like to ask others to review it
>and share feedback as appropriate.
>
>If we have enough support for a proposed charter Pete is willing to
>entertain a chartering request. If there's more to discuss we can ask
>about scheduling a BOF during the Vancouver meeting.
>
>I've got one specific question: are people able and willing to write a
>draft (or drafts) that describe(s) the registry and registration
>procedures? I don't think this will be a difficult task because cloning
>an existing registry is a perfectly reasonable approach, but someone
>needs to do the work. I'm willing to co-chair (if you all will have me)
>if we form a working group, and thus it would be best if we find other
>volunteers to write documents.
>
>Scott
>----------
>Proposed Charter for EPP Extensions (eppext) Working Group
>
>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 internationalized domain name
>variants.
>
>ICANN is now well into a 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 is only
>expected to become worse.
>
>The goal of the EPP Extensions (eppext) working group is to develop an
>IANA registry of EPP extensions and procedures to review specifications
>for inclusion in the registry. It will accomplish this goal in two steps:
>
>1. Develop a Proposed Standard specification for the registration and
>review of EPP extensions. There is no current Internet Draft that
>describes this process.
>
>2. Test the extension registration process by developing a small number
>of standards track extensions that currently exist in Internet Draft
>form, including:
>
>draft-gieben-epp-keyrelay
>(http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)
>
>draft-obispo-epp-idn
>(http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)
>
>draft-tan-epp-launchphase
>(http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)
>draft-lozano-tmch-smd
>(https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)
>draft-tan-epp-launchphase has a normative dependency on
>draft-lozano-tmch-smd.
>
>When these milestones have been completed the working group will consider
>rechartering to explore the issue of ongoing extension development and
>standardization. Modifications to EPP itself are explicitly out of scope
>for this working group.
>
>Milestones:
>
>TBD Extensions registry document to IESG
>
>TBD draft-gieben-epp-keyrelay to IESG
>
>TBD draft-obispo-epp-idn to IESG
>
>TBD draft-tan-epp-launchphase and draft-lozano-tmch-smd to IESG
>
>
>_______________________________________________
>provreg mailing list
>provreg@ietf.org
>https://www.ietf.org/mailman/listinfo/provreg