Skip to main content

Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-allocation-token-12

Revision differences

Document history

Date Rev. By Action
2018-11-26
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-11-08
12 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-11-05
12 James Galvin Added to session: IETF-103: regext  Tue-1350
2018-10-15
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2018-10-10
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-10-10
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-10-10
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-10-03
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-10-03
12 (System) RFC Editor state changed to EDIT
2018-10-03
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-10-03
12 (System) Announcement was received by RFC Editor
2018-10-03
12 (System) IANA Action state changed to In Progress
2018-10-03
12 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-10-03
12 Cindy Morgan IESG has approved the document
2018-10-03
12 Cindy Morgan Closed "Approve" ballot
2018-10-03
12 Cindy Morgan Ballot approval text was generated
2018-10-03
12 Adam Roach IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2018-10-03
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-10-03
12 Kal Feher New version available: draft-ietf-regext-allocation-token-12.txt
2018-10-03
12 (System) New version approved
2018-10-03
12 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2018-10-03
12 Kal Feher Uploaded new revision
2018-10-02
11 Adam Roach Authors plan to publish draft-ietf-regext-allocation-token-12 with changes related to Ben Campbell's ballot comments.
2018-10-02
11 Adam Roach IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2018-09-20
11 Adam Roach Pinged authors September 20th to inquire about whether to expect updates based on Ben Campbell's review.
2018-09-04
11 James Gould New version available: draft-ietf-regext-allocation-token-11.txt
2018-09-04
11 (System) New version approved
2018-09-04
11 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2018-09-04
11 James Gould Uploaded new revision
2018-08-31
10 Benjamin Kaduk
[Ballot comment]
Thank you for resolving my DISCUSS points.  Original COMMENT section preserved below.

(section-by-section)

Section 1

  A client MUST pass an Allocation Token …
[Ballot comment]
Thank you for resolving my DISCUSS points.  Original COMMENT section preserved below.

(section-by-section)

Section 1

  A client MUST pass an Allocation Token known to the server to be
  authorized to use one of the supported EPP transform commands.  It is
  up to server policy which EPP transform commands and which objects
  require the Allocation Token.

The language could probably be tightened up for greater clarity about when
the MUST applies, and perhaps be consistent about "supported" vs. "require"
between sentences.

Section 1.1

  represents lines returned by a protocol server.  Indentation and
  white space in examples are provided only to illustrate element
  relationships and are not a REQUIRED feature of this protocol.

It would be nice to rephrase this so that "NOT REQUIRED" could be
together/majuscule.  Maybe, "to illustrate element relationships and
implementations are NOT REQUIRED to adhere to such whitespace and
formatting"?

  The XML namespace prefix "allocationToken" is used for the namespace
  "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations
  MUST NOT depend on it and instead employ a proper namespace-aware XML
  parser and serializer to interpret and output the XML documents.

Maybe I'm misunderstanding, but isn't this kind-of inviting sloppy
implementations that don't check?  Sometimes we say things like "this
prefix is used in the examples for concision but actual usage is expected
to vary between fully scoped and shortened versions".

Section 3.1.1

  2.  If an object requires an Allocation Token and the Allocation
      Token does not apply to the object or an object does not require
      an Allocation Token, then the server SHOULD return the
      availability status as unavailable (e.g., "avail" attribute is
      "0" or "false").
It's really unclear why these two cases are not distinguished in a
machine-readable way (i.e., not the text of the reason).  (Also in 3.2.4,
etc.)

Section 3.1.2

  [...] Authorized clients MAY retrieve
  the Allocation Token (Section 2.1) along with the other object
  information using the  element. [...]

The causality here is a bit weird; it seems like the client is requesting
to retrieve the token by including  in its request so
that the server knows to include it in the response (where it is retrieved
from an  element).

  If the query was successful, the server replies with an
    element, as described in
  Section 2.1.

Section 2.1 describes the contents of the element, not how the server
replies with it.  Maybe, "interpreted as described in" would be better?

