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> 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
