Subject: [ietf-provreg] a question for the list

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jan 2010 12:03:19 -0500

It's been about 7 years since PROVREG WG closed and about 5 years 
since the IETF has taken on a serious amount of registry-related work 
(such as CRISP).  In that time Scott has shepherded EPP's base 
specification to Full Standard.  By comparison, DNS's original RFCs 
have been elevated to Full Standard without the current process, and 
almost no extensions to DNS have progressed even to Draft Standard. 
I say that to highlight the extent of Scott's effort and achievement.

Currently we have a draft proposing an update to RFC 4310 (DNSSEC in 
EPP), I have been asked about "how to submit" another extension. 
There have been a few other extensions published as RFCs.

EPP is also growing in deployments.  Early it was the registration 
protocol for the ICANN shared registry model but it has been 
spreading to other registries that are not subject to ICANN's 
overview.  With less "evidence" on hand, a few registries have had to 
modify something to get an EPP interface.  I suspect that some of the 
extensions have not been published as RFCs (which is fine, but, it 
would be nice).

Based on this, I wanted to ask the audience of this list if they 
thought it would be a good idea to organize a new WG to cover EPP.  A 
new WG would mean another mail list, as well as the other trappings - 
drafts, charter, BoFs, etc.

I can imagine extensions being discussed here, as well as trying to 
promote the existing ones to Draft and Full.  Also, a document that 
discusses what could have been done better in EPP (as maybe a 
requirements to EPP 2.0).

So - the question here is - is there interest?

Ultimately, there are other registry-specific things to discuss these 
days, discussions that currently have no other appropriate home. 
Such as - getting DNSSEC information into a registry in a generalized 
environment.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email-masked]

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 14 Jan 2010 12:47:55 -0500

Ed,

I think so.

Eric

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 14 Jan 2010 20:42:43 +0200

> I think so.

+1

   paf

---

From: James Gould <[email-masked]>
Date: Thu, 14 Jan 2010 13:50:37 -0500

Edward,

I would like to know more about which extensions would go up the standards
track and what the goals of the WG would be.  We have implemented a set of
custom extensions that might be of interest, but I¹m really not sure.  It
might be best to work on a charter first to determine if there is adequate
work to form a WG. 

-- 

JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email-masked]
Direct: 703.948.3271
Mobile: 703.628.7063

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Jan 2010 12:03:19 -0500
To: EPP Provreg <[email-masked]>
Cc: <[email-masked]>
Subject: [ietf-provreg] a question for the list

---

From: "Michael Young" <[email-masked]>
Date: Thu, 14 Jan 2010 21:48:18 -0500

I second James' questions here, I am not sure a WG is required at this point
but I'd like to see a proposed charter draft as a first step.

Michael Young

From: James Gould [mailto:[email-masked]] 
Sent: Thursday, January 14, 2010 1:51 PM
To: Edward Lewis; EPP Provreg
Subject: Re: [ietf-provreg] a question for the list

Edward,

I would like to know more about which extensions would go up the standards
track and what the goals of the WG would be.  We have implemented a set of
custom extensions that might be of interest, but I'm really not sure.  It
might be best to work on a charter first to determine if there is adequate
work to form a WG.  

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

  _____

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 14 Jan 2010 22:43:56 -0500

> but I'd like to see a proposed charter draft as a first step.

It seems to me that one of Ed's observations might have been a bit too
subtle for some who are less attuned to the IETF processes, so I
thought I'd try to make it more plain.

The DNSEXT WG has as one of its explicit current chartered work items
to move a very long list of RFCs along the standards track.  Whenever
this comes up for review, people nod sagely, say it's all very
important, and say that it should be a charter item.  Yet the moving
along in the standards track seems not to happen.  Very few DNS RFCs
are at the level of STANDARD.  For instance RFC 2181, easily among the
most important of the DNS RFCs I'd expect anyone interested in the
topic to have read, is only at Proposed Standard.  RFC 1982, Serial
Number Arithmetic -- a terribly influential RFC even outside the DNS
-- also stopped at PS.  IXFR is still PS (RFC 1995), as is Notify
(1996).  I could go on, but I guess you get the picture.

By contrast, without any WG and without a great deal of fanfare, EPP
has become an Internet Standard.  I remember confidently predicting at
one point in the past that EPP could never be a Standard because the
community was simply too small.  I am delighted to have been wrong.