Section 3.1.3

It would probably be good to have some discussion of why the
query command (as opposed to transform command) does not benefit from
having this additional authorization-checking mechanism.

Section 3.2.1

  The EPP  command provides a transform operation that allows a
  client to create an instance of an object.  In addition to the EPP
  command elements described in an object mapping like [RFC5731], the
  command MUST contain a child

This MUST is only for the cases when an allocation token is to be used,
right?  (Similarly in 3.2.4, etc.)

  element for the client to be authorized to create and allocate the
  object.  If the Allocation Token does not apply to the object, the
  server MUST return an EPP error result code of 2201.

nit: Maybe "supplied Allocation Token"?

Section 3.2.2, 3.2.3, 3.2.5

Similarly to for Section 3.1.3, some text on why the additional
authorization is not useful would be helpful.

Section 4.1

   
     
        Extensible Provisioning Protocol v1.0
        Allocation
        Token Extension.
     
   

nit: are this many line breaks needed?


I also question the minLength of 1 for an allocation token value.
Why couldn't it be more like 16 or even 32?  I would put this in the
DISCUSS section but maybe there are mitgating circumstances I'm unaware of.
2018-08-31
10 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2018-08-22
10 Eric Rescorla [Ballot comment]
Thank you for addressing my DISCUSS
2018-08-22
10 Eric Rescorla [Ballot Position Update] Position for Eric Rescorla has been changed to No Objection from Discuss
2018-08-21
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-08-21
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2018-08-21
10 James Gould New version available: draft-ietf-regext-allocation-token-10.txt
2018-08-21
10 (System) New version approved
2018-08-21
10 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2018-08-21
10 James Gould Uploaded new revision
2018-08-16
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2018-08-16
09 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-08-16
09 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-08-15
09 Warren Kumari
[Ballot comment]
I agree with Ben and Alexey (and others) that it would be helpful for the document to be clearer in the introduction about …
[Ballot comment]
I agree with Ben and Alexey (and others) that it would be helpful for the document to be clearer in the introduction about the motivations (what and why) this is being done.

Also, thanks to Al Morton for the OpsDir review.
2018-08-15
09 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2018-08-15
09 Alissa Cooper [Ballot comment]
BCP 14 can be referenced in the usual way, it doesn't need a URL reference.
2018-08-15
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-08-15
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2018-08-15
09 Ben Campbell
[Ballot comment]
Substantive Comments:

- General:

As far as I can tell, the document doesn't explain what an Allocation Token _is_. It talks about how …
[Ballot comment]
Substantive Comments:

- General:

As far as I can tell, the document doesn't explain what an Allocation Token _is_. It talks about how it is used and what it contains, but I'm not sure what one represents semantically, or how it gets created, destroyed, etc. I see Section 7 mentions that Allocation Tokens are defined elsewhere; is there something that can be referenced? If not, would it be reasonable to add a high level summary to the introduction?

§3.1.1: "Availability of allocation.example and allocation2.example
domain names are based on the Allocation Token ’abc123’"

I'm confused by this, since the example shows a "mismatch" result for allocation.example.

§3.2.1, 2nd paragraph:

I'm confused by the idea of a token mismatch for an object that has not yet been created. (Please see my general comment; some discussion of the lifecycle of allocation tokens would be helpful.)

Editorial Comments:

§1.1, last paragraph: The "REQUIRED" seems like a statement of fact.

§3.1.1: "If an object requires an Allocation Token and the Allocation
      Token does not apply to the object or an object does not require
      an Allocation Token..."
That's hard to parse. Please consider separate cases for "required but does not apply" and "not required".
2018-08-15
09 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2018-08-15
09 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-08-15
09 Benjamin Kaduk
[Ballot discuss]
(I agree with Ekr's DISCUSS about these being bearer tokens and am happy to
see the discussion on improving the text there.)

There …
[Ballot discuss]
(I agree with Ekr's DISCUSS about these being bearer tokens and am happy to
see the discussion on improving the text there.)

