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

Mike O'Connell <mcanix@gmail.com> Thu, 19 September 2013 18:19 UTC

Return-Path: <mcanix@gmail.com>
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 8D6DC21F9123 for <provreg@ietfa.amsl.com>; Thu, 19 Sep 2013 11:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level:
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 T14g7OS-ceIt for <provreg@ietfa.amsl.com>; Thu, 19 Sep 2013 11:19:47 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id CB9B821F90CC for <provreg@ietf.org>; Thu, 19 Sep 2013 11:19:46 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id ez12so8463773wid.3 for <provreg@ietf.org>; Thu, 19 Sep 2013 11:19:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=V4WhSMG8gyhX2C9uLr4L9xyaj3/gyb45pMssdW0MBQA=; b=xPlZBzqnWOINo6cuDDekRlYO2ej+K+tq928Nx3nTHkmDS91ZXaDjsVRqjSyRW98Dz2 JpXWLn9i/t2LjqzUqrnJe0fURITjQ2ytQoQtdAUF2J1HyVU42MqPnw7NAshbQa1T7E2u 67B+56qQ2MVkdvaLFITNsoTsDYeZNC2DfLicrM4hkeEjIbbhsVuQALaJlAIqpNNoL/Ti ySmbmVBQvI+sL9U6H5F9CpK7cpgHcziJRORd5dLLHFwJ4TgKMwFHV9ocfKgWJKYFXxTd JKu5LeNxVUeFFc3E9nJxrrHtQHRKSsQbpg9bC5b466BRpFbMBq1vBVG0as/XSQcbHlCb pz1Q==
X-Received: by 10.180.20.77 with SMTP id l13mr2443247wie.40.1379614785890; Thu, 19 Sep 2013 11:19:45 -0700 (PDT)
Received: from [192.168.192.18] (41-135-0-116.dsl.mweb.co.za. [41.135.0.116]) by mx.google.com with ESMTPSA id jf2sm11737078wic.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 11:19:44 -0700 (PDT)
References: <CE606A02.175D2%gustavo.lozano@icann.org>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CE606A02.175D2%gustavo.lozano@icann.org>
Content-Type: multipart/alternative; boundary="Apple-Mail-7A5BD739-F884-4430-945B-EA86A3827183"
Content-Transfer-Encoding: 7bit
Message-Id: <1E12FA0A-6354-4FE8-80E6-DEAC6E0F0460@gmail.com>
X-Mailer: iPad Mail (10B329)
From: Mike O'Connell <mcanix@gmail.com>
Date: Thu, 19 Sep 2013 20:19:39 +0200
To: Gustavo Lozano <gustavo.lozano@icann.org>
Cc: "provreg@ietf.org" <provreg@ietf.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: Thu, 19 Sep 2013 18:19:48 -0000

Likewise +1

On 19 Sep 2013, at 17:45, Gustavo Lozano <gustavo.lozano@icann.org> wrote:

> +1
> 
> Gustavo
> 
> From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
> Date: Wednesday, September 18, 2013 5:19 AM
> To: "Gould, James" <JGould@verisign.com>, Michael Young <michael@mwyoung.ca>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
> Cc: "provreg@ietf.org" <provreg@ietf.org>
> Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group
> 
> Same for me. I’m willing to write and review.
>  
> Alex
>  
>  
> Von: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] Im Auftrag von Gould, James
> Gesendet: Mittwoch, 18. September 2013 14:17
> An: Michael Young; Hollenbeck, Scott
> Cc: provreg@ietf.org
> Betreff: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group
>  
> Scott,
>  
> I too am willing to participate and help write, so +1.  
>  
> -- 
>  
> JG
>  
> <image001.png>
>  
> James Gould
> Principal Software Engineer
> jgould@verisign.com
>  
> 703-948-3271 (Office)
> 12061 Bluemont Way
> Reston, VA 20190
> VerisignInc.com
>  
> From: Michael Young <michael@mwyoung.ca>
> Date: Wednesday, September 18, 2013 8:01 AM
> To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
> Cc: EPP Provreg <provreg@ietf.org>
> Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group
>  
> Scott I'm willing to participate and help write,
> 
> Michael Young
> 
> On 2013-09-18 7:21 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
> <image001.png>
> _______________________________________________
> provreg mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg