Subject: [provreg] FW: EPP extensions working group

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Jul 2013 13:16:08 +0000

Please see the note below from John Levine. Does anyone know of any other EPP extensions that meet the conditions laid out by Pete? I'd like to consider non-Verisign extensions, too.

If this effort is successful we may have a better chance of creating a working group to develop extensions that don't yet exist or haven't been documented in the IETF.

Scott

-----Original Message-----
From: John R Levine [mailto:[email-masked]] 
Sent: Friday, July 19, 2013 4:58 PM
To: Hollenbeck, Scott; Francisco Obispo; Wil Tan; Gould, James
Subject: EPP extensions working group

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.

The drafts currently on my list are:

IDN Language Tag (http:⁄⁄www.verisigninc.com⁄assets⁄idn-language-tag.pdf)
RGP Poll Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf)
Whois Info Extension (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf)
ConsoliDate Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt)
NameStore Extension (http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf)
Low Balance Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf)

draft-obispo-epp-idn

draft-tan-epp-launchphase

If there are any more you think we should add, please let me know.

Also, it would be a big help if you could suggest people at registries and 
registrars who have implemented these so we can ask them to read along.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Jul 2013 15:22:54 +0200

I fully support any work that make this list shorter:

<http://search.cpan.org/dist/Net-DRI/>

   Patrik

On 22 jul 2013, at 15:16, "Hollenbeck, Scott" <[email-masked]> wrote:

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Jul 2013 13:27:15 +0000

> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Monday, July 22, 2013 9:23 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [provreg] FW: EPP extensions working group
> 

Do you know which of those exist in I-D form, Patrik?

Scott

---

From: Wil Tan <[email-masked]>
Date: Mon, 22 Jul 2013 22:40:17 +0900

> <http://search.cpan.org/dist/Net-DRI/>

It certainly won't shorten the list, but will hopefully encourage reuse and
slow the proliferation of extensions created for nearly identical purposes.

.wil

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Jul 2013 15:56:32 +0200

> Do you know which of those exist in I-D form, Patrik?

Unfortunately not.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Jul 2013 15:57:45 +0200

On 22 jul 2013, at 15:40, Wil Tan <[email-masked]> wrote:

> It certainly won't shorten the list, but will hopefully encourage reuse and slow the proliferation of extensions created for nearly identical purposes.