There are a couple of other things that I seek discussion on:

The document itself does very little to motivate the addition of the
allocation token, from a security point of view.  In what security model is
there a security advantage from having this sort of single-use
authorization token as opposed to using existing authentication and
authorization methods?  The use case of a premium domain-name auction that
came up in Ekr's ballot thread is actually quite enlightening, in that the
token allows for the authorization to be granted to the winner of an
auction even in the case where the winning bidder and the current
registration owner do not have any common authentication or authorization
infrastructure (other than for the auction and its payment itself).  Some
generalization of these considerations into a model that matches the
generalized functionality in the draft would be a quite helpful addition.
This could also be leveraged in the discussion of why the allocation token
is not needed in the various commands for which its usage is not provided
(mentioned in my COMMENT).

I also request changes to the examples (or the discussion surrounding them).
Using "abc123" as the example allocation token is probably unwise, as that
value provides none of the properties we desire from allocation tokens.
If you don't want to use an actual random-looking (e.g., self-encrypted
server-generated) or signed value because it makes the examples too long,
at least provide some text indicating that "abc123" is a placeholder and
real tokens should have a different structure.
Similarly, the passwords used in the examples hardly have enough entropy to
be considered secure by modern standards.
2018-08-15
09 Benjamin Kaduk
[Ballot comment]
(section-by-section)

Section 1

  A client MUST pass an Allocation Token known to the server to be
  authorized to use one of …
[Ballot comment]
(section-by-section)

Section 1

  A client MUST pass an Allocation Token known to the server to be
  authorized to use one of the supported EPP transform commands.  It is
  up to server policy which EPP transform commands and which objects
  require the Allocation Token.

The language could probably be tightened up for greater clarity about when
the MUST applies, and perhaps be consistent about "supported" vs. "require"
between sentences.

Section 1.1

  represents lines returned by a protocol server.  Indentation and
  white space in examples are provided only to illustrate element
  relationships and are not a REQUIRED feature of this protocol.

It would be nice to rephrase this so that "NOT REQUIRED" could be
together/majuscule.  Maybe, "to illustrate element relationships and
implementations are NOT REQUIRED to adhere to such whitespace and
formatting"?

  The XML namespace prefix "allocationToken" is used for the namespace
  "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations
  MUST NOT depend on it and instead employ a proper namespace-aware XML
  parser and serializer to interpret and output the XML documents.

Maybe I'm misunderstanding, but isn't this kind-of inviting sloppy
implementations that don't check?  Sometimes we say things like "this
prefix is used in the examples for concision but actual usage is expected
to vary between fully scoped and shortened versions".

Section 3.1.1

  2.  If an object requires an Allocation Token and the Allocation
      Token does not apply to the object or an object does not require
      an Allocation Token, then the server SHOULD return the
      availability status as unavailable (e.g., "avail" attribute is
      "0" or "false").
It's really unclear why these two cases are not distinguished in a
machine-readable way (i.e., not the text of the reason).  (Also in 3.2.4,
etc.)

Section 3.1.2

  [...] Authorized clients MAY retrieve
  the Allocation Token (Section 2.1) along with the other object
  information using the  element. [...]

The causality here is a bit weird; it seems like the client is requesting
to retrieve the token by including  in its request so
that the server knows to include it in the response (where it is retrieved
from an  element).

  If the query was successful, the server replies with an
    element, as described in
  Section 2.1.

Section 2.1 describes the contents of the element, not how the server
replies with it.  Maybe, "interpreted as described in" would be better?

Section 3.1.3

It would probably be good to have some discussion of why the
query command (as opposed to transform command) does not benefit from
having this additional authorization-checking mechanism.

Section 3.2.1

  The EPP  command provides a transform operation that allows a
  client to create an instance of an object.  In addition to the EPP
  command elements described in an object mapping like [RFC5731], the
  command MUST contain a child

