The new version (v16) is now online on datatracker. Best, Tobias
> On 16. Jul 2021, at 13:03, Tobias Sattler <satt...@united-domains.de> wrote: > > 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 >> <mailto: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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
