Skip to main content

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