Subject: [ietf-provreg] Proposal for new work

From: Edward Lewis <[email-masked]>
Date: Mon, 25 Jan 2010 11:15:04 -0500

Two weeks ago I floated an idea for an effort to look at updating EPP 
in a new IETF WG.  Last week I was occupied with other things 
including trying to prepare "IRE" for a BoF application.

I think the following areas have promising work items:

1. Moving EPP-related RFCs along the standards track.

I looked back at the published RFCs documenting extensions to EPP and 
found these:

5706 - ENUM Validation Information
4310 - DNSSEC
4114 - E.164 Number Mapping
3915 - Domain Registry Grace Period

All of these are sitting at proposed standard.

2. Documenting more of the extensions on the standards track.

I have heard of (but haven't been able to compile a list of) 
extensions done by registries that have not been documented in RFCs. 
This is not criminal (;)) but one of the desires voiced within 
PROVREG WG (in the early days) was to have a "unified" registration 
protocol.

One beneficiary of this are the commercial registrars who can then 
work with more registries to "sell" more names, with the benefit to 
registries too.  Said just for example.

3. Review of DNSSEC extensions.

This item may not wait for WG formation, but if it is still hanging 
around it would be a "good one."  (BoF application deadline is in 
about 12 hours, so it's tight to try to organize this in a day.)

4. A discussion of the shortcomings of EPP for new registry environments.

This is more or less a EPPbis requirements document, if one at all. 
Between this and the next item, the work isn't necessarily EPP but 
registration improvements in general.

Back to this, I am including this based on comments I heard in the 
CENTR Tech meetings, as well as some registries opting not to use EPP 
- or using EPP "under duress."  I'm not saying anything is the matter 
- it would be good to give these discussions a place to be held.

5. How do we get DNSSEC information (DS RR; DNSKEY RR) into a 
registry in a generalized environment?  EPP has RFC 4310 and the 
4310bis draft, but what about situations in which EPP is not the 
conduit?  Such as non-registrar DNS operators and registries that do 
not have registrars in the architecture?

I'd appreciate commentary on this list of work items.  Perhaps the 
next step is to set up a mail list for this and target having a BoF 
at the summer IETF (in SE Holland - some town whose name I can't 
spell "M-something" without looking at a map).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Mon, 25 Jan 2010 11:59:18 -0500

Ed,

The "I have an extention" bits are fine, but each are a registry's 
dork on the common case. We also need to fake, or figure out, or get 
registrars (and I don't simply mean the 100+ actual registrars in the 
900+ list of ICANN accredited registrars, but ccTLD registrars too) 
into the mix, as they have a many-to-many view absent from registries.

The last time the world was 6 and 60, and the ccTLDs used a bunch of 
stuff, and VGRS used RRP.

Now the world is 60 and 600 (caveat as above for the bogus shell 
registrars, and also above for the ccTLD and their registrars now 
using XML as the syntax and something EPP-esque as the protocol.

Last time we could (and did) submarine the thing into the IETF as a 
small clique of (immanently) prospective and one actual gTLD registry 
operators, within a very ICANN-market specific set of constraints.

This time we should recognized, like escrow, that zone provisioning is 
not restricted to registries with contracts with ICANN, or which have 
agreements with ICANN, but is generalized. The registry for 
a.b.c.d.example could use EPP as could the registrars for a.b.c.d.example.

I'm fine with a mid-year BOF, I don't think there is any compelling 
reason to hurry, as I read the EOI thing as "no delegations till 
2013", and we're not as tightly constrained, by VGRS, by ICANN, by our 
rush for gold and glory (or nominal utility) as we were the last time.

Eric

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 25 Jan 2010 18:03:53 +0100 (CET)

Hi Ed et al.

In the times I was still working with Switch I made a study about 
different implementation variants of the Transfer command. The conclusion 
was that almost every Registry had implemented the Tranfer in a different 
way.

This study might help to englighten some of the shortcomings of EPP.
Unfortunately I only found a Draft Version of that study made in 2006:

   http://ucom.ch/presentations/EPP_Transfer_Variants_20060920.pdf

[Please note, that the information in that document is most likely 
outdated (2006). As it is a draft version, it also contains inaccuracies.]

At some CENTR Tech meeting I presented the results of that study.
If you have a CENTR login, you can find those slides at:

  https://www.centr.org/main/lib/g1/3278-CTR.html

Hope this helps to better understand the problem space.

Have fun!

cheers,
  Bernie

---

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

On Mon, 25 Jan 2010, Edward Lewis wrote:

> Two weeks ago I floated an idea for an effort to look at updating EPP in a 
> new IETF WG.  Last week I was occupied with other things including trying to 
> prepare "IRE" for a BoF application.
>
> I looked back at the published RFCs documenting extensions to EPP and found 
> these:
>
> I have heard of (but haven't been able to compile a list of) extensions done 
> by registries that have not been documented in RFCs. This is not criminal 
> (;)) but one of the desires voiced within PROVREG WG (in the early days) was 
> to have a "unified" registration protocol.
>
> One beneficiary of this are the commercial registrars who can then work with 
> more registries to "sell" more names, with the benefit to registries too. 
> Said just for example.
>
> This item may not wait for WG formation, but if it is still hanging around it 
> would be a "good one."  (BoF application deadline is in about 12 hours, so 
> it's tight to try to organize this in a day.)
>
> This is more or less a EPPbis requirements document, if one at all. Between 
> this and the next item, the work isn't necessarily EPP but registration 
> improvements in general.
>
> Back to this, I am including this based on comments I heard in the CENTR Tech 
> meetings, as well as some registries opting not to use EPP - or using EPP 
> "under duress."  I'm not saying anything is the matter - it would be good to 
> give these discussions a place to be held.
>
> 5. How do we get DNSSEC information (DS RR; DNSKEY RR) into a registry in a 
> generalized environment?  EPP has RFC 4310 and the 4310bis draft, but what 
> about situations in which EPP is not the conduit?  Such as non-registrar DNS 
> operators and registries that do not have registrars in the architecture?
>
> I'd appreciate commentary on this list of work items.  Perhaps the next step 
> is to set up a mail list for this and target having a BoF at the summer IETF 
> (in SE Holland - some town whose name I can't spell "M-something" without 
> looking at a map).
> --