So, before anyone produces a draft charter, I'd like to know what
problem we have that is actually going to be solved.  Never mind
charters and so on: if nobody has been interested enough in
documenting their extensions that they've bothered to write an
individual submission Internet Draft, what problem of any conceivable
interest will be solved by spinning up the considerable machinery
necessary actually to charter a working group?  Or, to put this more
negatively, what possible reason is there for me not to stand up in
the BOF and say, "There are no individual drafts, there is no real
problem to be solved here, and therefore setting up a WG is a waste of
the Area's time,"?  

None of this is to say I don't think there's work to be done (or do
think there's such work).  What I think instead is that, if one wants
a WG, one had better have at least prima facie evidence of an
interested community.  So if people are interested, let's see some
drafts.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 15 Jan 2010 07:42:05 +0200

On 15 jan 2010, at 05.43, Andrew Sullivan wrote:

> I'd like to know what
> problem we have that is actually going to be solved.

>From my perspective, there are too many extensions out there.

A WG should:

- Compile a list of extensions that are developed and used by registries
- Evaluate whether any of those implies changes are needed to the core protocol
- If changes are needed, roll those into the protocol itself

All to make epp better and easier to use. It is not fun at the moment.

   Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 15 Jan 2010 02:38:35 -0500

Our universe was 6 and 60. It is now 60 and 600.

We over constrained the end points, and the event model.

We over constrained the transport mappings, the drop pool is an edge 
case, not the general case.

We didn't generalize the syntax to allow "containers" (Zhang/Damaraju).

The syntax wasn't really all that extensible.

We didn't include resellers/members in the end points model, and 
therefore we didn't include routing, settlement, giveup, pricing query 
or subaccounts in the use cases.

Eric

---

From: [email-masked]
Date: Fri, 15 Jan 2010 08:06:47 +0000

> Or, to put this more negatively, what possible reason is there for me
> not to stand up in the BOF and say, "There are no individual drafts,
> there is no real problem to be solved here, and therefore setting up
> a WG is a waste of the Area's time,"? 

I plan to submit an individual draft for a proposed EPP extension within 
the next few weeks.

Ray

---

From: "Marc Groeneweg" <[email-masked]>
Date: Fri, 15 Jan 2010 09:34:57 +0100

> All to make epp better and easier to use. It is not fun at the moment.

Agreed. SIDN as the Dutch registry is implementing EPP at this very
moment. We are going live in March this year. During the development
phase, we have consulted several registries to try to stay in line with
those regarding EPP and extensions. But we have made our own extension
to get domainnames out of quarantine (period after deleting a
domainname) and didn't follow the RRP extension of Verisign (considered
too complex for the job). No RFC planned though for this. Just like
several other registries, we have documented the differences with the
core protocol. I think that when you write an RFC for this, you should
ask yourself if it's going to contribute to all (not just for one
registry) and are we going to make a standard out of this.

The next planned release of our registry system should have a kind of
trade option (transfer and registrant change in one process), which
several other registries have, but which is different in implementation
from each other. The problem there might be in policies just like there
was in the transfer process.

Marc Groeneweg

---

From: Edward Lewis <[email-masked]>
Date: Fri, 15 Jan 2010 09:50:53 -0500

I'd like to second what Eric mentions here - mostly because he and I 
have never discussed this in person before.  For the most part, his 
list is dead-on the same as the one I wrote in my mind recently.

It's not just the extensions that are being written.  It's the angst 
of the growing community I hear.  (See also PAF's note).

At 2:38 -0500 1/15/10, Eric Brunner-Williams wrote:
>therefore we didn't include routing, settlement, giveup, pricing 
>query or subaccounts in the use cases.
>
>Eric

But - next week I hope to cobble together a more complete work load 
list/charter prototype.  (If no one else does one first. ;))
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 15 Jan 2010 16:07:41 +0100

On 15 jan 2010, at 09.34, Marc Groeneweg wrote:

> those regarding EPP and extensions.

And, btw, not all TLDs have publicised documentation for their extensions. .EU require actual payment of the fee to become a registrar before you get the technical documentation. Sure, there is a Net::DRI support for .EU, which one can reverse engineer, but if one would like to know what the details are? Pay first, then you get to know whether you actually are interested in doing it.

Interesting business model.

And, if I am wrong and documentation for .EU exists out there. My apologies (if I get documentation sent to me ;-) ). Enough people have though asked me, and looked for it, that I do not think it exists.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Jan 2010 10:56:38 -0500

