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 <nore...@ietf.org> > > 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 > > regext@ietf.org > > https://www.ietf.org/mailman/listinfo/regext > _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
