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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 18 Sep 2013 11:20:51 +0000

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

---

From: Michael Young <[email-masked]>
Date: Wed, 18 Sep 2013 08:01:40 -0400

Scott I'm willing to participate and help write,

Michael Young
On 2013-09-18 7:21 AM, "Hollenbeck, Scott" <[email-masked]> 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
> ----------
> 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/)
> 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:
>
> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg
>

---

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Sep 2013 12:17:20 +0000

Scott,

I too am willing to participate and help write, so +1.

--

JG

James Gould
Principal Software Engineer
[email-masked]

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

From: Michael Young <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 18, 2013 8:01 AM
To: "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>
Cc: EPP Provreg <[email-masked]<mailto:[email-masked]>>
Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group

Michael Young

On 2013-09-18 7:21 AM, "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>> 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.

Scott
----------

Milestones:

_______________________________________________
provreg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/provreg

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 18 Sep 2013 12:19:02 +0000

Same for me. I'm willing to write and review.

Alex

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Gould, James
Gesendet: Mittwoch, 18. September 2013 14:17
An: Michael Young; Hollenbeck, Scott
Cc: [email-masked]
Betreff: Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working Group

Scott,

--

JG

James Gould
Principal Software Engineer
[email-masked]<mailto:[email-masked]>

703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

Michael Young

Scott
----------

Milestones:

---

From: Luis Muñoz <[email-masked]>
Date: Wed, 18 Sep 2013 08:40:14 -0400

I'm willing to participate, specially writing.

Best regards

-lem

---

From: Francisco Obispo <[email-masked]>
Date: Wed, 18 Sep 2013 07:47:45 -0500

Hi Scott,

We will be happy to participate in the wg.

best regards,

> 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 becau…

Francisco Obispo 
email: [email-masked]
Phone: +1 650 423 1374 || INOC-DBA *3557* NOC
PGP KeyID = B38DB1BE

---

From: Jothan Frakes <[email-masked]>
Date: Wed, 18 Sep 2013 09:41:38 -0700

I would like to also participate and contribute to this important effort.

-Jothan

Jothan Frakes
+1.206-355-0230 tel
+1.206-201-6881 fax

---

From: Dan York <[email-masked]>
Date: Wed, 18 Sep 2013 17:21:27 +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
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

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

On 9/18/13 7:20 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

>charter that I shared with Pete and I'd like to ask others to review it
>and share feedback as appropriate.
>
>entertain a chartering request. If there's more to discuss we can ask
>about scheduling a BOF during the Vancouver meeting.
>
>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
>----------
>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
>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.
>
>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.
>
>IANA registry of EPP extensions and procedures to review specifications
>for inclusion in the registry. It will accomplish this goal in two steps:
>
>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/)

---

From: Jay Daley <[email-masked]>
Date: Thu, 19 Sep 2013 11:54:06 +1200

Good news, thanks Scott and thanks for offering to co-chair.  I'll make the time to review.

Jay

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

---

From: Antoin Verschuren <[email-masked]>
Date: Thu, 19 Sep 2013 09:31:32 +0200

Hi Scott,

I feel a conflict of interest writing on the registration procedures,
but I'm happy to review and participate in the wg.

Op 18-09-13 13:20, Hollenbeck, Scott schreef:

> 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.

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  M: +31 6 23368970
Mailto: [email-masked]
XMPP: [email-masked]
HTTP://www.sidn.nl/

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 19 Sep 2013 08:45:27 -0700

+1

Gustavo

