Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)
RFC 9167
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2021-12-29
|
19 | Bernie Volz | Closed request for Telechat review by INTDIR with state 'Overtaken by Events' |
|
2021-12-24
|
19 | (System) | Received changes through RFC Editor sync (created alias RFC 9167, changed abstract to 'This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry … Received changes through RFC Editor sync (created alias RFC 9167, changed abstract to 'This document describes an Extensible Provisioning Protocol (EPP) extension called "Registry Maintenance Notification", which is used by EPP servers to notify EPP clients and allow EPP clients to query EPP servers regarding maintenance events.', changed pages to 22, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-12-24, changed IESG state to RFC Published) |
|
2021-12-24
|
19 | (System) | RFC published |
|
2021-12-20
|
19 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9167">AUTH48-DONE</a> from AUTH48 |
|
2021-12-13
|
19 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9167">AUTH48</a> |
|
2021-10-27
|
19 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2021-10-25
|
19 | Bernie Volz | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Benno Overeinder. Submission of review completed at an earlier date. |
|
2021-10-24
|
19 | Bernie Volz | Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Benno Overeinder. |
|
2021-10-13
|
19 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2021-10-13
|
19 | Carlos Bernardos | Assignment of request for Telechat review by INTDIR to Benno Overeinder was marked no-response |
|
2021-10-13
|
19 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2021-10-13
|
19 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2021-10-12
|
19 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2021-10-12
|
19 | (System) | RFC Editor state changed to EDIT |
|
2021-10-12
|
19 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2021-10-12
|
19 | (System) | Announcement was received by RFC Editor |
|
2021-10-12
|
19 | (System) | IANA Action state changed to In Progress from On Hold |
|
2021-10-12
|
19 | (System) | IANA Action state changed to On Hold from In Progress |
|
2021-10-12
|
19 | (System) | IANA Action state changed to In Progress |
|
2021-10-12
|
19 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2021-10-12
|
19 | Cindy Morgan | IESG has approved the document |
|
2021-10-12
|
19 | Cindy Morgan | Closed "Approve" ballot |
|
2021-10-12
|
19 | Cindy Morgan | Ballot approval text was generated |
|
2021-10-12
|
19 | (System) | Removed all action holders (IESG state changed) |
|
2021-10-12
|
19 | Murray Kucherawy | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
|
2021-10-11
|
19 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-19.txt |
|
2021-10-11
|
19 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-10-11
|
19 | Tobias Sattler | Uploaded new revision |
|
2021-10-08
|
18 | Francesca Palombini | [Ballot comment] Thank you for the work on this document. Many thanks to Harald Alvestrand for the ART ART review: https://datatracker.ietf.org/doc/review-ietf-regext-epp-registry-maintenance-17-artart-lc-alvestrand-2021-09-13/. I agree with … [Ballot comment] Thank you for the work on this document. Many thanks to Harald Alvestrand for the ART ART review: https://datatracker.ietf.org/doc/review-ietf-regext-epp-registry-maintenance-17-artart-lc-alvestrand-2021-09-13/. I agree with his comments, and thank you to the authors for working with him to fix those points. Francesca |
|
2021-10-08
|
18 | Francesca Palombini | [Ballot Position Update] Position for Francesca Palombini has been changed to No Objection from Discuss |
|
2021-10-08
|
18 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-10-08
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-10-08
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
|
2021-10-08
|
18 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-18.txt |
|
2021-10-08
|
18 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-10-08
|
18 | Tobias Sattler | Uploaded new revision |
|
2021-10-07
|
17 | (System) | Changed action holders to Murray Kucherawy, Roger Carney, Jody Kolker, Tobias Sattler (IESG state changed) |
|
2021-10-07
|
17 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
|
2021-10-07
|
17 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
|
2021-10-07
|
17 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2021-10-06
|
17 | John Scudder | [Ballot comment] Thanks for your work on this spec. Thanks also to James Galvin for the careful shepherd writeup. Below are some comments I hope … [Ballot comment] Thanks for your work on this spec. Thanks also to James Galvin for the careful shepherd writeup. Below are some comments I hope may be useful. 1. Although it's normal for an IETF spec to speak primarily to its expected audience, I do think it's both usual and helpful for the introduction to offer a little more context than this one does. It seems like a line or two at the beginning, along the lines of "EPP is a protocol whose original motivation was to provide a standard Internet domain name registration protocol for use between domain name registrars and domain name registries" would help; it would have helped me anyway. 2. Section 1, nit: s/Extensible Provision Protocol/Extensible Provisioning Protocol/ 3. In Section 2 you use a couple of SHOULDs that don't have any additional context to help guide an implementor to know when the implementor MAY want to do otherwise. Could the SHOULDs be turned into MUSTs? Could they be turned into lower-case "should"? 4. In Section 3, I'm having some difficulty with this paragraph: Servers MUST return a Registry Maintenance Notification poll message matching the newest version of the maintenance extension, based on an intersection of the maintenance <objURI> elements in the server <greeting> and the client <login> command. If the intersection of the maintenance <objURI> elements of the server <greeting> and the client <login> command results in an empty set, the server MUST return the newest version of the Registry Maintenance Notification poll message supported by the server based on "Usage with Poll-Message EPP Responses" in Section 6 of [RFC9038]. Possibly the first sentence is supposed to say "... matching the newest negotiated version" (or "supported", or some other qualifier, if "negotiated" isn't technically accurate, which it may not be)? 5. Section 3.3, I think this has been mentioned by another reviewer, but just to be sure: please provide an expansion of "ote". 6. In Section 4.1.3.1, maintenance identifier does not exist, the server MUST return an EPP error result code of 2303 [RFC5730]. I suggest inserting the textual name of the error code, as in "... error result code of 2303 ("object does not exist") [RFC5730]." 7. Section 4.2 and subsections. This is clear and if you let it stand the way it is, that's OK. But do you really need five subsections to say this? Surely you could just add one sentence to the end of the paragraph in 4.2, such as: "None of these commands have semantics that apply to maintenance objects, so there is no EPP mapping defined for these commands." That saves a half-page (admittedly we don't pay by the page so it arguably doesn't matter, but it's still nice to keep these things tight). About the only reason I can think of for enumerating all the subsections is that it makes the table of contents more descriptive. 8. Section 7: when you write additionally a server MUST only provide maintenance information for clients that are authorized. If a client queries for a maintenance do you actually mean additionally a server MUST only provide maintenance information to clients that are authorized. If a client queries for a maintenance (substitute "to" for "for"). If you really mean "for", I am confused. 9. Section 7: Much like my point 6, I suggest inserting the textual name of the error code, as in "... code of 2201 ("Authorization error") [RFC5730]." 10: Section 7: nit: filtered based on the top-level domains or registry zones the client Insert "for which" after "registry zones". |
|
2021-10-06
|
17 | John Scudder | [Ballot Position Update] New position, No Objection, has been recorded for John Scudder |
|
2021-10-06
|
17 | Warren Kumari | [Ballot comment] Thanks to Joe Clarke for the OpsDir review, and to Tobias for answering / addressing the comments. |
|
2021-10-06
|
17 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
|
2021-10-06
|
17 | Joe Clarke | Request for Telechat review by OPSDIR Completed: Has Nits. Reviewer: Joe Clarke. Sent review to list. |
|
2021-10-06
|
17 | Francesca Palombini | [Ballot discuss] Thank you for the work on this document. Many thanks to Harald Alvestrand for the ART ART review: https://datatracker.ietf.org/doc/review-ietf-regext-epp-registry-maintenance-17-artart-lc-alvestrand-2021-09-13/. I agree with … [Ballot discuss] Thank you for the work on this document. Many thanks to Harald Alvestrand for the ART ART review: https://datatracker.ietf.org/doc/review-ietf-regext-epp-registry-maintenance-17-artart-lc-alvestrand-2021-09-13/. I agree with his comments, and thank you to the authors for working with him to fix those points. I will hold a DISCUSS until the update answering the two first comments about "weak definitions", the "formatting issues" comment, and the date-format comment is published. As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion; I really think that the document would be improved with a change here, but can be convinced otherwise. Francesca |
|
2021-10-06
|
17 | Francesca Palombini | [Ballot Position Update] New position, Discuss, has been recorded for Francesca Palombini |
|
2021-10-06
|
17 | Roman Danyliw | [Ballot comment] Thank you to Melinda Shore for the SECDIR review. ** Section 7. "If a client queries for a maintenance identifier, per Section 4.1.3.1 … [Ballot comment] Thank you to Melinda Shore for the SECDIR review. ** Section 7. "If a client queries for a maintenance identifier, per Section 4.1.3.1 "Info Maintenance Item", that it is not authorized to access, the server MUST return an EPP error result code of 2201 [RFC5730]." Should this be softened to give a server the flexibility to alternatively return a 2303 error ("Object does not exist") so the existence of a maintenance updates would remain unknown to unauthorized users? If not, this (likely minor) risk of leaking the existence of maintenance windows should be noted. ** Section 7. These could be read as conflicting. (a) Section 7. “a server MUST only provide maintenance information for clients that are authorized.” (b) Later in Section 7. “The list of top-level domains or registry zones returned in the "Info Maintenance Item" response SHOULD be filtered based on the top-level domains or registry zones the client is authorized.” (a) seems to say that a client must only get the information for which it is authorized, but (b) suggests that this filtering for those TLD/zones to restrict it only to authorized clients is only a should. |
|
2021-10-06
|
17 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
|
2021-10-06
|
17 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). I hope that this helps to improve the document, Regards, -éric -- Section 3.3 -- In "mantid", should the reference for the encoding of the language be mentioned ? The use of "maint:tlds" seems to indicate a limitation to top-level domains only (even if the text mentions later "registry zone") but EPP is used not only for TLD. Suggest to make it even clearer (as I am afraid that it is too late in the process to change the element name). -- Section 4.1.3.1 -- In the example, there is "<maint:type lang="en">" but lang is not specified as an attribute of "maint:type" in section 3.3. |
|
2021-10-06
|
17 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
|
2021-10-06
|
17 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2021-10-05
|
17 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
|
2021-10-01
|
17 | Benjamin Kaduk | [Ballot comment] Mostly my comments are either editorial in nature or derive from attempting to cross-check for internal consistency; there's not much security-related to talk … [Ballot comment] Mostly my comments are either editorial in nature or derive from attempting to cross-check for internal consistency; there's not much security-related to talk about here. I did phrase some editorial comments in the form of suggested text, which I put into a pull request on github (https://github.com/seitsu/registry-epp-maintenance/pull/1). Given that the only form of the draft in the repo is the text file, I'm not sure if this is the preferred form of modification, though -- I believe that the github UI will at least do an effective job of highlighting the suggested changes, should they need to be made in a different, authoritative, source version of the document. I agree with the ArtArt reviewer that a specific definition of "maintenance event" is in order, and am happy to see such a definition provided in the editor's copy in github. Section 3.3 <maint:type> Zero or more OPTIONAL types of the maintenance event that has the possible set of values defined by server policy, such as "Routine Maintenance", "Software Update", "Software Upgrade", or "Extended Outage". A subsequent example shows the "lang" attribute present, but while it's mentioned for other elements, it's not mentioned here. Section 4.1.3.2 S: <maint:start>2021-12-30T06:00:00Z</maint:start> S: <maint:end>2021-12-30T07:00:00Z</maint:end> S: <maint:crDate>2021-11-08T22:10:00Z</maint:crDate> Interesting to use an example of a maintenance scheduled to go from 0600 to 0700 but that actually didn't end (per the §4.1.3.2 example) until 1425. Section 4.1.4 In the case of a Registry Maintenance specific message, a <maint:infData> element will be included within the <resData> element of the standard <poll> response. The <maint:infData> element contains the <maint:item> element defined in Section 3.3. Should we mention here that the <maint:infData> also indicates the maintenance namespace? S: <maint:id>2e6df9b0-4092-4491-bcc8-9fb2166dcee6</maint:id> S: <maint:pollType>create</maint:pollType> [...] S: <maint:start>2021-12-30T06:00:00Z</maint:start> S: <maint:end>2021-12-30T14:25:57Z</maint:end> How is the end time 1425 at creation, when the <maint:list> example shows this maintenance having an end time of 0700? Section 7 As SEC AD, I always have to try to think up any other potential security considerations. The main thing that comes to mind here is that knowledge of maintenance events (especially those with only "partial" impact) might help an attacker know when an attack would be most effective, and which services to direct attacks against. But, that's a pretty weak consideration and might not merit mention here, even before we consider the mitigating effect of the existing guidance on authorization checking. Section 9.1 In some sense RFC 3688 does not need to be a normative reference; we say that what we provide conforms with it but evaluating such conformance is not a prerequisite for understanding or using this protocol. NITS Section 1 Given the DNS namespace expansion, it is now desirable to provide an efficient approach to notify registrars. (I see that the intro has been greatly expanded in the editor's copy, but this line seems to be mostly unaffected.) It seems that perhaps there is a missing link between expansion of the DNS namespace and a need to automate notification of maintenance events, perhaps relating to the greater number of registries that individual registrars are interacting with regularly? Section 2 elements of the server <greeting>. The version of the maintenance <info> response MUST match the version of the maintenance <info> command executed by the server. Is it better to make the requirement to match be that the response must use the same version as what the client sends (which in turn is assumed to be what the server executes)? If the intersection of the maintenance <objURI> elements of the server <greeting> and the client <login> command results in an empty set, the server MUST return the newest version of the Registry Maintenance Notification poll message supported by the server based on "Usage with Poll-Message EPP Responses" in Section 6 of [RFC9038]. I'm not sure I'm parsing this properly. I get the part up to "results in an empty set" (though pedantically, there's only one empty set, so "the empty set" might be better). After that, the server MUST use the newest version it supports, okay, but "based on [section 6 of RFC 9038]" throws me for a loop. The referenced section seems to be talking about the mechanics of how to use the "unhandled namespace" method to ensure that a client will be able to handle a given <poll> response without erroring, even in the face of extension elements that the client does not recognize. I do not, however, see anything about "use the latest version of an extension" in that section. My current guess is that the intent of what's written here is to impose a new requirement to use the latest version if there is no known common version (which is to some extent an arbitrary choice of what version to use), and to also say that the server should construct that response following the procedures of Section 6 of [RFC9038]. But right now the words on the page suggest that the latter is the reason or justification for the former, and I can't make that fit together. Section 3.3 <maint:detail> The OPTIONAL URI to detailed maintenance event description, formatted according to [RFC8820]. RFC 3986 might be a better reference than RFC 8820, here. [the below is quoted from the editor's copy, having diverged from the published -17]: <maint:connection> The value SHALL be boolean and indicates if a client needs to perform an action that is connection-related, such as a reconnect. The attribute should only be used as a flag to indicate connections will be affected. Servers SHOULD include a description of how the connections are affected in the <main:description> element above. <maint:implementation> [...] include a description of how the implementation is affected in the <main:description> element above. I assume that the resource identified by <maint:detail> would also be expected to include this description. |
|
2021-10-01
|
17 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
|
2021-09-30
|
17 | Lars Eggert | [Ballot comment] All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as … [Ballot comment] All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Paragraph 13, nit: > ML [W3C.REC-xml11-20060816] is case sensitive. Unless stated otherwise, XML s > ^^^^^^^^^^^^^^ This word is normally spelled with a hyphen. Paragraph 39, nit: > he negotiated value is something other then the default value of "en" (Engli > ^^^^^^^^^^ Did you mean "other than"? |
|
2021-09-30
|
17 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
|
2021-09-29
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
|
2021-09-29
|
17 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
|
2021-09-29
|
17 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Joe Clarke |
|
2021-09-28
|
17 | Carlos Bernardos | Request for Telechat review by INTDIR is assigned to Benno Overeinder |
|
2021-09-28
|
17 | Carlos Bernardos | Request for Telechat review by INTDIR is assigned to Benno Overeinder |
|
2021-09-28
|
17 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
|
2021-09-28
|
17 | Éric Vyncke | Requested Telechat review by INTDIR |
|
2021-09-24
|
17 | Erik Kline | [Ballot comment] [S3.3, nit] * Seems like the <maint:impact> text could be phrased in terms of expectations for the impact, i.e. "If access … [Ballot comment] [S3.3, nit] * Seems like the <maint:impact> text could be phrased in terms of expectations for the impact, i.e. "If access is expected to be {intermittently unavailable, completely unavailable, unaffected}, ..." (give that things can go from "none" to "full" unexpectedly =). [S3.3, question] * For the <maint:environment> type attribute values, the meanings of most are immediately obvious to me except for "ote". Assuming this means "Operational Test and Evaluation", or something similar, perhaps expand/explain this? ("ote" does not appear in the RFC Editor's list of abbreviations.) |
|
2021-09-24
|
17 | Erik Kline | [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline |
|
2021-09-23
|
17 | Amy Vezza | Placed on agenda for telechat - 2021-10-07 |
|
2021-09-22
|
17 | Murray Kucherawy | Ballot has been issued |
|
2021-09-22
|
17 | Murray Kucherawy | [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy |
|
2021-09-22
|
17 | Murray Kucherawy | Created "Approve" ballot |
|
2021-09-22
|
17 | Murray Kucherawy | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::External Party |
|
2021-09-22
|
17 | Murray Kucherawy | Ballot writeup was changed |
|
2021-09-14
|
17 | Sabrina Tanamal | IANA Experts State changed to Expert Reviews OK from Issues identified |
|
2021-09-13
|
17 | Harald Alvestrand | Request for Last Call review by ARTART Completed: Almost Ready. Reviewer: Harald Alvestrand. Sent review to list. |
|
2021-09-09
|
17 | Jean Mahoney | Closed request for Last Call review by GENART with state 'Team Will not Review Version' |
|
2021-09-09
|
17 | Jean Mahoney | Assignment of request for Last Call review by GENART to Jouni Korhonen was marked no-response |
|
2021-08-27
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
|
2021-08-27
|
17 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-17.txt |
|
2021-08-27
|
17 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-08-27
|
17 | Tobias Sattler | Uploaded new revision |
|
2021-08-21
|
16 | Murray Kucherawy | Awaiting feedback from IANA designated expert. |
|
2021-08-21
|
16 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead::AD Followup |
|
2021-08-16
|
16 | Murray Kucherawy | IESG state changed to Waiting for AD Go-Ahead::AD Followup from Waiting for Writeup::AD Followup |
|
2021-08-16
|
16 | Murray Kucherawy | IESG state changed to Waiting for Writeup::AD Followup from Waiting for Writeup |
|
2021-08-12
|
16 | Sabrina Tanamal | From the designated expert for IETF XML registry: Sect 1.1: "maint" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:maintenance-1.0". Um, I don't think so? They use … From the designated expert for IETF XML registry: Sect 1.1: "maint" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:maintenance-1.0". Um, I don't think so? They use that as an example namespace prefix but I don't see anywhere that it's used as an abbreviation. But perhaps I missed it in scanning through the draft? I didn't check the schema, nor did I check the examples against the schema. Aside from that, looks OK to me. ==== From the designated expert for EPP Extensions: I'm not the designated expert for the XML schema registry, but I'd prefer to see the XML schema registration using a slightly different URI. This: urn:ietf:params:xml:schema:epp:maintenance-1.0 instead of this: urn:ietf:params:xml:schema:maintenance-1.0 As is, the schema registration and the namespace registration are inconsistent. The namespace registration URI includes "epp". The EPP extension registration looks fine. |
|
2021-08-12
|
16 | Sabrina Tanamal | IANA Experts State changed to Issues identified from Reviews assigned |
|
2021-08-11
|
16 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2021-08-10
|
16 | Sabrina Tanamal | IANA Experts State changed to Reviews assigned |
|
2021-08-10
|
16 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
|
2021-08-10
|
16 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-regext-epp-registry-maintenance-16. 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-epp-registry-maintenance-16. 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 new registration is to be made as follows: ID: epp:maintenance-1.0 URI: urn:ietf:params:xml:ns:epp:maintenance-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. This review must be completed before the document's IANA state can be changed to "IANA OK." Second, in the schema registry on the IETF XML Registry page located at: https://www.iana.org/assignments/xml-registry/ a new registration is to be made as follows: ID: epp:maintenance-1.0 URI: urn:ietf:params:xml:ns:epp:maintenance-1.0 Filename: [ TBD-at-Registration ] Reference: [ RFC-to-be ] As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." Third, in the Extensions for the Extensible Provisioning Protocol (EPP) registry located at: https://www.iana.org/assignments/epp-extensions/ a new registration is to be made as follows: Name of Extension: Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP) Document Status: Standards Track Reference: [ RFC-to-be ] Registrant: IESG TLDs: Any IPR Disclosure: None Status: Active Notes: None As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK." 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 Lead IANA Services Specialist |
|
2021-08-08
|
16 | Melinda Shore | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Melinda Shore. Sent review to list. |
|
2021-07-30
|
16 | Barry Leiba | Request for Last Call review by ARTART is assigned to Harald Alvestrand |
|
2021-07-30
|
16 | Barry Leiba | Request for Last Call review by ARTART is assigned to Harald Alvestrand |
|
2021-07-29
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
|
2021-07-29
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Jouni Korhonen |
|
2021-07-29
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
|
2021-07-29
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Melinda Shore |
|
2021-07-28
|
16 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2021-07-28
|
16 | Amy Vezza | The following Last Call announcement was sent out (ends 2021-08-11):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: James Galvin <galvin@elistx.com … The following Last Call announcement was sent out (ends 2021-08-11):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: James Galvin <galvin@elistx.com>, draft-ietf-regext-epp-registry-maintenance@ietf.org, galvin@elistx.com, regext-chairs@ietf.org, regext@ietf.org, superuser@gmail.com Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-regext-epp-registry-maintenance-16.txt> (Registry Maintenance Notifications 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: - 'Registry Maintenance Notifications for the Extensible Provisioning Protocol (EPP)' <draft-ietf-regext-epp-registry-maintenance-16.txt> 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 last-call@ietf.org mailing lists by 2021-08-11. 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 Provision Protocol (EPP) extension called "Registry Maintenance Notification", used by EPP servers to notify EPP clients and allow EPP clients to query EPP servers on maintenance events. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/ No IPR declarations have been submitted directly on this I-D. |
|
2021-07-28
|
16 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2021-07-28
|
16 | Amy Vezza | Last call announcement was changed |
|
2021-07-27
|
16 | Murray Kucherawy | Last call was requested |
|
2021-07-27
|
16 | Murray Kucherawy | Ballot approval text was generated |
|
2021-07-27
|
16 | Murray Kucherawy | Ballot writeup was generated |
|
2021-07-27
|
16 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-07-27
|
16 | Murray Kucherawy | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
|
2021-07-27
|
16 | Murray Kucherawy | Last call announcement was generated |
|
2021-07-25
|
16 | (System) | Removed all action holders (IESG state changed) |
|
2021-07-25
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-07-25
|
16 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-16.txt |
|
2021-07-25
|
16 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-07-25
|
16 | Tobias Sattler | Uploaded new revision |
|
2021-07-16
|
15 | Murray Kucherawy | Changed action holders to Roger Carney, Jody Kolker, Tobias Sattler |
|
2021-07-16
|
15 | (System) | Changed action holders to Murray Kucherawy, Roger Carney, Jody Kolker, Tobias Sattler (IESG state changed) |
|
2021-07-16
|
15 | Murray Kucherawy | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
|
2021-07-09
|
15 | Murray Kucherawy | IESG state changed to AD Evaluation::AD Followup from AD Evaluation |
|
2021-06-24
|
15 | (System) | Changed action holders to Murray Kucherawy (IESG state changed) |
|
2021-06-24
|
15 | Murray Kucherawy | IESG state changed to AD Evaluation from Publication Requested |
|
2021-06-22
|
15 | Antoin Verschuren | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, indicated in the title page header. This is desired in order to promote a single, interoperable protocol specification. (2) 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: Registries usually conduct maintenances and inform registrars in different ways. Given the DNS namespace expansion, it is now desirable to provide methods for EPP servers to notify EPP clients and EPP clients can query EPP servers for upcoming maintenances. This document describes an extension mapping for version 1.0 of the Extensible Provision Protocol [RFC5730]. This mapping provides a mechanism by which EPP servers may notify and EPP clients to query upcoming maintenances. Working Group Summary: This work originated in the Technical Operations subcommittee of registries and registrars in ICANN's Generic Names Supporting Organization (GNSO). Since it is an EPP protocol extension it was submitted to the REGEXT working group for consideration as a Proposed Standard. As the work was developed within its community of interest, the specification arrived mostly complete. There was minor discussion of a few details and without objection the working group agreed to Proposed Standard status for the specification. Document Quality: The document was reviewed by EPP experts among the working group members and found to be excellent quality. Personnel: The document shepherd is James Galvin <galvin@elistx.com>. The responsible Area Director is Murray Kucherawy. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document was reviewed for readability, accuracy, and the formal syntax was validated. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures. (9) 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? The document represents strong consensus of a few individuals, with no objection from anyone else. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? None. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. None. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). There are three additions to existing IANA registries listed in the IANA Considerations section. All are consistent with the document and conform to IANA requirements. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The XML formal syntax was syntax validated with https://www.xmlvalidation.com/. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? None. |
|
2021-06-22
|
15 | Antoin Verschuren | Responsible AD changed to Murray Kucherawy |
|
2021-06-22
|
15 | Antoin Verschuren | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2021-06-22
|
15 | Antoin Verschuren | IESG state changed to Publication Requested from I-D Exists |
|
2021-06-22
|
15 | Antoin Verschuren | IESG process started in state Publication Requested |
|
2021-06-22
|
15 | Antoin Verschuren | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, indicated in the title page header. This is desired in order to promote a single, interoperable protocol specification. (2) 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: Registries usually conduct maintenances and inform registrars in different ways. Given the DNS namespace expansion, it is now desirable to provide methods for EPP servers to notify EPP clients and EPP clients can query EPP servers for upcoming maintenances. This document describes an extension mapping for version 1.0 of the Extensible Provision Protocol [RFC5730]. This mapping provides a mechanism by which EPP servers may notify and EPP clients to query upcoming maintenances. Working Group Summary: This work originated in the Technical Operations subcommittee of registries and registrars in ICANN's Generic Names Supporting Organization (GNSO). Since it is an EPP protocol extension it was submitted to the REGEXT working group for consideration as a Proposed Standard. As the work was developed within its community of interest, the specification arrived mostly complete. There was minor discussion of a few details and without objection the working group agreed to Proposed Standard status for the specification. Document Quality: The document was reviewed by EPP experts among the working group members and found to be excellent quality. Personnel: The document shepherd is James Galvin <galvin@elistx.com>. The responsible Area Director is Murray Kucherawy. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document was reviewed for readability, accuracy, and the formal syntax was validated. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures. (9) 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? The document represents strong consensus of a few individuals, with no objection from anyone else. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? None. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. None. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). There are three additions to existing IANA registries listed in the IANA Considerations section. All are consistent with the document and conform to IANA requirements. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The XML formal syntax was syntax validated with https://www.xmlvalidation.com/. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? None. |
|
2021-06-18
|
15 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-15.txt |
|
2021-06-18
|
15 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-06-18
|
15 | Tobias Sattler | Uploaded new revision |
|
2021-06-18
|
14 | James Galvin | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 1 November 2019. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Proposed Standard, indicated in the title page header. This is desired in order to promote a single, interoperable protocol specification. (2) 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: Registries usually conduct maintenances and inform registrars in different ways. Given the DNS namespace expansion, it is now desirable to provide methods for EPP servers to notify EPP clients and EPP clients can query EPP servers for upcoming maintenances. This document describes an extension mapping for version 1.0 of the Extensible Provision Protocol [RFC5730]. This mapping provides a mechanism by which EPP servers may notify and EPP clients to query upcoming maintenances. Working Group Summary: This work originated in the Technical Operations subcommittee of registries and registrars in ICANN's Generic Names Supporting Organization (GNSO). Since it is an EPP protocol extension it was submitted to the REGEXT working group for consideration as a Proposed Standard. As the work was developed within its community of interest, the specification arrived mostly complete. There was minor discussion of a few details and without objection the working group agreed to Proposed Standard status for the specification. Document Quality: The document was reviewed by EPP experts among the working group members and found to be excellent quality. Personnel: The document shepherd is James Galvin <galvin@elistx.com>. The responsible Area Director is <NOT YET SELECTED>. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document was reviewed for readability, accuracy, and the formal syntax was validated. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has 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. No concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There are no IPR disclosures. (9) 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? The document represents strong consensus of a few individuals, with no objection from anyone else. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. None. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. None. (13) Have all references within this document been identified as either normative or informative? Yes. (14) 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 plan for their completion? None. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. None. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). There are three additions to existing IANA registries listed in the IANA Considerations section. All are consistent with the document and conform to IANA requirements. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc. The XML formal syntax was syntax validated with https://www.xmlvalidation.com/. (20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342? None. |
|
2021-04-19
|
14 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-14.txt |
|
2021-04-19
|
14 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-04-19
|
14 | Tobias Sattler | Uploaded new revision |
|
2021-04-19
|
13 | Antoin Verschuren | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
|
2021-04-15
|
13 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-13.txt |
|
2021-04-15
|
13 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-04-15
|
13 | Tobias Sattler | Uploaded new revision |
|
2021-03-27
|
12 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-12.txt |
|
2021-03-27
|
12 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-03-27
|
12 | Tobias Sattler | Uploaded new revision |
|
2021-02-19
|
11 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-11.txt |
|
2021-02-19
|
11 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-02-19
|
11 | Tobias Sattler | Uploaded new revision |
|
2021-01-25
|
10 | James Galvin | The document was only supported by its authors. A new/revised set of questions/comments have been reported. |
|
2021-01-25
|
10 | James Galvin | Tag Other - see Comment Log cleared. |
|
2021-01-25
|
10 | James Galvin | IETF WG state changed to WG Document from In WG Last Call |
|
2021-01-13
|
10 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-10.txt |
|
2021-01-13
|
10 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2021-01-13
|
10 | Tobias Sattler | Uploaded new revision |
|
2021-01-04
|
09 | Antoin Verschuren | IETF WG state changed to In WG Last Call from WG Document |
|
2020-12-29
|
09 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-09.txt |
|
2020-12-29
|
09 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-12-29
|
09 | Tobias Sattler | Uploaded new revision |
|
2020-12-23
|
08 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-08.txt |
|
2020-12-23
|
08 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-12-23
|
08 | Tobias Sattler | Uploaded new revision |
|
2020-12-11
|
07 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-07.txt |
|
2020-12-11
|
07 | (System) | New version approved |
|
2020-12-11
|
07 | (System) | Request for posting confirmation emailed to previous authors: Tobias Sattler <tobias.sattler@me.com>, Roger Carney <rcarney@godaddy.com>, Jody Kolker <jkolker@godaddy.com> |
|
2020-12-11
|
07 | Tobias Sattler | Uploaded new revision |
|
2020-12-08
|
06 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-06.txt |
|
2020-12-08
|
06 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-12-08
|
06 | Tobias Sattler | Uploaded new revision |
|
2020-12-01
|
05 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-05.txt |
|
2020-12-01
|
05 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-12-01
|
05 | Tobias Sattler | Uploaded new revision |
|
2020-11-09
|
04 | James Galvin | Revert to working group document because issues were raised during last call that need further discussion. |
|
2020-11-09
|
04 | James Galvin | Tag Other - see Comment Log set. |
|
2020-11-09
|
04 | James Galvin | IETF WG state changed to WG Document from In WG Last Call |
|
2020-10-26
|
04 | James Galvin | IETF WG state changed to In WG Last Call from WG Document |
|
2020-10-23
|
04 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-04.txt |
|
2020-10-23
|
04 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-10-23
|
04 | Tobias Sattler | Uploaded new revision |
|
2020-06-30
|
03 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-03.txt |
|
2020-06-30
|
03 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-06-30
|
03 | Tobias Sattler | Uploaded new revision |
|
2020-06-17
|
02 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-02.txt |
|
2020-06-17
|
02 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-06-17
|
02 | Tobias Sattler | Uploaded new revision |
|
2020-05-08
|
01 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-01.txt |
|
2020-05-08
|
01 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-05-08
|
01 | Tobias Sattler | Uploaded new revision |
|
2020-03-06
|
00 | James Galvin | Notification list changed to James Galvin <galvin@elistx.com> |
|
2020-03-06
|
00 | James Galvin | Document shepherd changed to James Galvin |
|
2020-03-06
|
00 | Antoin Verschuren | Changed consensus to Yes from Unknown |
|
2020-03-06
|
00 | Antoin Verschuren | Intended Status changed to Proposed Standard from None |
|
2020-02-14
|
00 | Tobias Sattler | This document now replaces draft-sattler-epp-registry-maintenance instead of None |
|
2020-02-14
|
00 | Tobias Sattler | New version available: draft-ietf-regext-epp-registry-maintenance-00.txt |
|
2020-02-14
|
00 | (System) | New version accepted (logged-in submitter: Tobias Sattler) |
|
2020-02-14
|
00 | Tobias Sattler | Uploaded new revision |