Extensible Provisioning Protocol (EPP)
draft-hollenbeck-rfc4930bis-02
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
02 | (System) | post-migration administrative database adjustment to the No Objection position for Robert Sparks |
2012-08-22
|
02 | (System) | post-migration administrative database adjustment to the No Objection position for Dan Romascanu |
2009-07-23
|
02 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-07-23
|
02 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-07-23
|
02 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-07-22
|
02 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-07-20
|
02 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-07-20
|
02 | (System) | IANA Action state changed to In Progress |
2009-07-20
|
02 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2009-07-20
|
02 | Cindy Morgan | IESG has approved the document |
2009-07-20
|
02 | Cindy Morgan | Closed "Approve" ballot |
2009-07-18
|
02 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Catherine Meadows. |
2009-07-17
|
02 | (System) | Removed from agenda for telechat - 2009-07-16 |
2009-07-16
|
02 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza |
2009-07-16
|
02 | Robert Sparks | [Note]: 'Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd. Implementation report can be found at <http://www6.ietf.org/iesg/implementation/report-rfc3730-3734.txt>.' added by Robert Sparks |
2009-07-16
|
02 | Robert Sparks | (Capturing this in the tracker) To: ietf-provreg@cafax.se Cc: Chris.Newman@Sun.COM, lisa@osafoundation.org, iesg@ietf.org From: Patrick Mevzek Date: Thu, 18 Dec 2008 18:18:53 +0100 Content-Disposition: inline … (Capturing this in the tracker) To: ietf-provreg@cafax.se Cc: Chris.Newman@Sun.COM, lisa@osafoundation.org, iesg@ietf.org From: Patrick Mevzek Date: Thu, 18 Dec 2008 18:18:53 +0100 Content-Disposition: inline In-Reply-To: <046F43A8D79C794FA4733814869CDF070282A322@dul1wnexmb01.vcorp.ad.vrsn.com> Sender: owner-ietf-provreg@cafax.se User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [ietf-provreg] RE: Standards Track Advancement Request for EPP RFCs Hollenbeck, Scott 2008-12-18 16:16 > If you're asking about overall adoption, I know that it's used by all of > the gTLD operators (it's an ICANN requirement) and many ccTLD operators. > Patrick Mevzek recently reported on recent deployments here: > > http://www.dotandco.com/services/software/Net-DRI/docs/netdri-icann-cair > o-ccnso-techday-200811.html > > Sorry if the URL gets broken across two lines. If that can help, from my software, here are some registries using EPP, sometimes alongside other ancillary protocols, and sometimes still in the process of deploying it (sorry in advance for any error). aero fr re (being currently deployed) ag si (being currently deployed) asia at au be biz br bz cat la cx gs tl ki ms mu nf ht na coop cz eu hn i.3.4.e164.arpa (Infrastructure Enum in Austria) info lc lu me mn mobi name uk no (being currently deployed) nu org pl (over HTTPS) pro pt sc se ch li travel us vc com net cc tv jobs There is also: es (over HTTPS) cn tw im cl ac sh io tm in And I'm sure I've forgotten some... From the ICANN Caïro meeting I can see that even some "small" ccTLD operator are now interested to provide EPP to their registrars (since most registrars are registering in multiple TLDs, it makes sense for them to consolidate their protocols and so it make sense for a registry to suit them). In short there is a massive move towards EPP (we may already have crossed the top of the curve), and no move in the opposite direction (past critics of EPP, specifically in ccTLDs, have changed their minds or at least agreed to move towards EPP) > > 1. Move RFC 4930-4934 to full standard without change. I am > > willing to attempt this, although it's less likely to pass > > IETF last call than the other options due to the obsolescence > > of some of the normative references. > > > > 2. Republish with only references updated. This will require > > somewhat less use of the RFC 3967 procedures and make improve > > the odds of a successful last call. > > > > 3. Republish with references updated and operational > > clarifications; primarily documenting the TLS practices that > > have been used in practice to interoperate. I recognize > > there is some risk that the new TLS practices text will not > > be correct, which is why I've decided I'm willing to let this > > issue pass for a draft->full advancement. IMHO, the problem > > should have been noticed and fixed when advancing to draft so > > any errata could be applied when advancing to full. We > > missed the window where it was most appropriate to fix that > > sort of problem, so we shouldn't hold advancement hostage > > over the issue, IMHO. I can't promise my the rest of the > > IESG will agree, but that's my opinion. > > > > So the steps to advance are: > > > > A. Provide data for the "significant benefit to the Internet" > > litmus test. > > I'll need to > > defend this before the IESG. Besides the number of TLDs/domain names managed through/with EPP, some quick ideas: - native support for IPv6 in hostnames (was added only late in RRP, see RFC3632) - use of XML hence Unicode hence native support for any kind of IDNs (if the unicode string version need to be passed during the exchange, without any encoding) - support of ENUM provision - support of DNSSEC provision - extensibility to cater for needs of current and future TLDs - standardization on an « EPP authcode » needed for domain name transfers, being adopted by more and more TLDs, this simplifies the life of registrants (the merit of this use can be discussed, but at least it is starting to be uniform in multiple TLDs) > > B. Choose option 1-3, publish revised I-Ds as appropriate C. > > It would be very helpful to provide candidate RFC 3967 text > > for the last call notice. > > > > and I'll take it forward from there. > > I'm open to either option 2 or 3. What do others think? From an implementor point of view again, TLS is not a problem for EPP deployment, I mean besides just knowing if the registry verify the client certificate and if so which client certificates issuers the registry accept, that it is enough to fullfill RFC4934 (EPP over TCP). It is far more complicated to enable the interoperability on the protocol level, taking into account each registry EPP extensions and various tweaks in namespaces, ordering, result codes, etc. So I would favor option 2, or after that option 3, so that not too much time is used for TLS which is not a big issue for EPP in my mind. -- Patrick Mevzek |
2009-07-16
|
02 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks |
2009-07-16
|
02 | Dan Romascanu | [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss by Dan Romascanu |
2009-07-16
|
02 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2009-07-16
|
02 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-07-16
|
02 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-07-16
|
02 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2009-07-16
|
02 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko |
2009-07-16
|
02 | Alexey Melnikov | [Note]: 'Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd. Implementation report can be found at <http://www6.ietf.org/iesg/implementation/report-rfc3730-3734.txt>.' added by Alexey Melnikov |
2009-07-16
|
02 | Dan Romascanu | [Ballot discuss] Is there an implementation and interoperability report or some other document that speaks about the 'significant implementation and successful operational experience' has was … [Ballot discuss] Is there an implementation and interoperability report or some other document that speaks about the 'significant implementation and successful operational experience' has was achieved and about the 'significant benefit to the Internet community' brought by this protocol that justify the elevation to the Internet Standard level? I could not find this information in the document or in the PROTO write-up. |
2009-07-16
|
02 | Dan Romascanu | [Ballot Position Update] New position, Discuss, has been recorded by Dan Romascanu |
2009-07-16
|
02 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2009-07-16
|
02 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-07-15
|
02 | Robert Sparks | [Ballot discuss] I expect to clear this discuss after a quick discussion. Would it be easy to pull together an artifact somewhere capturing a sense … [Ballot discuss] I expect to clear this discuss after a quick discussion. Would it be easy to pull together an artifact somewhere capturing a sense of growth of the implementation base and operational experience beyond what's in the original implementation report? |
2009-07-15
|
02 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks |
2009-07-13
|
02 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2009-07-05
|
02 | Alexey Melnikov | [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov |
2009-07-05
|
02 | Alexey Melnikov | Ballot has been issued by Alexey Melnikov |
2009-07-05
|
02 | Alexey Melnikov | Created "Approve" ballot |
2009-07-05
|
02 | Alexey Melnikov | State Changes to IESG Evaluation from Waiting for Writeup by Alexey Melnikov |
2009-07-05
|
02 | Alexey Melnikov | State Change Notice email list have been change to shollenbeck@verisign.com, Ed.Lewis@neustar.biz, chris.newman@sun.com from shollenbeck@verisign.com, chris.newman@sun.com |
2009-07-05
|
02 | Alexey Melnikov | State Change Notice email list have been change to shollenbeck@verisign.com, Ed.Lewis@neustar.biz, chris.newman@sun.com from shollenbeck@verisign.com, chris.newman@sun.com |
2009-07-05
|
02 | Alexey Melnikov | [Note]: 'Edward Lewis <Ed.Lewis@neustar.biz> is the document shepherd.' added by Alexey Melnikov |
2009-07-05
|
02 | Alexey Melnikov | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Edward Lewis (Ed.Lewis@neustar.biz) is the document shepherd for this series of documents. I am the former co-chair of the PROVREG working group that originally worked on the EPP specifications. I have personally reviewed 4930bis, 4931bis, 4932bis, 4933bis, and 4934bis and I believe they are ready for forwarding to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The updates to these documents were announced on the still-open mailing list that was used by the PROVREG working group. The document set has been through three formal review cycles: first for publication at Proposed Standard status, then for publication at Draft Standard status, and finally for publication at Standard status. I have no concerns about the depth or breadth of the reviews that have been performed. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization, or XML? I do not. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I have no specific concerns or issues with any of the documents. An IPR disclosure was filed by VeriSign in 2001 when the documents were first adopted by the PROVREG working group: http://www.ietf.org/ietf/IPR/VERISIGN-EPP There were no issues or concerns with VeriSign's IPR statement. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is currently no working group focused on EPP document progression. Working group consensus to publish the documents as Proposed Standards was strong. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There are no known threatened appeals or extreme discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/.) Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type, and URI type reviews? If the document does not already indicate its intended status at the top of the first page, please indicate the intended status here. The intended status for each document is "Standard". I have personally checked each document using the idnits tool. The following nits were reported: rfc4930bis: OK rfc4931bis: tmp/draft-hollenbeck-rfc4931bis-00.txt(155): Found possible FQDN 'ns1.example1.com' in position 34; this doesn't match RFC2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-hollenbeck-rfc4931bis-00.txt(157): Found possible FQDN 'ns1.example1.com' in position 17; this doesn't match RFC2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-hollenbeck-rfc4931bis-00.txt(158): Found possible FQDN 'ns1.example1.com' in position 32; this doesn't match RFC2606's suggested ".example" or ".example.(com|org|net)". (The author reports that the examples used are deliberate because RFC 2606 doesn't include multiple example domains within a single top-level domain, and that's what was needed in the document.) ** Downref: Normative reference to an Unknown state RFC: RFC 952 rfc4932bis: tmp/draft-hollenbeck-rfc4932bis-00.txt(153): Found possible FQDN 'ns1.example1.com' in position 34; this doesn't match RFC2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-hollenbeck-rfc4932bis-00.txt(155): Found possible FQDN 'ns1.example1.com' in position 17; this doesn't match RFC2606's suggested ".example" or ".example.(com|org|net)". tmp/draft-hollenbeck-rfc4932bis-00.txt(156): Found possible FQDN 'ns1.example1.com' in position 32; this doesn't match RFC2606's suggested ".example" or ".example.(com|org|net)". ** Downref: Normative reference to an Unknown state RFC: RFC 952 ** Downref: Normative reference to an Draft Standard RFC: RFC 4291 rfc4933bis: ** Downref: Normative reference to an Draft Standard RFC: RFC 5322 rfc4934bis: ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) (The author reports that a specific reference to RFC 2246 is required. References to updated documents are included as well.) (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. The references are split into normative and informative sections. All normative reference documents are complete. Downward references: rfc4931bis: ** Downref: Normative reference to an Unknown state RFC: RFC 952 rfc4932bis: ** Downref: Normative reference to an Unknown state RFC: RFC 952 ** Downref: Normative reference to an Draft Standard RFC: RFC 4291 rfc4933bis: ** Downref: Normative reference to an Draft Standard RFC: RFC 5322 rfc4934bis: ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) (1.i) Has the Document Shepherd verified that the document's IANA Considerations section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. If the document describes an Expert Review process, has the Document Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during IESG Evaluation? The IANA Considerations section in each document exists and is consistent. All IANA actions are clearly identified. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? I have verified that all XML schemas and examples are valid by processing them with the Xerces XML parser and the IBM schema quality checker. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This set of documents advances EPP to Standard. References have been updated and non-normative text updates have been made. Working Group Summary This is the product of an individual submitter, though the working group mailing list of PROVREG (now closed) was used to review the updates to the documents. Document Quality This document was reviewed for the IESG by Alexey Melnikov. The ballot includes down references to RFCs 952, 2246, 4291, and 5322, which were identified in the last call as required by RFC 3967. Personnel Edward Lewis is the document shepherd for this series of documents. Alexey Melnikov is the responsible Area Director. |
2009-06-15
|
02 | Alexey Melnikov | Placed on agenda for telechat - 2009-07-16 by Alexey Melnikov |
2009-06-15
|
02 | (System) | New version available: draft-hollenbeck-rfc4930bis-02.txt |
2009-06-13
|
02 | Alexey Melnikov | State Changes to Waiting for Writeup from Waiting for AD Go-Ahead by Alexey Melnikov |
2009-06-11
|
02 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-06-10
|
02 | Amanda Baber | IANA comments: Upon approval of this document, IANA will make the following changes to the "xml-registry/schema/epp-1.0.xsd" registry located at http://www.iana.org/assignments/xml-registry/schema/epp-1.0.xsd : The whole schema file … IANA comments: Upon approval of this document, IANA will make the following changes to the "xml-registry/schema/epp-1.0.xsd" registry located at http://www.iana.org/assignments/xml-registry/schema/epp-1.0.xsd : The whole schema file will be replaced by the schema located between (and not including) the "BEGIN" and "END" keywords of the section 4.1 "Base Schema". IANA will also make the following changes to the "xml-registry/schema/eppcom-1.0.xsd" registry located at http://www.iana.org/assignments/xml-registry/schema/eppcom-1.0.xsd : The whole schema file will be replaced by the schema located between (and not including) the "BEGIN" and "END" keywords of the section 4.2 "Shared Structure Schema". IANA will update the MIME media type description in http://www.iana.org/assignments/media-types/application/epp+xml with the content of Appendix B. Per RFC4930, the urn:ietf:params:xml:ns:epp-1.0 registration request is already implemented in http://www.iana.org/assignments/xml-registry/ns.html. Therefore, IANA will make no change. The references to the new RFC and Author's contact info will be updated accordingly. |
2009-05-24
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2009-05-24
|
02 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2009-05-14
|
02 | Cindy Morgan | Last call sent |
2009-05-14
|
02 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2009-05-14
|
02 | Alexey Melnikov | State Changes to Last Call Requested from AD Evaluation::External Party by Alexey Melnikov |
2009-05-14
|
02 | Alexey Melnikov | Last Call was requested by Alexey Melnikov |
2009-05-14
|
02 | (System) | Ballot writeup text was added |
2009-05-14
|
02 | (System) | Last call text was added |
2009-05-14
|
02 | (System) | Ballot approval text was added |
2009-05-14
|
02 | Alexey Melnikov | State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Alexey Melnikov |
2009-05-13
|
02 | Alexey Melnikov | State Change Notice email list have been change to shollenbeck@verisign.com, chris.newman@sun.com from shollenbeck@verisign.com, chris.newman@sun.com, draft-hollenbeck-rfc4930bis@tools.ietf.org |
2009-05-13
|
02 | Alexey Melnikov | [Note]: 'Chris Newman has agreed to shepherd the document. ' added by Alexey Melnikov |
2009-05-06
|
02 | Alexey Melnikov | State Changes to AD Evaluation::AD Followup from AD Evaluation::External Party by Alexey Melnikov |
2009-05-05
|
01 | (System) | New version available: draft-hollenbeck-rfc4930bis-01.txt |
2009-05-01
|
02 | Alexey Melnikov | State Changes to AD Evaluation::External Party from AD Evaluation by Alexey Melnikov |
2009-05-01
|
02 | Alexey Melnikov | Waiting for the author to respond to AD review before issuing IETF LC. |
2009-05-01
|
02 | Alexey Melnikov | State Change Notice email list have been change to shollenbeck@verisign.com, chris.newman@sun.com, draft-hollenbeck-rfc4930bis@tools.ietf.org from shollenbeck@verisign.com, draft-hollenbeck-rfc4930bis@tools.ietf.org |
2009-04-29
|
02 | Alexey Melnikov | State Changes to AD Evaluation from Publication Requested by Alexey Melnikov |
2009-04-11
|
02 | Alexey Melnikov | State Changes to Publication Requested from AD is watching by Alexey Melnikov |
2009-04-07
|
02 | Alexey Melnikov | Area acronymn has been changed to app from gen |
2009-04-07
|
02 | Alexey Melnikov | Intended Status has been changed to Standard from Proposed Standard |
2009-04-07
|
02 | Alexey Melnikov | Draft Added by Alexey Melnikov in state AD is watching |
2009-04-03
|
00 | (System) | New version available: draft-hollenbeck-rfc4930bis-00.txt |