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 |