This MUST is only for the cases when an allocation token is to be used,
right?  (Similarly in 3.2.4, etc.)

  element for the client to be authorized to create and allocate the
  object.  If the Allocation Token does not apply to the object, the
  server MUST return an EPP error result code of 2201.

nit: Maybe "supplied Allocation Token"?

Section 3.2.2, 3.2.3, 3.2.5

Similarly to for Section 3.1.3, some text on why the additional
authorization is not useful would be helpful.

Section 4.1

   
     
        Extensible Provisioning Protocol v1.0
        Allocation
        Token Extension.
     
   

nit: are this many line breaks needed?


I also question the minLength of 1 for an allocation token value.
Why couldn't it be more like 16 or even 32?  I would put this in the
DISCUSS section but maybe there are mitgating circumstances I'm unaware of.
2018-08-15
09 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2018-08-15
09 Eric Rescorla
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3061


These are bearer tokens and therefore I believe transport encryption
needs to be required in S …
[Ballot discuss]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3061


These are bearer tokens and therefore I believe transport encryption
needs to be required in S 7, not just listed as should (which isn't
even normative in this context).
2018-08-15
09 Eric Rescorla
[Ballot comment]
S 3.2.4.
>      like [RFC5731], the command MUST contain a child
>      element for the client to …
[Ballot comment]
S 3.2.4.
>      like [RFC5731], the command MUST contain a child
>      element for the client to be
>      authorized to transfer and allocate the object.  The authorization
>      associated with the Allocation Token is in addition to and does not
>      replace the authorization mechanism defined for the object's
>      request command.  If the Allocation Token is invalid or

I'm having trouble processing this statement. Can you explain in more
detail what the two access control checks are here.


S 7.
>      specifications apply to this specification as well.

>      The mapping acts as a conduit for the passing of Allocation Tokens
>      between a client and a server.  The definition of the Allocation
>      Token is defined outside of this mapping.  The following are security
>      considerations in the definition and use of an Allocation Token:

Do you want to use normative language here?


S 7.
>      3.  An Allocation Token should have a limited life with some form of
>          expiry in the Allocation Token if generated by a trusted 3rd
>          third party, or with a server-side expiry if generated by the
>          server.
>      4.  An Allocation Token should use a strong random value if it is
>          based on an unsigned code.

What is an "unsigned code"?
2018-08-15
09 Eric Rescorla [Ballot Position Update] New position, Discuss, has been recorded for Eric Rescorla
2018-08-14
09 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-08-14
09 Alexey Melnikov
[Ballot comment]
I am looking forward to reading answers to Mirja's questions.

I think the Introduction section can be improved in explaining how allocation token …
[Ballot comment]
I am looking forward to reading answers to Mirja's questions.

I think the Introduction section can be improved in explaining how allocation token is used and why it is needed.
2018-08-14
09 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2018-08-13
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-08-08
09 Adam Roach IESG state changed to IESG Evaluation from Waiting for Writeup
2018-08-06
09 Mirja Kühlewind
[Ballot comment]
Two quick questions (and I'm really no expert here, so these questions might be stupid):

1) Why should the check return 'unavailable' if …
[Ballot comment]
Two quick questions (and I'm really no expert here, so these questions might be stupid):

1) Why should the check return 'unavailable' if the object does not require an Allocation Token but the check is send with an Allocation Token (sec 3.1.1)? Is that obvious to everybody else but me or should that maybe be further explained in the doc? And inline with that, why is it not a MUST to return 'unavailable' if a Token is required but the sent token doesn't match?

2) Why is this mechanism not applied to delete, renew, and update?
2018-08-06
09 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-08-05
09 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list.
2018-08-03
09 Cindy Morgan Placed on agenda for telechat - 2018-08-16
2018-08-03
09 Adam Roach Ballot has been issued
2018-08-03
09 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2018-08-03
09 Adam Roach Created "Approve" ballot
2018-08-03
09 Adam Roach Ballot writeup was changed
2018-08-03
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-08-03
09 James Gould New version available: draft-ietf-regext-allocation-token-09.txt
2018-08-03
09 (System) New version approved
2018-08-03
09 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2018-08-03
09 James Gould Uploaded new revision
2018-08-03
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-08-02
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg.
2018-08-01
08 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-08-01
08 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-allocation-token-08. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-regext-allocation-token-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the ns registry of the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

