Registry Maintenance Notification for the Extensible Provisioning Protocol (EPP)
draft-ietf-regext-epp-registry-maintenance-19

[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.)

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

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".

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.

Thanks to Joe Clarke for the OpsDir review, and to Tobias for answering / addressing the comments.

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.

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.

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"?