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

[Tobias Sattler <[e-mail]>]

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