From:  Alexander Mayrhofer <[email-masked]>
Date:  Wednesday, September 18, 2013 5:19 AM
To:  "Gould, James" <[email-masked]>, Michael Young
<[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [provreg] Proposed Charter for EPP Extensions (eppext) Working
Group

> Same for me. I¹m willing to write and review.
>  
> Alex
>  
>  
> 
> From: Michael Young <[email-masked]>
> To: "Hollenbeck, Scott" <[email-masked]>
> Cc: EPP Provreg <[email-masked]>
>> 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
>> ----------
>> 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.
>> 
>> 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.
>> 
>> 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
>> 1. Develop a Proposed Standard specification for the registration and review
>> of EPP extensions. There is no current Internet Draft that describes this
>> process.
>> 
>> standardization. Modifications to EPP itself are explicitly out of scope for
>> this working group.
>> 
>> Milestones:
>>

---

From: Mike O'Connell <[email-masked]>
Date: Thu, 19 Sep 2013 20:19:39 +0200

Likewise +1

On 19 Sep 2013, at 17:45, Gustavo Lozano <[email-masked]> wrote:

> To: "Gould, James" <[email-masked]>, Michael Young <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>
> Same for me. I’m willing to write and review.
>  
> Alex
>  
>

---

From: Jan Saell <[email-masked]>
Date: Fri, 20 Sep 2013 09:17:16 +0200

+1 here. ALso willing to write and review

Best regards
jan

On 09/19/2013 08:19 PM, Mike O'Connell wrote:
> Likewise +1
> 
> On 19 Sep 2013, at 17:45, Gustavo Lozano <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> +1
>>
>> Gustavo
>>
>> From: Alexander Mayrhofer <[email-masked]
>> <mailto:[email-masked]>>
>> To: "Gould, James" <[email-masked] <mailto:[email-masked]>>,
>> Michael Young <[email-masked] <mailto:[email-masked]>>,
>> "Hollenbeck, Scott" <[email-masked]
>> <mailto:[email-masked]>>
>> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>> <mailto:[email-masked]>>
>>     *Von:[email-masked] <mailto:[email-masked]>
>>     [mailto:[email-masked]] *Im Auftrag von *Gould, James
>>     *Gesendet:* Mittwoch, 18. September 2013 14:17
>>     *An:* Michael Young; Hollenbeck, Scott
>>     *Cc:* [email-masked] <mailto:[email-masked]>
>>     *Betreff:* Re: [provreg] Proposed Charter for EPP Extensions
>>     (eppext) Working Group
>>
>>      
>>
>>     Scott,
>>
>>      
>>
>>     [email-masked] <mailto:[email-masked]>
>>
>>      
>>
>>     703-948-3271 (Office)
>>
>>     12061 Bluemont Way
>>
>>     Reston, VA 20190
>>
>>     VerisignInc.com <http://VerisignInc.com>
>>
>>      
>>
>>     *From: *Michael Young <[email-masked] <mailto:[email-masked]>>
>>     *Date: *Wednesday, September 18, 2013 8:01 AM
>>     *To: *"Hollenbeck, Scott" <[email-masked]
>>     <mailto:[email-masked]>>
>>     *Cc: *EPP Provreg <[email-masked] <mailto:[email-masked]>>
>>     *Subject: *Re: [provreg] Proposed Charter for EPP Extensions
>>     (eppext) Working Group
>>
>>      
>>
>>         On 2013-09-18 7:21 AM, "Hollenbeck, Scott"
>>         <[email-masked] <mailto:[email-masked]>>
>>         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.
>>
>>         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
>>         ----------
>>         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
>>         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:
>>
>>         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:
>>
>>         [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

- -- 
+-------------------------------------------------------------------
! Irial / YASK AB
! Att: Jan Saell
! Box 59, S-692 21 KUMLA, SWEDEN
! Tel: 019-58 25 15     Int +46-19 58 25 15     Fax +46-19 58 38 05
! E-mail: [email-masked]
! PGP Fingerprint: E957 23C8 9F51 0958 B9AD  7F18 404A 5DA1 F944 A08B

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Sep 2013 11:29:35 +0000

A number of people have expressed willingness to participate and/or write documents. It would be really, really helpful if one or more of you could write a draft or two describing proposals for an extensions registry. Having a couple of documents to choose from might make the chartering process a little easier. Something like RFC 5797 (http://tools.ietf.org/html/rfc5797) could provide a useful template.

There are some thoughts on registry contents in this thread:

http://www.ietf.org/mail-archive/web/provreg/current/msg07429.html

Scott

---

From: Ning Kong <[email-masked]>
Date: Sun, 22 Sep 2013 10:43:56 +0800

Thanks, Scott. I'd like to review and contribute. Hope my response is not too late.

BTW, I notice that registering internationalized domain name variants is as a example in the proposed charter. I still think draft-kong-epp-idn-variants-mapping rightly focuses on this problem. I hope this draft can also be considered by the new WG. Any thoughts?

Cheers,
Ning

---

From: "Jian Chen" <[email-masked]>
Date: Sun, 22 Sep 2013 14:58:38 +0800 (CST)

Hi Scott,

I'm willing to participate and do some help.
best regards,Jian Chen

--

---

From: Peter Koch <[email-masked]>
Date: Mon, 23 Sep 2013 07:28:52 +0200

Scott, all,

> Proposed Charter for EPP Extensions (eppext) Working Group

looks like a good start for develioping the list discussion into a charter.

> 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 additio…

The IETF has not made the best experience with working on protocols
with explicitly naming ICANN as the primary, let alone single,
stakeholder.  I understand this is a motivator, but the charter
would probably not suffer from an omission of this section.

> 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…

There seems to be a need for some catalog of extensions, but my feeling
is that an IANA registry isn't the right approach.  There's no
identifier space (except that there's already some XML registration
involved) and artificially creating such space just to make IANA eligible
for maintaining such a catalog looks odd to me.

> 1. Develop a Proposed Standard specification for the registration and review of EPP extensions. There is no current Internet Draft that describes this process.

With the above said and just as a nit: an IANA registration policy would
fit into a BCP better than into a PS/standards track document.

> draft-tan-epp-launchphase has a normative dependency on draft-lozano-tmch-smd.

Work on these could actually progress without (1) done and even without (1) at all.

-Peter (otherwise EPP ignorant)

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 23 Sep 2013 17:16:08 +0800

volunteer to write and review

Regards,
Linlin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hollenbeck, Scott
> Sent: Wednesday, September 18, 2013 7:21 PM
> To: [email-masked]
> Subject: [provreg] Proposed Charter for EPP Extensions (eppext) Working
Group
> 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.
> 
entertain a
> chartering request. If there's more to discuss we can ask about scheduling
a
> BOF during the Vancouver meeting.
> 
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
> ----------
as a
> Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004.
It
> 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
> 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"
> additional extensions. The working group was closed in 2004 after
producing a
> registry operators are expected to develop additional protocol extensions.
With
> no way to coordinate the development of these extensions, the problem of
IANA
> registry of EPP extensions and procedures to review specifications for
inclusion
> in the registry. It will accomplish this goal in two steps:
> 
review of
> EPP extensions. There is no current Internet Draft that describes this
process.
> standardization. Modifications to EPP itself are explicitly out of scope
for this
> working group.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 23 Sep 2013 12:39:55 +0000

> From: Ning Kong [mailto:[email-masked]]
> Sent: Saturday, September 21, 2013 10:44 PM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> BTW, I notice that registering internationalized domain name variants
> is as a example in the proposed charter. I still think draft-kong-epp-
> idn-variants-mapping rightly focuses on this problem. I hope this draft
> can also be considered by the new WG. Any thoughts?

Ning, I was trying to limit the initial list to a small number of active drafts that have already been the subject of discussion and have been revised at least once to reflect that discussion. Your document is a -00 draft that expired in September 2012. Given the lack of recent progress I didn't think your document was far enough along to be included in the first batch.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 23 Sep 2013 12:56:55 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Koch
> Sent: Monday, September 23, 2013 1:29 AM
> To: [email-masked]

Thanks for the feedback, Peter.

> would probably not suffer from an omission of this section.

ICANN's gTLD program isn't the single stakeholder. I'd prefer to keep the text to recognize reality, but I could add more to make it clear that this effort isn't just a reaction to the ICANN program.

> > 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:
> 

There's precedent for using IANA-maintained registries to manage the development of protocol extensions. The BCP vs. standards track discussion is worth having, but again, there is precedent for such documents being on the standards track. RFC 5797 is an example of both. I don't have a strong preference when it comes to PS or BCP, but I do prefer to follow convention. Pete can certainly provide guidance on this point.

I proposed an IANA registry based on recent list threads expressing support for the idea. Can you suggest an alternative if you don't think this is the right approach?

> > 2. Test the extension registration process by developing a small
> number of standards track extensions that currently exist in Internet
> Draft form, including:
> >

Of course, but a number of people who have implemented and are using EPP have suggested that the lack of a more formal process to coordinate extension development is causing confusion and duplication of effort.

Scott

---

From: Ning Kong <[email-masked]>
Date: Tue, 24 Sep 2013 14:08:18 +0800

> Ning, I was trying to limit the initial list to a small number of active drafts that have already been the subject of discussion and have been revised at least once to reflect that discussion. Your…
The main reason of the lack of progress is that there is not a suitable WG to improve it. I had thought to form a new WG for this work. I'm very glad to see your work for the new eppext WG.

I'm not sure we should limit the number of active drafts or limit the number of topics for the first batch. If we choose topics, I think my draft is within the scope. As I mentioned in my last email, "registering internationalized domain name variants" is listed in the proposed charter, but there is no draft within the current first batch discussing the variants issue.

If necessary, I'd like to update our draft ASAP.

Cheers,
Ning

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 24 Sep 2013 11:01:41 +0000

> Sent: Tuesday, September 24, 2013 2:08 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> > Ning, I was trying to limit the initial list to a small number of
> active drafts that have already been the subject of discussion and have
> been revised at least once to reflect that discussion. Your document is
> a -00 draft that expired in September 2012. Given the lack of recent
> progress I didn't think your document was far enough along to be
> included in the first batch.
> The main reason of the lack of progress is that there is not a suitable
> WG to improve it. I had thought to form a new WG for this work. I'm
> very glad to see your work for the new eppext WG.
> 
> I'm not sure we should limit the number of active drafts or limit the
> number of topics for the first batch. If we choose topics, I think my
> draft is within the scope. As I mentioned in my last email,
> "registering internationalized domain name variants" is listed in the
> proposed charter, but there is no draft within the current first batch
> discussing the variants issue.

I'm going with Pete's original guidance on the drafts to be selected. This is how John Levine explained that guidance to me:

> I talked to Pete Resnick, one of the IETF apps area ADs yesterday, and
> he
> says he's willing to set up a short lived working group to turn EPP
> extension drafts into RFCs.  There are two conditions: that we identify
> the drafts in advance, all of which have to be in current use, and that
> we
> round up enough people with implementation experience to read them and
> confirm that what we plan to publish is what they implemented.

So I have to disagree when it comes to imposing limits - and I can easily change the proposed charter text if there is any confusion about IDN variants. Pushing out an update now to create the illusion of activity won't help us.

Scott