On Fri, Jan 15, 2010 at 09:50:53AM -0500, Edward Lewis wrote:
> have never discussed this in person before.  For the most part, his list 
> is dead-on the same as the one I wrote in my mind recently.

Ok, so I'm picking on Ed's message, but several people responded with
similar sorts of arguments, and one at least said an I-D is
forthcoming.  

Since I'm playing devil's advocate, however (and let me emphasise that
I'm pushing mostly because I think the best way to make a strong
argument is to find all its weak points and press on them), where were
these voices when the protocol was moving along the standards track?
I recall submitting an I-D some time ago that argued for some fairly
major changes, some of which were intended to address these issues,
before any movement had happened.  It seemed to me then (as it does
now) that the time to make incompatible changes to a protocol is
before it moves to Draft Standard, not after it has been declared an
Internet Standard.  So I thought I'd propose a number of changes that
I would have found useful, in the hopes of opening a discussion about
the issues.

The response at the time was overwhelmingly that we had EPP, it was
mostly working, and nobody had the energy or interest to open it up to
make it perfect.  Sure, there were issues, but this was the one we had
and so it would be good enough.  Moreover, some said, any attempt to
add a new protocol would surely, for ICANN-constrained registries,
entail running more than one protocol in parallel, which either means
that you're stuck with the functionality actually available or else
that you have to kludge things up to make them backward compatible.
Finally, there was a side chorus claiming that, given the wide
variation in EPP implementations and extensions, EPP isn't really a
protocol anyway and that therefore "improving" it wouldn't work.

What has changed to make those arguments less compelling now that EPP
has become an Internet Standard?

A

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 18 Jan 2010 17:21:13 +0100

> these voices when the protocol was moving along the standards track?

In short, I did rise my voice exactly like this, but the document moved forward, and I thought I was in the minority. I also explicitly then brought up the issue that exist that some policy issues are not well defined, for example on what a transfer (of a domain name) implies regarding sponsor of the contact object that is the holder of the domain.

The conclusion then was that epp _as_defined_ was implemented as nice and clean and obviously works.

The question now is whether we should do eppV2, so I think the questions are different. Or, that I was told ;-)

   Patrik

---

From: James Gould <[email-masked]>
Date: Mon, 18 Jan 2010 14:00:14 -0500

I personally don¹t believe that the creation of a large number of additional
mappings and extensions represents an issue with the base protocol, but more
of meeting one of the goals of the base protocol in being flexible.  There
is no way that everyone could foresee all of the possible needs of a
provisioning system, so the ability to create mappings and extensions
without touching the base protocol is a huge benefit.  I would like to see
as the goal of a working group be the following:

1. Identify the custom EPP mappings and extensions out there.  Look for
overlap and for the potential of some of them moving up the standards track.
2. Identify common patterns followed in creating extensions and mappings and
document them for consistency.  For example, adding a new verb has been done
by creating an extension to an empty update.  I would call the pattern ³New
EPP Verb² or something like that :-)
3. Collaborate on additional mappings and extensions for the standards
track.  I have a few that I would like to discuss around key management but
it would require a good cross-cutting representation of the EPP community.
4. Identify areas of improvement of the base protocol that could be
addressed by common conventions, extensions, or even on update to the base
protocol.

It would be good if each of us could recommend goal items that can be
clearly listed in the charter.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Patrik Fältström <[email-masked]>
Date: Mon, 18 Jan 2010 11:21:13 -0500
To: Andrew Sullivan <[email-masked]>
Cc: EPP Provreg <[email-masked]>
Subject: Re: [ietf-provreg] a question for the list

> these voices when the protocol was moving along the standards track?

In short, I did rise my voice exactly like this, but the document moved
forward, and I thought I was in the minority. I also explicitly then brought
up the issue that exist that some policy issues are not well defined, for
example on what a transfer (of a domain name) implies regarding sponsor of
the contact object that is the holder of the domain.

The conclusion then was that epp _as_defined_ was implemented as nice and
clean and obviously works.

The question now is whether we should do eppV2, so I think the questions are
different. Or, that I was told ;-)

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 19 Jan 2010 08:20:07 +0100

> The question now is whether we should do eppV2, so I think the questions are different. Or, that I was told ;-)

Maybe my wording was badly phrased. And I feel I must clarify:

I do NOT think the move of epp to standard was wrong. The protocol is in wide use. It is usable. We have multiple implementations.

I DO think we should do eppV2 because the deployment and implementation can be better. I claim we can move more today developed extensions to epp to become standard parts of the protocol -- and that way make deployment easier.

    Patrik

