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

[Benjamin Kaduk <[e-mail]>]

Hi Tobias,

Thanks for the replies, and I'm glad that the github pull request was
usable as-is.

I have no further questions.

-Ben

On Wed, Oct 06, 2021 at 08:42:36PM +0200, Tobias Sattler wrote:
> Hi Benjamin,
> 
> Thank you for your review, comments, and pull request on GitHub.
> 
> We have added our replies inline below and updated v18 on GitHub accordingly.
> 
> Please let us know if you have any questions.
> 
> Best,
> Tobias
> 
> > On 2. Oct 2021, at 04:15, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> > 
> > 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.
> 
> TS: Fixed that.
> 
> > 
> > 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.
> 
> TS: Fixed that.
> 
> > 
> > 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?
> 
> TS: Fixed that.
> 
> > 
> >   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?
> 
> TS: Fixed that.
> 
> > 
> > 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.
> 
> TS: True, however, hacker could als get into the email of a registrar and receive the same information. Also some registries publish maintenance events to the public. To us this is even more secure than that as registries require a cert, approved IP list and a username and password.
> 
> > 
> > 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.
> 
> TS: Fixed that.
> 
> > 
> > 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?
> 
> TS: Fixed that.
> 
> > 
> > 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.
> 
> TS: We will discuss that with the EPP experts and check how we can address that.
> 
> > 
> > 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.
> 
> TS: Fixed that.
> 
> > 
> > [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.
> 
> TS: Fixed that.
> 
> > 
> > 
> > 
> > _______________________________________________
> > regext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/regext
>