True, but it would be even cooler if an initiative like this in a combination of IETF/ICANN/*TLD have as a goal to shorten the list. And IF the list ends up being shorter, I buy chocolate to everyone! (well, maybe not but anyway... :-P

   paf

---

From: Ewout de Graaf <[email-masked]>
Date: Mon, 22 Jul 2013 15:40:26 +0200

A standardized undelete / remove from quarantine EPP extension would be
nice.

And since this track will take some time, an extension to support secure
DNSSEC transfers.
We tested http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/ with
success.

Kind regards,

Ewout de Graaf
Metaregistrar

2013/7/22 Hollenbeck, Scott <[email-masked]>

> Please see the note below from John Levine. Does anyone know of any other
> EPP extensions that meet the conditions laid out by Pete? I'd like to
> consider non-Verisign extensions, too.
>
> If this effort is successful we may have a better chance of creating a
> working group to develop extensions that don't yet exist or haven't been
> documented in the IETF.
>
> Scott
>
>

---

From: Antoin Verschuren <[email-masked]>
Date: Mon, 22 Jul 2013 16:05:01 +0200

> Do you know which of those exist in I-D form, Patrik?

Net::DRI has just implemented

http://tools.ietf.org/id/draft-gieben-epp-keyrelay-03.txt

This I-D is almost finished, I was actually going to approach Pete for
AD adoption.
It was implemented 2 weeks ago, and in use, as you can read in english
here:
http://www.domainnews.com/en/secure-transfer-method-for-dnssec-secured-domain-names-already-out-to-successful-use.html
The draft contains the running code that we implemented.

So it meets the criteria, and I'm happy to work on this.

- -
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: Frederico A C Neves <[email-masked]>
Date: Mon, 22 Jul 2013 11:27:17 -0300

Scott,

> If this effort is successful we may have a better chance of creating a working group to develop extensions that don't yet exist or haven't been documented in the IETF.

We've two extensions used since 2006 to associate tax-payers IDs in
Brazil to .br domain names.

ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-brorg-05.txt
ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-brdomain-04.txt

And we've two extensions used since 2010 for allocation/assignment and
reallocation/reassignment for ASNs and IP blocks. It's being used by
LACNIC and the two NIRs or the region, Nic.br and Nic.mx and it's
being used by large ISPs to automate their provisioning systems too.

ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-asn-02.txt
ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-asn-02.txt

> Scott

Fred

> IDN Language Tag (http:??????www.verisigninc.com???assets???idn-language-tag.pdf)
> RGP Poll Mapping (http:??????www.verisigninc.com???assets???whois-info-extension.pdf)
> Whois Info Extension (http:??????www.verisigninc.com???assets???whois-info-extension.pdf)
> ConsoliDate Mapping (http:??????www.verisigninc.com???assets???consolidate-mapping.txt)
> NameStore Extension (http:??????www.verisigninc.com???assets???namestore-extension.pdf)
> Low Balance Mapping (http:??????www.verisigninc.com???assets???low-balance-mapping.pdf)
> 
> draft-obispo-epp-idn
>

---

From: Edward Lewis <[email-masked]>
Date: Mon, 22 Jul 2013 10:55:55 -0400

As someone that has dealt more with the forces behind EPP than the implementation of the code, I'm not sure upon which open forum I'd place the onus of shortening the CPAN list.  Shortening "the list" is a worthy goal, don't get me wrong.  It's that the first step of choosing the right forum is important to success.  The reason is that one might be able to combine certain extensions into one but getting a registry to adopt the new version over the existing extension is more important in declaring success than publishing a document.

What I learned in 2010 or so's dabbling in "wither EPP 2.0?" was that registries need an economic reason to make an engineering change.  I feel, without every performing an survey of registrars, that they have a similar need.  What I want to avoid is the IETF's proclivity to assume "if we build it they will come" going into a working group or we will see a reprise of the CRISP WG's IRIS.

This isn't to say that the list that started this thread shouldn't be collected into a new IETF working group.  Those are existing internet drafts and are candidates for adoption by sets of operators.  The list of items on the CPAN site don't fit that profile, trying to combine work that has already been completed is much different than working a "green field."

> True, but it would be even cooler if an initiative like this in a combination of IETF/ICANN/*TLD have as a goal to shorten the list. And IF the list ends up being shorter, I buy chocolate to everyo…

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 22 Jul 2013 09:40:46 -0700

> As someone that has dealt more with the forces behind EPP ...

+1.

I went into the Vertical Integration Working Group (an ICANN thing)
with the hope that a 15% registry ownership cap in registrars would
force a 7-to-1 shared resource pattern.

The ICANN Board decided each registry could be its own registrar.

Fortunately, the vast majority of the ~2k applicants settled on one of
~40 registry service providers, and these share costs, hence fate,
across multiple tenant registry contract holders.

But fundamentally, the shared registrar (poli-db-access-agent) is
broken by the uni-db-access-agent, historically do-what-vgrs-does, now
do-what-each-go-it-alone-operator-does, with the semi-orthogonal
feature of ~.2k non-gTLDs, some of which are "in scope".

I don't expect chocolate from paf any time soon.

Eric

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 22 Jul 2013 23:22:19 +0200

On 22 jul 2013, at 16:55, Edward Lewis <[email-masked]> wrote:

> What I learned in 2010 or so's dabbling in "wither EPP 2.0?" was that registries need an economic reason to make an engineering change.

This is why I at the ICANN meeting had a presentation that it is not the *registries* that make the choice by the registrars (on behalf of the registrants).

I.e. the classical view is that we have one TLD/registry and to that we have many registrars.

That is wrong.

Instead we have one registrant, one or more registrars and then many many registries.

So the economical incentive for registries is to do what their registrants, via the registrars, have interest in, which is to harmonize. ;-)

   Patrik

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 22 Jul 2013 23:24:01 +0200

Hollenbeck, Scott <[email-masked]> 2013-07-22 15:29

>From what I remember when implementing them, almost none, or if an I-D
existed it was outdated and not in sync with what was done really.

Please note that if you see the first few lines of comment inside each
Net::DRI::Protocol::EPP::Extensions::* module you see the URL or a
name of PDF I used to do the implementation.

One of the strength of this work is to implement so many extensions
under a common umbrella. But shortening the list is a goal I'm also
interested in.

Please have a look also in this presentation I made in 2006:
http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-techday-201006.pdf

I do not think many things have changed since then (except number of
extensions and TLDs supported in the toolkit), and it shows
examples of overlap and unfortunate duplication.

PS: if anyone wants to buy chocolate, I love chocolate :-)

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 23 Jul 2013 00:02:59 +0200

Patrick Mevzek <[email-masked]> 2013-07-22 23:27
> http://www.dotandco.com/services/software/Net-DRI/docs/netdri-future-epp-icann-brussels-ccnso-techday-201006/netdri-future-epp-icann-brussels-ccnso-techday-201006.pdf
 
My bad, it was done in June 2010, not in 2006.

Also, before starting any work on past extensions, I believe it would
be useful (even if a little late, the good time would have been before
ICANN accepted new gTLDs) to make whatever is necessary to make sure
people are not creating new duplication, by purpose or just ignorance
of what is happening. I do not claim to know what would be necessary
for that, nor knowing if this problem has really a solution. ICANN
could put some pressure on gTLD markets, but less so on ccTLD ones.

For example, if I'm not mistaken, there are 2 drafts for handling
specific registry phases, such as sunrise and such. Since I've not
studied both of them a lot, I can not argue definitively that they
could be merged completely, but from experience I'm sure there is some
possible mutualisation.

As stated in my presentation however the crux of the problem is not
technical but economical : specifically for currently in use
extensions, registries will have no incentive to switch over new ones
doing the same thing even if done more "standardized", with registrars
not wanting to change their existing implementation
(from my ccTLD technical experience, we still see people struggling
with DNSSEC in general, and specifically DNSSEC in EPP)

This is my only fear in working on "unified/standardized" versions: at
the end, what guarantee do we have that we have really replaced the
old ones, and not just create another iteration?

Obligatory XKCD on that: http://xkcd.com/927/

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 23 Jul 2013 00:07:23 +0200

Patrik Fältström <[email-masked]> 2013-07-22 15:24
> <http://search.cpan.org/dist/Net-DRI/>
 
Make sure to see the latest version (which is marked as developer
level, but is indeed stable and used in production) :
https://metacpan.org/release/PMEVZEK/Net-DRI-0.96_05

You haven even more Net::DRI::Protocol::EPP::Extensions::* cases to
study :-)

And more are underway, based on patches I've received.

-- 
Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 23 Jul 2013 09:27:10 +0800

Hi Scott,

We have 3 EPP extensions about domain variants and implemented them.

http://datatracker.ietf.org/doc/draft-kong-epp-cdn-mapping/
http://datatracker.ietf.org/doc/draft-kong-epp-cdn-dnssec-mapping/
http://datatracker.ietf.org/doc/draft-kong-epp-idn-variants-mapping/

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hollenbeck, Scott
> Sent: Monday, July 22, 2013 9:16 PM
> To: [email-masked]
> Subject: [provreg] FW: EPP extensions working group
> 
> EPP extensions that meet the conditions laid out by Pete? I'd like to consider
> non-Verisign extensions, too.
> 
> If this effort is successful we may have a better chance of creating a working
> group to develop extensions that don't yet exist or haven't been documented in
> the IETF.
> 
> Scott
> 
> 
> 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.
> 
> RGP Poll Mapping
> (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf)
> Whois Info Extension
> (http:⁄⁄www.verisigninc.com⁄assets⁄whois-info-extension.pdf)
> ConsoliDate Mapping
> (http:⁄⁄www.verisigninc.com⁄assets⁄consolidate-mapping.txt)
> NameStore Extension
> (http:⁄⁄www.verisigninc.com⁄assets⁄namestore-extension.pdf)
> Low Balance Mapping
> (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf)
> 
> draft-obispo-epp-idn
> 
> John Levine, [email-masked], Taughannock Networks, Trumansburg NY "I
> dropped the toothpaste", said Tom, crestfallenly.

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 23 Jul 2013 10:50:45 +0200 (CEST)

Hi Patrick

You are right, the challenges on the technical side are not to much of a 
problem. The economical side and policies (in some cases the legal / 
regualatory requirements) induce far stronger drag to more harmonization 
in EPP.

Back in 2005 (while still working for the .ch/.li ccTLD / before EPP was 
implemented widely) I took an effort (in CENTR) to standardize one 
consolidated alternative for each of those parts in EPP, that did not fit 
well for most (European) ccTLDs. Those were mainly the Contact object and 
the Transfer Logic (among other smaller issues).

It was rather difficult to convince other Registries to invest time and 
resources into more EPP standardization. The question I got was often: 
"What is our incentive, if we can just make our own extensions and let the 
Registrars deal with it?"

And on the Registrar side I often hear: "We have implemented all the 
extensions by now. Why should we help to make things easier to new 
competitors?"

I don't think things have changed too much in the meantime, however I'd be 
more than happy to learn the opposite, i.e. that things had changed...

cheers,
  Bernie

--

http://ucom.ch/
Tech Consulting for Internet Technology

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 23 Jul 2013 07:43:06 -0300

On Mon, Jul 22, 2013 at 11:27:17AM -0300, Frederico A C Neves wrote:
...
> ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-asn-02.txt

Duplicated ref, the correct one is.

ftp://ftp.registro.br/pub/libepp-nicbr/draft-neves-epp-ipnetwork-02.txt

Fred

---

From: Jay Daley <[email-masked]>
Date: Mon, 29 Jul 2013 14:54:44 +1200

> Please see the note below from John Levine. Does anyone know of any other EPP extensions that meet the conditions laid out by Pete? I'd like to consider non-Verisign extensions, too.

Yes I agree in principle but not to most of the specific extensions below. 

> If this effort is successful we may have a better chance of creating a working group to develop extensions that don't yet exist or haven't been documented in the IETF.

Great - that's very much needed as the IETF is in danger of becoming irrelevant in this particular niche.

> confirm that what we plan to publish is what they implemented.

I would add the following criteria

1.  Are not proprietary to a specific registry
2.  Have already had significant discussion and review on the provreg list
3.  Are not patent encumbered

> Low Balance Mapping (http:⁄⁄www.verisigninc.com⁄assets⁄low-balance-mapping.pdf)

None of which I would support for violating #2, mostly violating #1 and probably violating #3 of my criteria above.

(BTW How the hell does someone get forward slashes that are not forward slashes into URLs?)

> draft-obispo-epp-idn

Yes.

> draft-tan-epp-launchphase

Yes.

> If there are any more you think we should add, please let me know.

As Patrik points out, the shorter the list the better.

cheers
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: "Gould, James" <[email-masked]>
Date: Mon, 29 Jul 2013 15:27:44 +0000

Jay,

I believe that your additional criteria might overly filter the candidate
set of extensions.  There are clear standard track extensions including
draft-tan-epp-launchphase and draft-obispo-epp-idn that could go through
as individual submissions as long as an AD is willing to take them based
on their maturity and based on the discussions that have already occurred
on the provreg list.  There are a large set of extensions that have been
and are in the process of being built that could be of general interest.
If this working group is meant to be "short lived" and to handle initially
the low hanging fruit, then certainly it could take on the extensions that
are primed for standards track like draft-tan-epp-launchphase and
draft-obispo-epp-idn.  I am not sure if these two extensions alone are
enough to form a working group, since they could be individual
submissions.  The ConsoliDate Mapping
(http:ŽŽwww.verisigninc.comŽassetsŽconsolidate-mapping.txt) extension
created by Scott Hollenbeck back in 2005 for supporting synchronization of
expiration dates might be of general interest and applicable for the
working group even though it would violate your #1 and #2 criteria items.
There is no issue with your #3 criteria item.  My proposal is to focus on
the following extensions:

1. draft-tan-epp-launchphase along with the dependent draft-lozano-tmch-smd
2. draft-obispo-epp-idn
3. ConsoliDate Mapping
 
Hopefully we can create a broader charter in the future to attack the set
of custom extensions that are of general interest.
    
-- 
 
JG

James Gould
Principal Software Engineer
[email-masked]
 
703-948-3271 (Office)
12061 Bluemont Way
Reston, VA 20190
VerisignInc.com

On 7/28/13 10:54 PM, "Jay Daley" <[email-masked]> wrote:

>> Please see the note below from John Levine. Does anyone know of any
>>other EPP extensions that meet the conditions laid out by Pete? I'd like
>>to consider non-Verisign extensions, too.
>
>> IDN Language Tag
>>(http:ŽŽwww.verisigninc.comŽassetsŽidn-language-tag.pdf)
>> RGP Poll Mapping
>>(http:ŽŽwww.verisigninc.comŽassetsŽwhois-info-extension.pdf)
>> Whois Info Extension
>>(http:ŽŽwww.verisigninc.comŽassetsŽwhois-info-extension.pdf)
>> ConsoliDate Mapping
>>(http:ŽŽwww.verisigninc.comŽassetsŽconsolidate-mapping.txt)
>> NameStore Extension
>>(http:ŽŽwww.verisigninc.comŽassetsŽnamestore-extension.pdf)
>> Low Balance Mapping
>>(http:ŽŽwww.verisigninc.comŽassetsŽlow-balance-mapping.pdf)
>
>None of which I would support for violating #2, mostly violating #1 and
>probably violating #3 of my criteria above.
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 29 Jul 2013 15:49:37 +0000

Here's a summary of the active extension I-Ds I've that may meet Pete's existence and use requirements:

http://datatracker.ietf.org/doc/draft-obispo-epp-idn/ (in use?)

http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/ (in use)

http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/ (in use)

http://datatracker.ietf.org/doc/draft-wang-epp-cdn-mapping/ (in use?)

http://datatracker.ietf.org/doc/draft-xie-epp-trademark-mapping/ (in use?)

I've marked some "in use?" because I'm not sure if they are. If they are, please say so.

If Pete eventually lets us consider expired drafts the pool of candidates can be increased (not all of these are viable candidates, though):

http://datatracker.ietf.org/doc/search/?name=epp&olddrafts=on&sort=

Scott

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hollenbeck, Scott
> Sent: Monday, July 22, 2013 9:16 AM
> To: [email-masked]
> other EPP extensions that meet the conditions laid out by Pete? I'd
> like to consider non-Verisign extensions, too.
> 
> working group to develop extensions that don't yet exist or haven't
> been documented in the IETF.
> 
> Scott
> 
>

---

From: Keith Gaughan <[email-masked]>
Date: Mon, 29 Jul 2013 17:46:41 +0100

On Mon, Jul 22, 2013 at 03:40:26PM +0200, Ewout de Graaf wrote:

> A standardized undelete / remove from quarantine EPP extension would
> be nice.

Sorry for piping up late on this. Gavin Brown and I have mentioned on
the list that a standardised method for notifying registrars that the
registry plans on garbage collecting unused objects would be useful. We
went over methods that might be done within the contraints of the
existing object mappings, but unfortunately nothing worked without
breaking contraints EPP and the standardised mappings place on us.

I believe that a standardised undelete / remove from quarantine
extension should cover this use-case too. It would be better than the
current practice of some registries that abuse RFC 3915 to implement
removal from quarantine by having registrars issue <rgp:restore
op="request"/> requests.

K.

-- 
Keith Gaughan, Development Lead
PGP/GPG key ID: 82AC3634
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Jul 2013 09:40:14 +1200

On 30/07/2013, at 3:27 AM, "Gould, James" <[email-masked]> wrote:

> submissions.  

As I understood it, and someone please correct me if I'm wrong, this is a two-step process.  Step one is to prove the efficacy of the WG by taking some already well developed ideas through to conclusion and step two is then for a longer term WG to take a more strategic approach of creating standards where we would otherwise be doing things in different ways.

I don't think it takes a long list to achieve step one but what is does take is engagement of the community interested in this and to me that will not be achievable, and may in fact be damaged, by starting with drafts that are proprietary and have not been discussed much.

If the list needs broadening then something like epp-keyrelay would be a better third candidate.

cheers
Jay

> The ConsoliDate Mapping

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 30 Jul 2013 08:03:16 +0000

> From: Jay Daley [mailto:[email-masked]]
> Sent: Monday, July 29, 2013 5:40 PM
> To: Gould, James
> Cc: Hollenbeck, Scott; [email-masked]
> Subject: Re: [provreg] EPP extensions working group
> 
> As I understood it, and someone please correct me if I'm wrong, this is
> a two-step process.  Step one is to prove the efficacy of the WG by
> taking some already well developed ideas through to conclusion and step
> two is then for a longer term WG to take a more strategic approach of
> creating standards where we would otherwise be doing things in
> different ways.
> 
> I don't think it takes a long list to achieve step one but what is does
> take is engagement of the community interested in this and to me that
> will not be achievable, and may in fact be damaged, by starting with
> drafts that are proprietary and have not been discussed much.

Something to consider: documents that are currently proprietary or otherwise not in I-D format may well have been implemented and used far more broadly than those that exist as I-Ds. If there is a commitment to release the specification(s) to the community they may be worth considering.

As of right now this is only a one-step process. Pete hasn't agreed to a second step. I think you're right about the goal of the first step.

Scott

---

From: Jay Daley <[email-masked]>
Date: Tue, 30 Jul 2013 21:44:47 +1200

> Something to consider: documents that are currently proprietary or otherwise not in I-D format may well have been implemented and used far more broadly than those that exist as I-Ds. If there is a…

If there are those out there then I would not object to those.  I probably wasn't clear enough that I meant to exclude drafts that are for a proprietary purpose rather than proprietary technology as the aim should be widespread adoption.

Jay

---

From: Chris Wright <[email-masked]>
Date: Wed, 31 Jul 2013 01:28:17 +1000

AusRegistry has many EPP extensions for various purposes none of which have ever really been posted as drafts (to the IETF) - if there was to be an effort try to standardise all these things we would very much be interested in submitting relevant ones for consideration.

Thanks

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jay Daley
Sent: Tuesday, 30 July 2013 7:45 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [provreg] EPP extensions working group

Jay

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Jul 2013 00:33:33 +0200

Please post your extensions as internet-drafts, and other registries should do so as well. That would be a good basis for the coordination and collaboration I see now that I *really* think is a big step forward!

   Patrik

---

From: Luis Muñoz <[email-masked]>
Date: Tue, 30 Jul 2013 18:35:22 -0400

> Please post your extensions as internet-drafts, and other registries should do so as well. That would be a good basis for the coordination and collaboration I see now that I *really* think is a big…

I think this should be a requisite for all extensions to be considered by this new WG.

-lem

---

From: Peter Koch <[email-masked]>
Date: Wed, 31 Jul 2013 08:39:43 +0200

> [...] has many EPP extensions for various purposes none of which have ever really been posted as drafts (to the IETF) - if there was to be an effort try to standardise all these things we would very much be interested in submitting relevant ones for consideration.

not picking on any one in particular, but does this include the
willingness to give up the change control to the IETF?

-Peter

---

From: Chris Wright <[email-masked]>
Date: Wed, 31 Jul 2013 20:15:10 +1000

That's an interesting question...

Many of our extensions are in use in the wild, and have been for years now. They are implemented by many registrars, so changing them for the sake of change probably wouldn't go down very well.

If the goal is just to get together a catalogue of EPP extensions, maybe as an IANA registry of some sort or not, would that be valuable enough to meet the goal - otherwise Im wondering, for example, if there are 4 or 5 different IDN extensions (which Im pretty sure there is at least that) - how would we standardise? Do we design a new one from scratch using them all as input? Do we 'vote' on which one to use as the base? Given a lot of us have working registries using our own extensions its going to be hard enough to make a business case for changing as it is, obviously the registry whose extension we choose to standardise to would have an advantage - so perhaps the fairest thing to do would be to design new ones from scratch... but then the only motivation for implementation is that we are now all 'standardised' and that 'perhaps' makes life easier for Registrars (although our experience has been that the more difficult part for registrars is dealing with the different business rules that are out there and the subtle but important differentiations between our systems with respect to interpretations of specifications and where choices are allowed - not which piece of XML to construct at the end - that actually rather trivial). Give all the difference in the way things such as IDNs have been implemented in various registries, I wonder if it would be even possible to standardise such things?

So in short - I don't know... what are we hoping to achieve here?

Thanks

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Koch
Sent: Wednesday, 31 July 2013 4:40 PM
To: [email-masked]
Subject: Re: [provreg] EPP extensions working group

> [...] has many EPP extensions for various purposes none of which have ever really been posted as drafts (to the IETF) - if there was to be an effort try to standardise all these things we would ver…

not picking on any one in particular, but does this include the willingness to give up the change control to the IETF?

-Peter

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 31 Jul 2013 13:43:14 +0200

On 31 jul 2013, at 12:15, Chris Wright <[email-masked]> wrote:

> so changing them for the sake of change probably wouldn't go down very well

True, but new extensions are "invented" by registrars if not every week so every quarter. Not having them documented somewhere would be sad, and increases the risk new extensions are invented.

Whether people are interested in "merging" their extensions, and because of that change their spec/implementation/whatever is a separate story.

On the registrar side, some such changes might be received easily ("oh, .XX is now as .XY and no longer special -- great!"") while on the registry side that is of course more problematic. And if the "merge" implies also registrars must change for both registries, that might also be troublesome.

MY reason for spending energy on these things are:

- Get the existing extensions documented as I-Ds (can be informational -- no change control handed over).

- By having documentation as I-D minimize the risk future extensions solving same problem is created.

- Increase the likelyhood (from zero) that there will be merge between extensions.

   Patrik