a single new registration is to be made as follows:

ID: allocationToken-1.0
URI: urn:ietf:params:xml:ns:allocationToken-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the schema registry of the IETF XML Registry located at:

https://www.iana.org/assignments/xml-registry/

the current document requests the following registration:

URI: ietf:params:xml:ns:allocationToken-1.0
Registrant Contact: IESG
XML: See the "Formal Syntax" section of this document.

IANA Question --> Is the URI correct? Do the authors actually intend that the registration be:

ID: allocationToken-1.0
URI: urn:ietf:params:xml:schema:allocationToken-1.0
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As before, this document requests registrations in a Specification Required (see RFC 8126) registry, so we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry on the Extensions for the Extensible Provisioning Protocol (EPP) registry page located at:

https://www.iana.org/assignments/epp-extensions/

a single, new registration is to be made as follows:

Name of Extension: Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
Document Status: Standards Track
Reference: [ RFC-to-be ]
Registrant: IESG [ iesg@ietf.org ]
TLDs: Any
IPR Disclosure: None
Status: Active
Notes: None

As before, this document requests registrations in a Specification Required (see RFC 8126) registry, so we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-07-23
08 Al Morton Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Al Morton. Sent review to list.
2018-07-19
08 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-07-19
08 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2018-07-19
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2018-07-19
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to David Mandelberg
2018-07-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2018-07-17
08 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Al Morton
2018-07-14
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2018-07-14
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2018-08-03):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, regext-chairs@ietf.org, pm@dotandco.com, draft-ietf-regext-allocation-token@ietf.org, Patrick …
The following Last Call announcement was sent out (ends 2018-08-03):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, regext-chairs@ietf.org, pm@dotandco.com, draft-ietf-regext-allocation-token@ietf.org, Patrick Mevzek , regext@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Allocation Token Extension for the Extensible Provisioning Protocol (EPP)) to Proposed Standard


The IESG has received a request from the Registration Protocols Extensions WG
(regext) to consider the following document: - 'Allocation Token Extension
for the Extensible Provisioning Protocol
  (EPP)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-regext-allocation-token/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-07-14
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2018-07-14
08 Adam Roach Last call announcement was changed
2018-07-14
08 Adam Roach Note: AD review is at https://mailarchive.ietf.org/arch/msg/regext/t5hMzFzt6JX_Iwg0RiOl8_DrduM
2018-07-14
08 Adam Roach Last call was requested
2018-07-14
08 Adam Roach Last call announcement was generated
2018-07-14
08 Adam Roach Ballot approval text was generated
2018-07-14
08 Adam Roach Ballot writeup was generated
2018-07-14
08 Adam Roach
Secretariat: To accommodate the fact that this last call will start during IETF meeting week, please ensure that it ends on August 3rd or later. …
Secretariat: To accommodate the fact that this last call will start during IETF meeting week, please ensure that it ends on August 3rd or later. Thanks.
2018-07-14
08 Adam Roach IESG state changed to Last Call Requested from Publication Requested
2018-06-15
08 Antoin Verschuren
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 …
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.


