Skip to main content

Shepherd writeup
draft-ietf-regext-allocation-token

This is the shepherd writeup for draft-ietf-regext-allocation-token-08.txt
after its working group last call.

1. Summary

The document shepherd is Patrick Mevzek, pm@dotandco.com
The responsible Area Director is Adam Roach, adam@nostrum.com

This document is submitted for consideration as a Proposed Standard:
it has received community review and is of interest to multiple
parties as it covers a basic need among domain name registries.

This document describes an Extensible Provisioning Protocol (EPP)
extension for including an Allocation Token in query and transform
commands.  The Allocation Token is used as a credential that
authorizes a client to request the allocation of a specific object
from the server, using one of the EPP transform commands including
create and transfer.

This document is an extension of the core EPP specifications
in STD 69. It uses the framework outlined in RFC 3735
"Guidelines for Extending the Extensible Provisioning Protocol (EPP)",
to extend some EPP operations by exchanging a new piece of information,
the allocation token.

It is written with the usual set of sections in the expected order
like other documents extending EPP, in order to make its reading
simpler for future implementors.
It follows the RFC style described in RFC 7322.

The document does not introduce new security considerations besides
the new existing in the core EPP RFCs.

All references have been identified as either normative or informative.
There are no normative references on documents with unclear state and no
downward normative references.

2. Review and Consensus

First version of the draft was in October 14th, 2016.
It was added in the working group milestones on June 12th, 2017.
The WGLC for its version 6 happened between November 15th, 2017 and January 12th, 2018.

During discussions some edge cases were exposed as being
underspecified by participants in the working group, and the document
has been amended as a result of that to concentrate on its core features
and not introduce unjustified extensibility, based on the author
own knowledge of current registries needs.

There was feedback on the working group mailing-list by multiple
individuals, including some of the designated experts for EPP Extensions
Registry (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml)

The document was also discussed during face to face meetings at IETF 97,
IETF 99, IETF 100, IETF 101, as transcribed in the respective minutes.

Two thorough reviews were communicated during last call, as well
as some other minor edits.

The author addressed all comments raised on the working group
open mailing list during the last call. There are no concerns
about the depth or breadth of the reviews that have been performed.

The document has an "Implementation Status" conforming to RFC 7942
and shows implementations existing already in multiple clients and servers,
both open and proprietary.

It does not affect negatively parties not implementing it,
and did not create major disagreements inside the working group.

3. Intellectual Property

The author has confirmed following BCP 78 and BCP 79 in the document header.
No IPR disclosures have been submitted for this document.

4. Other Points

All EPP XML examples have been validated against the XML schema provided
in the draft by the Document Shepherd.

This document requests IANA to register a new XML namespace URI and the
XML schema for the namespace definitions. Additionally it requests IANA
to insert the document in the EPP Extension Registry, per RFC 7451.


Back