Thanks, Murray. We are not in a hurry. We will do the update next week then and look forward to the next steps.
Best, Tobias > On 16. Jul 2021, at 09:09, Murray S. Kucherawy <superu...@gmail.com> wrote: > > Thanks, that's all fine. > > If this document is not slated to be on the IETF 111 agenda, I'm OK approving > its update during the embargo period. (I'm also fine just waiting if there's > no hurry.) > > -MSK > > On Wed, Jul 14, 2021 at 11:01 AM Tobias Sattler <satt...@united-domains.de > <mailto:satt...@united-domains.de>> wrote: > Hi Murray, > > Thank you very much for your feedback. > > We have prepared a new version (v16) on GitHub > (https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt > > <https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt>), > while the datatracker is currently locked for submissions till 2021-07-24 > 23:59 PDT. > > Please find inline our comments. > > Best, > Tobias > >> On 9. Jul 2021, at 21:16, Murray S. Kucherawy <superu...@gmail.com >> <mailto:superu...@gmail.com>> wrote: >> >> Hi all, >> >> This is my AD review for draft-ietf-regext-epp-registry-maintenance. >> >> General: >> >> The use of "maintenance" in this document is sometimes awkward to me, >> especially in its plural form. For instance, the first sentence of the >> introduction includes "conduct maintenances", which reads oddly. I think I >> would suggest "conduct maintenance", and change "upcoming maintenances" to >> "upcoming maintenance events" (as was done in Section 3.3) or "upcoming >> maintenance windows". >> > > TS: We addressed that in the new version. > >> Abstract: >> >> Should "registry's" perhaps be "registries" or "a registry's"? >> >> Actually perhaps this is a better solution: >> >> NEW: >> This document describes an Extensible Provisioning Protocol (EPP) extension >> called "Registry Maintenance Notifications", used by EPP clients and servers >> to notify each other about maintenance events. >> (END) > > TS: Thanks for that. We rewrote this part to make it more straightforward. > >> >> Section 1: >> >> I can't quite parse this sentence: >> >> This mapping provides a >> mechanism by which EPP servers may notify and EPP clients to query >> upcoming maintenances. > TS: We rephrased the Introduction. > >> Section 2 starts talking about particular EPP elements and commands. I >> think Section 1 should include a normative reference to EPP or some other >> document where these are defined. > > TS: Can you give us some pointers on that? There is a normative reference in > Section 1. > >> >> Section 3.2: "All dates and times attribute values ..." -- s/dates and >> times/date and time/ > > TS: Fixed. > >> >> Section 3.3: What does "the name of the maintenance" mean? Is this >> something like a headline or title, or a more complete description? > > TS: This more of a headline just for reference if you talk to someone about > it. > >> >> Also Section 3.3: If there might ever be a need to add more pollType values, >> or deprecate one of the ones listed, you might want to consider creating a >> registry for them. If not, this whole document needs to be updated or >> revised to include the new values. I have the same question about >> "<maint:reason>", "<maint:impact>", "<maint:environment>", and all of the >> others whose possible values are expressly enumerated. > > TS: We think that those fields are well designed, and pollType is an optional > field. Therefore, we want to avoid the additional overhead of creating a > registry for them. Historically those items haven’t changed. If we need to > correct them, we would do whatever is necessary (ERRATA, creating a registry, > etc.) > >> >> Also Section 3.3: For "<maint:environment>", what is "ote"? > > TS: ote stands for Operational Test and Evaluation, common terminology in the > domain name industry. > >> >> Also Section 3.3: In the examples, the "<maint:id>" seems to be a UUID. Is >> this at the discretion of the implementation (i.e., any format for the >> identifier is fine), or should this be constrained explicitly here? > > TS: That is only an example. It is at the discretion of the implementation. > >> >> Thank you for including Section 8. >> >> -MSK >> _______________________________________________ >> regext mailing list >> regext@ietf.org <mailto:regext@ietf.org> >> https://www.ietf.org/mailman/listinfo/regext >> <https://www.ietf.org/mailman/listinfo/regext> >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