2018-06-15
08 Antoin Verschuren Responsible AD changed to Adam Roach
2018-06-15
08 Antoin Verschuren IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-06-15
08 Antoin Verschuren IESG state changed to Publication Requested
2018-06-15
08 Antoin Verschuren IESG process started in state Publication Requested
2018-06-08
08 Patrick Mevzek Changed document writeup
2018-05-16
08 James Gould New version available: draft-ietf-regext-allocation-token-08.txt
2018-05-16
08 (System) New version approved
2018-05-16
08 (System) Request for posting confirmation emailed to previous authors: regext-chairs@ietf.org, Kal Feher , James Gould
2018-05-16
08 James Gould Uploaded new revision
2018-04-18
07 James Gould New version available: draft-ietf-regext-allocation-token-07.txt
2018-04-18
07 (System) New version approved
2018-04-18
07 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2018-04-18
07 James Gould Uploaded new revision
2018-04-06
06 Antoin Verschuren IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-04-06
06 James Galvin Notification list changed to Patrick Mevzek <patrick+ietf@deepcore.org> from " rcarney@godaddy.com" <rcarney@godaddy.com>, Patrick Mevzek <patrick+ietf@deepcore.org>
2018-03-08
06 Patrick Mevzek Document shepherd email changed
2018-03-08
06 James Galvin Notification list changed to " rcarney@godaddy.com" <rcarney@godaddy.com>, Patrick Mevzek <patrick+ietf@deepcore.org> from " rcarney@godaddy.com" <rcarney@godaddy.com>
2018-03-08
06 James Galvin Document shepherd changed to Patrick Mevzek
2018-02-09
06 Antoin Verschuren Document shepherd changed to (None)
2018-01-29
06 James Gould New version available: draft-ietf-regext-allocation-token-06.txt
2018-01-29
06 (System) New version approved
2018-01-29
06 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2018-01-29
06 James Gould Uploaded new revision
2018-01-26
05 James Galvin Notification list changed to " rcarney@godaddy.com" <rcarney@godaddy.com>
2018-01-26
05 James Galvin Document shepherd changed to rcarney@godaddy.com
2018-01-12
05 Antoin Verschuren Requesting volunteers as a document shepherd.
2018-01-12
05 Antoin Verschuren IETF WG state changed to In WG Last Call from WG Document
2018-01-02
05 James Gould New version available: draft-ietf-regext-allocation-token-05.txt
2018-01-02
05 (System) New version approved
2018-01-02
05 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2018-01-02
05 James Gould Uploaded new revision
2017-10-18
04 James Gould New version available: draft-ietf-regext-allocation-token-04.txt
2017-10-18
04 (System) New version approved
2017-10-18
04 (System) Request for posting confirmation emailed to previous authors: Kal Feher , James Gould
2017-10-18
04 James Gould Uploaded new revision
2017-07-03
03 James Gould New version available: draft-ietf-regext-allocation-token-03.txt
2017-07-03
03 (System) New version approved
2017-07-03
03 (System) Request for posting confirmation emailed to previous authors: regext-chairs@ietf.org, James Gould , Sharon Wodjenski
2017-07-03
03 James Gould Uploaded new revision
2017-06-23
02 James Gould New version available: draft-ietf-regext-allocation-token-02.txt
2017-06-23
02 (System) New version approved
2017-06-23
02 (System) Request for posting confirmation emailed to previous authors: regext-chairs@ietf.org, James Gould , Sharon Wodjenski
2017-06-23
02 James Gould Uploaded new revision
2017-04-17
01 James Gould New version available: draft-ietf-regext-allocation-token-01.txt
2017-04-17
01 (System) New version approved
2017-04-17
01 (System) Request for posting confirmation emailed to previous authors: regext-chairs@ietf.org, James Gould , Sharon Wodjenski
2017-04-17
01 James Gould Uploaded new revision
2017-04-17
00 (System) Document has expired
2016-11-14
00 Antoin Verschuren Added to session: IETF-97: regext  Fri-0930
2016-10-21
00 Antoin Verschuren Changed consensus to Yes from Unknown
2016-10-21
00 Antoin Verschuren Intended Status changed to Proposed Standard from None
2016-10-21
00 Antoin Verschuren This document now replaces draft-gould-allocation-token instead of None
2016-10-14
00 James Gould New version available: draft-ietf-regext-allocation-token-00.txt
2016-10-14
00 (System) WG -00 approved
2016-10-14
00 James Gould Set submitter to "James Gould ", replaces to (none) and sent approval email to group chairs: regext-chairs@ietf.org
2016-10-14
00 James Gould Uploaded new revision