---

From: "Michael Young" <[email-masked]>
Date: Tue, 19 Jan 2010 07:54:10 -0500

Perhaps what we need here is an equivalent to DNSOPs for EPP (EPPOPs)?  I
can't help but think that if we were talking about this level of change with
DNS, more than a few operators would get very concerned.

Let's remember that an EPPv2 costs registrars money and time to implement
plus there's risk to changing a core protocol.  I think we need to separate
discussions about updating the core protocol and consolidating efforts
around extensions.  Consolidating efforts around extensions seems like a
reasonable goal in principal to me, changing a core protocol that in use
supporting almost all of the internet is a much more serious objective that
I think needs some serious justification (ie,that vital shortcomings cannot
be addressed through extension work).

Also, we need a representative sample of registrars to weigh in before we
could consider proceeding, after all, they are the client side of this
protocol and their entire infrastructure stands to be effected at some real
$$$ cost.

IMHO, this conversation is very different than building the first EPP
version, now we have real world infrastructure, security and stability to
consider as primary considerations to any core protocol changes. 

Michael Young

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]] 
Sent: Tuesday, January 19, 2010 2:20 AM
To: Andrew Sullivan
Cc: EPP Provreg
Subject: Re: [ietf-provreg] a question for the list

I do NOT think the move of epp to standard was wrong. The protocol is in
wide use. It is usable. We have multiple implementations.

I DO think we should do eppV2 because the deployment and implementation can
be better. I claim we can move more today developed extensions to epp to
become standard parts of the protocol -- and that way make deployment
easier.

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 19 Jan 2010 14:35:54 +0100

On 19 jan 2010, at 13.54, Michael Young wrote:

> I think we need to separate

True, I agree with this view.

I have implemented epp from ground up for .SE, and working on extending for other TLDs

So here is a voice from a registrar that would support _some_ work on synchronization while the cost for even making changes is lower than what it will be to have eep + private extensions in every TLD in the world.

The goal I think should be to be able to use the same epp client and server implementation for more than one TLD.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Jan 2010 09:04:47 -0500

> DNS, more than a few operators would get very concerned.

While I am obviously sympathetic to your argument, using DNS as an
analogue won't work: it's too different.  The DNS is involved in just
about every interaction on the Internet, and it has to be deployed on
nearly every Internet node.  Moreover, most DNS deployments (stub
resolvers) are on the machines of people we have no way of reaching
out and talking to.  Finally, the DNS is an old protocol in Internet
terms, and therefore there is a lot of opportunity for small
carbuncles to have grown on it and become part of the _de facto_
standard, even though said growths are not actually found in any RFC.

None of those is true of EPP: the community is still relatively small,
and because EPP is a two-way protocol with a handshake step and so on,
it is possible to warn clients of an impending change to the protocol.
While provisioning in the DNS is pretty important, it's not core
infrastructure the way resolution in the DNS is, because it's not
directly invoked for every Internet transaction.  And finally, since
the protocol isn't that old, the opportunities for it to have grown
significant differences from the RFCs are fewer (and such cases can,
in any case, be called errors without causing half the installed base
to qualify thereby as "broken").

So, the risk in changing EPP is obviously one of cost and some
disruption; but not "time to reformat the Internet", which is what
major changes to the DNS might entail if not done just right.  In the
DNS, there are some pretty big rewards we'd like to go after, but the
risk is too great so we don't make the changes.  Similar rewards, if
they were available in EPP, might be worth the risk.

A

---

From: "Michael Young" <[email-masked]>
Date: Wed, 20 Jan 2010 10:58:26 -0500

I hear your arguments Andrew and I don't disagree. However I just haven't
seen any issues raised here that says we MUST or even SHOULD change the core
protocol.  The listed issues thus far could all be dealt with using
extensions AND I do agree with forming a concentrated effort around managing
extensions.

To my mind, any changes with the core protocol involves risk and cost to
registrars and registries.  This is why a lot of consideration was given to
the extensions in the first place - to avoid having to jump immediately into
core protocol revision work whenever a new use case comes up.  The real
problem I am hearing here is that we (by "we" I mean the EPP community)
haven't done a good job managing extension work. We need to fix that.

Best Regards,

Michael Young

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]] 
Sent: January-19-10 9:05 AM
To: 'EPP Provreg'
Subject: Re: [ietf-provreg] a question for the list

A

---

From: James Gould <[email-masked]>
Date: Wed, 20 Jan 2010 13:09:02 -0500

