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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Peter Koch
> Sent: Monday, September 23, 2013 1:29 AM
> To: [e-mail]
> Subject: Re: [provreg] Proposed Charter for EPP Extensions (eppext)
> Working Group
> 
> Scott, all,
> 
> > Proposed Charter for EPP Extensions (eppext) Working Group
> 
> looks like a good start for develioping the list discussion into a
> charter.

Thanks for the feedback, Peter.

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

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

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:
> >
> > 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.
> 
> Work on these could actually progress without (1) done and even without
> (1) at all.

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