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