I second Michael.  The sponsorship query service could be defined using a
new EPP Mapping and the info command (filters defined in the command
supporting sponsorship information across multiple entity types).  This is
just one example of a use case that could go up the standards track if there
was enough cross-cutting need.  I don¹t personally see a need for this but
others might.  I wouldn¹t touch the base protocol unless it was absolutely
necessary, but to focus on the set of custom mappings and extensions that
have been created and are being created to see if there is more general
interest of moving them up the standards track.  We have many custom
mappings and extensions that might be of interest as well.  Collaboration by
an EPP Working Group would help address the issue of the growing set of
custom EPP mappings and extensions.

-- 

JG 

21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

From: Michael Young <[email-masked]>
Date: Wed, 20 Jan 2010 10:58:26 -0500
To: Andrew Sullivan <[email-masked]>, EPP Provreg <[email-masked]>
Subject: RE: [ietf-provreg] a question for the list

Best Regards,

Michael Young

-----Original Message-----
From: Andrew Sullivan [mailto:[email-masked]]
Sent: January-19-10 9:05 AM
To: 'EPP Provreg'
Subject: Re: [ietf-provreg] a question for the list

A

---

From: Ulrich Wisser <[email-masked]>
Date: Wed, 27 Jan 2010 09:59:13 +0100

Hi,

at .SE we would be interested in a new wg for epp. There are definitely 
blips to solve and extensions to standardize.

We did our own extension for sending messages to registrars in case the 
registry updates any objects. I've seen several registries having such 
an extension. So it seems there is aneed for that.

/Ulrich

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 28 Jan 2010 19:10:01 +0100

Edward Lewis <[email-masked]> 2010-01-14 18:23
> protocol for the ICANN shared registry model but it has been spreading to 
> other registries that are not subject to ICANN's overview.  With less 
> "evidence" on hand, a few registries have had to modify something to get 
> an EPP interface.  I suspect that some of the extensions have not been 
> published as RFCs (which is fine, but, it would be nice).

I confirm (as an EPP client implementor of more than 30 extensions)
that almost all EPP extensions have NOT been published as
RFCs, even as drafts except for a few exceptions, most of the times
unmaitained. Worse than that, as other have said, not all EPP
extensions specifications are available publicly.

> Based on this, I wanted to ask the audience of this list if they thought 
> it would be a good idea to organize a new WG to cover EPP.  

Maybe. Depending on the goals, and indeed on the global reach of
participants to avoid the previous case where ccTLDs have seen EPP as
a purely gTLD thing, before entering the arena with 5 to 10 years of
useless delay.

> requirements to EPP 2.0).

Some of you may recall one of my posting on this list more than one
year ago (!) with a link to some notes I've made as an implementor,
seeing many extensions of various qualities, and the rationale being
them being sometimes some shortcomings in the current EPP.

The document is still at
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt
but I've not worked on it since then. It could be used as a base.

Also in light of the recent DNSSEC discussions, please have a look at
§3.3.2 that deals with some kind of EPP extensions used by some
registries (.CZ and .EU if I recall correctly) for handling key
materials.

And about using EPP for non provisioning operations, see §3.8.3

> So - the question here is - is there interest?

I really believe there are two separate points that may not be good
to deal at the same time in the same place even if there is some
overlap:

- discussion/work on an EPPv2, taking into account some current
shortcomings (such as static list of status codes, domain name
status, contact types ; handling of clTRID, etc... see my draft)

- enhancement of the current state of EPP, without changing its core,
but by taking into account all current extensions and trying to
persuade all stakeholders to work together to make some superseeding
extensions with some factorizations and enhancements (again see my
draft). Or at least producing some strong advises/recommandations to
extensions creator, as RFC3735 is a good starting point but is not
enough.

I'm personnally interested to contribute in both of them, 
but I do not have a lot of free time to invest in them.
I do fear however that,
specially for the second point, even if there is indeed a lot of work
to do technically (meaning that I think many extensions could be made
better), there is a reduced probability that it would be useful in
the sense that, specially without broad participation by the
extension creators themselves, there would be no motivation to change
the current extensions as they are already deployed and working even
if not perfect.
While there was and still is a pressure for some ccTLDs to finally
switch to EPP, in part by their registrars, I do not believe there
will be the same kind of pressure to switch to "better" extensions,
because all serious registrars already adapted their software to take
into account the unavoidable fact that with each TLD there are
specific procedures and extensions to deal with.

-- 
Patrick Mevzek