Organization Extension for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-org-ext-11
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-04-01
|
11 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-03-05
|
11 | Antoin Verschuren | Added to session: IETF-104: regext Mon-1350 |
2019-02-18
|
11 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-02-02
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-12-28
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-12-27
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-12-26
|
11 | (System) | IANA Action state changed to Waiting on Authors from Waiting on RFC Editor |
2018-12-26
|
11 | (System) | IANA Action state changed to Waiting on Authors |
2018-12-21
|
11 | (System) | RFC Editor state changed to EDIT |
2018-12-21
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-12-21
|
11 | (System) | Announcement was received by RFC Editor |
2018-12-21
|
11 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-12-21
|
11 | Cindy Morgan | IESG has approved the document |
2018-12-21
|
11 | Cindy Morgan | Closed "Approve" ballot |
2018-12-21
|
11 | Cindy Morgan | Ballot approval text was generated |
2018-12-21
|
11 | Adam Roach | RFC Editor Note was changed |
2018-12-21
|
11 | Adam Roach | RFC Editor Note for ballot was generated |
2018-12-21
|
11 | Adam Roach | RFC Editor Note for ballot was generated |
2018-12-21
|
11 | Adam Roach | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-12-04
|
11 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-11.txt |
2018-12-04
|
11 | (System) | New version approved |
2018-12-04
|
11 | (System) | Request for posting confirmation emailed to previous authors: James Gould , Linlin Zhou , Junkai Wei , Jiankang Yao , Ning Kong |
2018-12-04
|
11 | Linlin Zhou | Uploaded new revision |
2018-11-29
|
10 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss points! [Original Comment section preserved below] Section 1 In the business model of domain registration, we … [Ballot comment] Thank you for addressing my Discuss points! [Original Comment section preserved below] Section 1 In the business model of domain registration, we usually have 3 roles of entities: a registrant, a registrar and a registry. There may be other roles of entities involved in the domain registration process which are not formally defined, such as resellers, DNS service operators, privacy proxies, etc. nit: Perhaps I am misreading, but are we not going to formally define these entities in the next paragraph (in which case "yet" might be worth adding)? An organization mapping object defined in [ID.draft-ietf-regext-org] SHOULD be created first. The organization information specified in this document MUST reference the existing organization identifier. What does "first" refer to? "prior to the use of that object"? Section 2 The XML namespace prefix "orgext" is used, 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. [This could probably be written more clearly; see my comment on the companion document] Section 9 IIRC the authorization model for EPP does not allow arbitrary clients to retrieve information about arbitrary (unrelated) domains. If that's not the case, there would be privacy considerations with respect to exposing the linkages of the organization mappings (and roles). |
2018-11-29
|
10 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2018-11-29
|
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-11-29
|
10 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-11-29
|
10 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-10.txt |
2018-11-29
|
10 | (System) | New version approved |
2018-11-29
|
10 | (System) | Request for posting confirmation emailed to previous authors: James Gould , Linlin Zhou , Junkai Wei , Jiankang Yao , Ning Kong |
2018-11-29
|
10 | Linlin Zhou | Uploaded new revision |
2018-11-05
|
09 | James Galvin | Added to session: IETF-103: regext Tue-1350 |
2018-10-25
|
09 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-10-25
|
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2018-10-24
|
09 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2018-10-24
|
09 | Spencer Dawkins | [Ballot comment] If "huh?" was a ballot position, I would have used it. I'm actually too confused to ballot Discuss :-) I see several subsections … [Ballot comment] If "huh?" was a ballot position, I would have used it. I'm actually too confused to ballot Discuss :-) I see several subsections of the form This extension does not add any elements to the EPP command or response described in the EPP object mapping. I see other subsections in the same section that say what the extension DOES, not just what the extension does not do. Is there anything that can be included in these sections to tell the reader more about what the effect of using the extension actually is? |
2018-10-24
|
09 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
2018-10-24
|
09 | Spencer Dawkins | [Ballot comment] If "huh?" was a ballot position, I would have used it. I'm actually too confused to ballot DIscuss :-) I see several subsections … [Ballot comment] If "huh?" was a ballot position, I would have used it. I'm actually too confused to ballot DIscuss :-) I see several subsections of the form This extension does not add any elements to the EPP command or response described in the EPP object mapping. I see other subsections in the same section that say what the extension DOES, not just what the extension does not do. Is there anything that can be included in these sections to tell the reader more about what the effect of using the extension actually is? |
2018-10-24
|
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-10-24
|
09 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-10-24
|
09 | Eric Rescorla | [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3938 COMMENTS S 4.2.1. > C: fooBAR > C: … [Ballot comment] Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3938 COMMENTS S 4.2.1. > C: fooBAR > C: > C: > C: > C: > C: <orgext:create FWIW, this would be easier to read if the new fields were decorated in some way. |
2018-10-24
|
09 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-10-24
|
09 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-10-24
|
09 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-10-24
|
09 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-10-23
|
09 | Ben Campbell | [Ballot comment] Thanks for the work on this. I have a few comments: *** Substantive Comments *** §1: "An organization mapping object defined in [ID. … [Ballot comment] Thanks for the work on this. I have a few comments: *** Substantive Comments *** §1: "An organization mapping object defined in [ID.draft-ietf-regext-org] SHOULD be created first." First before what? *** Editorial Comments *** - General: I'm a little confused by the split in material between draft-ietf-regext-org and draft-ietf-regext-org-ext, especially how the command mapping and related info seems to span both documents. It seems a bit reader-unfriendly. But it's late enough in the process that it's probably not worth changing. - Abstract: Please expand EPP on first mention both in the abstract and in the body. §2, 3rd paragraph: I know we are not consistent about this, but I find the word “conforming” to be a red flag. Standards track RFCs should be about interoperability, not conformance. I suggest striking all after “presented”. |
2018-10-23
|
09 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2018-10-23
|
09 | Benjamin Kaduk | [Ballot discuss] I have two points that I would like to discuss. It is more likely than not that at least one of them merely … [Ballot discuss] I have two points that I would like to discuss. It is more likely than not that at least one of them merely reflects my confusion and is a non-issue, but I would like to get these at least clarified. First, the examples throughout the document use organization identifiers like "myreseller" or "myproxy". This seems to me to be highly confusing, since these IDs are supposed to be server-unique values per organization, and are highly unlikely to be "my" reseller/proxy/etc. for all the entries in the registry. If I understand things correctly, the example IDs should instead be company-name-like values or "random" numbers or similar (or combination thereof). Second, I am unsure of the semantics relating to role types, especially as they interact with the command. Various aspects of the examples seem to imply that it is only permitted to have at most one organization mapping of a given role type (i.e., one reseller, one proxy, etc.). In particular, the element seems to be using the role attribute to determine which is being changed (with the new value being provided in the element body), and the element is providing with only the role attribute and no body to identify a specific organization to remove. If this reading of the document is correct, then I would expect the limitation to be called out more clearly, especially as it would seem to prevent a domain owner from (e.g.) using multiple DNS service operators. |
2018-10-23
|
09 | Benjamin Kaduk | [Ballot comment] Section 1 In the business model of domain registration, we usually have 3 roles of entities: a registrant, a registrar and … [Ballot comment] Section 1 In the business model of domain registration, we usually have 3 roles of entities: a registrant, a registrar and a registry. There may be other roles of entities involved in the domain registration process which are not formally defined, such as resellers, DNS service operators, privacy proxies, etc. nit: Perhaps I am misreading, but are we not going to formally define these entities in the next paragraph (in which case "yet" might be worth adding)? An organization mapping object defined in [ID.draft-ietf-regext-org] SHOULD be created first. The organization information specified in this document MUST reference the existing organization identifier. What does "first" refer to? "prior to the use of that object"? Section 2 The XML namespace prefix "orgext" is used, 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. [This could probably be written more clearly; see my comment on the companion document] Section 9 IIRC the authorization model for EPP does not allow arbitrary clients to retrieve information about arbitrary (unrelated) domains. If that's not the case, there would be privacy considerations with respect to exposing the linkages of the organization mappings (and roles). |
2018-10-23
|
09 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2018-10-19
|
09 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-10-11
|
09 | Sabrina Tanamal | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
2018-10-08
|
09 | Amy Vezza | Placed on agenda for telechat - 2018-10-25 |
2018-10-08
|
09 | Adam Roach | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-10-08
|
09 | Adam Roach | Ballot has been issued |
2018-10-08
|
09 | Adam Roach | [Ballot Position Update] New position, Yes, has been recorded for Adam Roach |
2018-10-08
|
09 | Adam Roach | Created "Approve" ballot |
2018-10-08
|
09 | Adam Roach | Ballot writeup was changed |
2018-10-08
|
09 | Dan Romascanu | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. Sent review to list. |
2018-10-08
|
09 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-10-05
|
09 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-10-05
|
09 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-regext-org-ext-09. 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-org-ext-09. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the ns registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single, new registration will be made as follows: ID: epp:orgext-1.0 URI: urn:ietf:params:xml:ns:epp:orgext-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 also on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a single, new registration will be made as follows: ID: epp:orgext-1.0 URI: urn:ietf:params:xml:schema:epp:orgext-1.0 Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this request also 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. Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at: https://www.iana.org/assignments/epp-extensions/ a single, new registration will be made as follows: Name of Extension: Organization Extension for the Extensible Provisioning Protocol (EPP) Document Status: [ To be taken from the published document ] Reference: [ RFC-to-be ] Registrant: IESG [ iesg@ietf.org ] TLDs: Any IPR Disclosure: None Status: Active Notes: None As this request also 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. 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-10-04
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2018-10-04
|
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Dan Romascanu |
2018-10-04
|
09 | Leif Johansson | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Leif Johansson. Sent review to list. |
2018-09-27
|
09 | Jari Arkko | Request for Last Call review by GENART Completed: Ready. Reviewer: Jari Arkko. Sent review to list. |
2018-09-27
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2018-09-27
|
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jari Arkko |
2018-09-27
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Leif Johansson |
2018-09-27
|
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Leif Johansson |
2018-09-24
|
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-09-24
|
09 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-10-08): From: The IESG To: IETF-Announce CC: adam@nostrum.com, draft-ietf-regext-org-ext@ietf.org, regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, Pieter … The following Last Call announcement was sent out (ends 2018-10-08): From: The IESG To: IETF-Announce CC: adam@nostrum.com, draft-ietf-regext-org-ext@ietf.org, regext-chairs@ietf.org, pieter.vandepitte@dnsbelgium.be, Pieter Vandepitte , regext@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Organization 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: - 'Organization 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-10-08. 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 extension to EPP object mappings, which is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-regext-org-ext/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-09-24
|
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-09-24
|
09 | Amy Vezza | Last call announcement was changed |
2018-09-23
|
09 | Adam Roach | Last call was requested |
2018-09-23
|
09 | Adam Roach | Last call announcement was generated |
2018-09-23
|
09 | Adam Roach | Ballot approval text was generated |
2018-09-23
|
09 | Adam Roach | Ballot writeup was generated |
2018-09-23
|
09 | Adam Roach | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-08-23
|
09 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-09.txt |
2018-08-23
|
09 | (System) | New version approved |
2018-08-23
|
09 | (System) | Request for posting confirmation emailed to previous authors: James Gould , Linlin Zhou , Junkai Wei , Jiankang Yao , Ning Kong |
2018-08-23
|
09 | Linlin Zhou | Uploaded new revision |
2018-08-19
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-08-19
|
08 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-08.txt |
2018-08-19
|
08 | (System) | New version approved |
2018-08-19
|
08 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Junkai Wei , regext-chairs@ietf.org, Linlin Zhou , James Gould , Ning Kong |
2018-08-19
|
08 | Linlin Zhou | Uploaded new revision |
2018-08-10
|
07 | Adam Roach | Awaiting document changes reflecting outcome of discussion of AD review. |
2018-08-10
|
07 | Adam Roach | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-07-26
|
07 | Adam Roach | IESG state changed to AD Evaluation from Publication Requested |
2018-07-13
|
07 | Antoin Verschuren | This is a write-up for the draft-ietf-regext-org-08 and draft-ietf-regext-org-ext-07 documents as they belong together and were reviewed and treated as one work item. 1. Summary … This is a write-up for the draft-ietf-regext-org-08 and draft-ietf-regext-org-ext-07 documents as they belong together and were reviewed and treated as one work item. 1. Summary The document shepherd is Pieter Vandepitte, pieter.vandepitte@dnsbelgium.be The responsible Area Director is Adam Roach, adam@nostrum.com The documents are submitted for consideration as a Proposed Standard: they have received community review and are of interest to multiple parties as they cover a basic need among domain name registrars and registries. Original work for the documents started as a need to register resellers for domain names to be represented in Whois and RDAP. The working group concluded that the objective was too limited to justify the introduction of a new EPP object, as they remarked that future organization roles other than resellers would each require their own EPP object. Furthermore, if each role would be represented by its own object, it would lead to a proliferation of different objects, some of them representing the same organization. This would make it hard to maintain and potentially lead to errors. Therefore, these Internet drafts define an organization object which can be assigned multiple roles, and role types are standardized in an IANA registry to prevent a proliferation of role types across registries. The draft-ietf-regext-org-08 document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects stored in a shared central repository. Specified in Extensible Markup Language (XML), this extended mapping is applied to provide additional features required for the provisioning of organizations. The draft-ietf-regext-org-ext-07 document describes an extension to EPP object mappings, which is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects. Both documents are an extension of the core EPP specifications in STD 69. They use 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 organization object. Both documents 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. The documents follow the RFC style described in RFC 7322 and do 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 Both documents have been discussed on the mailing lists and various IETF meetings of the regext working group. The authors have addressed all comments and changes have been incorporated in the documents. The documents have been updated several times during the WGLC due to several thorough reviews. Verisign and CNNIC have working implementations of the specifications and at least 2 other Registry operators have plans or are interested in implementing the specifications. 3. Intellectual Property The author has confirmed following BCP 78 and BCP 79 in the document header. No IPR disclosures have been submitted for the documents. 4. Other Points All EPP XML examples have been validated against the XML schema provided in the drafts by the Document Shepherd. Each document requests IANA to register a new XML namespace URI and the XML schemas for the namespace definitions. Additionally it requests IANA to insert the document in the EPP Extension Registry, per RFC 7451. The draft-ietf-regext-org-08 document requests IANA to create a new protocol registry to manage organization roles. All requirements for such a request have been met. A detailed review by IANA is suggested. |
2018-07-13
|
07 | Antoin Verschuren | Responsible AD changed to Adam Roach |
2018-07-13
|
07 | Antoin Verschuren | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-07-13
|
07 | Antoin Verschuren | IESG state changed to Publication Requested |
2018-07-13
|
07 | Antoin Verschuren | IESG process started in state Publication Requested |
2018-07-04
|
07 | Pieter Vandepitte | Changed document writeup |
2018-07-02
|
07 | Pieter Vandepitte | Changed document writeup |
2018-06-14
|
07 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-07.txt |
2018-06-14
|
07 | (System) | New version approved |
2018-06-14
|
07 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Ning Kong , Linlin Zhou , Junkai Wei , James Gould |
2018-06-14
|
07 | Linlin Zhou | Uploaded new revision |
2018-05-11
|
06 | Antoin Verschuren | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2018-05-11
|
06 | Antoin Verschuren | Notification list changed to Pieter Vandepitte <pieter.vandepitte@dnsbelgium.be> |
2018-05-11
|
06 | Antoin Verschuren | Document shepherd changed to Pieter Vandepitte |
2018-05-08
|
06 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-06.txt |
2018-05-08
|
06 | (System) | New version approved |
2018-05-08
|
06 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Ning Kong , Linlin Zhou , Junkai Wei , James Gould |
2018-05-08
|
06 | Linlin Zhou | Uploaded new revision |
2018-05-07
|
05 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-05.txt |
2018-05-07
|
05 | (System) | New version approved |
2018-05-07
|
05 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Ning Kong , Linlin Zhou , Junkai Wei , James Gould |
2018-05-07
|
05 | Linlin Zhou | Uploaded new revision |
2018-05-03
|
04 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-04.txt |
2018-05-03
|
04 | (System) | New version approved |
2018-05-03
|
04 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Ning Kong , Linlin Zhou , Junkai Wei , James Gould |
2018-05-03
|
04 | Linlin Zhou | Uploaded new revision |
2018-04-27
|
03 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-03.txt |
2018-04-27
|
03 | (System) | New version approved |
2018-04-27
|
03 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Ning Kong , Linlin Zhou , Junkai Wei , James Gould |
2018-04-27
|
03 | Linlin Zhou | Uploaded new revision |
2018-04-13
|
02 | Antoin Verschuren | IETF WG state changed to In WG Last Call from WG Document |
2018-04-06
|
02 | James Galvin | Intended Status changed to Proposed Standard from Internet Standard |
2018-02-27
|
02 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-02.txt |
2018-02-27
|
02 | (System) | New version approved |
2018-02-27
|
02 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Ning Kong , Linlin Zhou , Junkai Wei , James Gould |
2018-02-27
|
02 | Linlin Zhou | Uploaded new revision |
2017-12-04
|
01 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-01.txt |
2017-12-04
|
01 | (System) | New version approved |
2017-12-04
|
01 | (System) | Request for posting confirmation emailed to previous authors: XiaoDong Lee , Ning Kong , Linlin Zhou , Junkai Wei , James Gould |
2017-12-04
|
01 | Linlin Zhou | Uploaded new revision |
2017-12-04
|
00 | (System) | Document has expired |
2017-06-02
|
00 | James Galvin | Changed consensus to Yes from Unknown |
2017-06-02
|
00 | James Galvin | Intended Status changed to Internet Standard from None |
2017-06-02
|
00 | James Galvin | Generalized organization approach replaces the reseller approach |
2017-06-02
|
00 | James Galvin | This document now replaces draft-ietf-regext-reseller-ext instead of None |
2017-06-02
|
00 | Linlin Zhou | New version available: draft-ietf-regext-org-ext-00.txt |
2017-06-02
|
00 | (System) | WG -00 approved |
2017-05-11
|
00 | Linlin Zhou | Set submitter to "Linlin Zhou ", replaces to (none) and sent approval email to group chairs: regext-chairs@ietf.org |
2017-05-11
|
00 | Linlin Zhou | Uploaded new revision |