Re: WG Review: Extensible Provisioning Protocol Extensions (eppext)

--===============4754710326917422642==
Content-Type: multipart/signed; boundary="Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27"; protocol="application/pgp-signature"; micalg=pgp-sha1


--Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

+1

On 22 nov 2013, at 18:20, Hollenbeck, Scott <[email protected]> =
wrote:

> Yay!
>=20
> Scott
>=20
> -----Original Message-----
> From: IETF-Announce [mailto:[email protected]] On Behalf =
Of The IESG
> Sent: Friday, November 22, 2013 12:18 PM
> To: IETF-Announce
> Cc: eppext WG
> Subject: WG Review: Extensible Provisioning Protocol Extensions =
(eppext)
>=20
> A new IETF working group has been proposed in the Applications Area. =
The
> IESG has not made any determination yet. The following draft charter =
was
> submitted, and is provided for informational purposes only. Please =
send
> your comments to the IESG mailing list (iesg at ietf.org) by =
2013-12-02.
>=20
> Extensible Provisioning Protocol Extensions (eppext)
> ------------------------------------------------
> Current Status: Proposed WG
>=20
> Assigned Area Director:
>  Pete Resnick <[email protected]>
>=20
> Charter:
>=20
> 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.
>=20
> 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.
>=20
> 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 additional contact information.
>=20
> EPP is widely implemented by generic top-level domain name registry
> operators. It is also used by multiple country-code top-level domain =
name
> registry operators. The Internet Corporation for Assigned Names and
> Numbers (ICANN) has an active 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 by =
multiple
> operators is only expected to become worse.
>=20
> The goal of the EPP Extensions (eppext) working group is to create an
> IANA registry of EPP extensions and to review specifications of
> extensions for inclusion in the registry. It will accomplish this goal =
in
> two steps:
>=20
> 1. Develop a specification for a registry of and corresponding
> registration procedures for EPP extensions. One proposal is documented =
in
> https://datatracker.ietf.org/doc/draft-hollenbeck-epp-ext-reg/.
>=20
> 2. Produce a small number of extensions based on existing Internet =
Draft
> documents and use the IANA registration process as developed in 1 to
> register those extensions, as follows:
>=20
> DNSSEC key relay: draft-gieben-epp-keyrelay
> (http://datatracker.ietf.org/doc/draft-gieben-epp-keyrelay/)
>=20
> Internationalized domain names: draft-obispo-epp-idn
> (http://datatracker.ietf.org/doc/draft-obispo-epp-idn/)
>=20
> New TLD launch phases: draft-tan-epp-launchphase
> (http://datatracker.ietf.org/doc/draft-tan-epp-launchphase/)
>=20
> Trademark Clearinghouse: draft-lozano-tmch-smd
> (https://datatracker.ietf.org/doc/draft-lozano-tmch-smd/)
>=20
> Note: draft-tan-epp-launchphase has a normative dependency on
> draft-lozano-tmch-smd.
>=20
> Only the development of the registration process and the
> publication/registration of the four extensions noted above are in =
scope
> for the working group. The working group can choose not to publish or
> register one or more of the extensions noted above, but it is out of
> scope to work on other extensions.
>=20
>=20
> Milestones:
>  May 2014 - Extensions registry document to IESG =20
>  Jul 2014 - DNSSEC key relay extension to IESG
>  Jul 2014 - New TLD launch phases extension to IESG
>  Sep 2014 - Internationalized domain names extension to IESG
>=20
>=20
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg


--Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iD8DBQFSkF3SrMabGguI180RAo8+AKCVOXaZp7c0E9gM+bKEaDpMlhrEOwCZAdTA
pCIi3TdxHdBRyhCfyXCUPqA=
=4MeE
-----END PGP SIGNATURE-----

--Apple-Mail=_63952F54-2601-4EDB-9999-FF037833FA27--

--===============4754710326917422642==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============4754710326917422642==--