[regext] Benjamin Kaduk's No Objection on draft-ietf-regext-epp-registry-maintenance-17: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-epp-registry-maintenance-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/



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