The working document (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>) has been updated according to your feedback. We will wait on other last call feedback before updating on datatracker.
Tobias > On 28. Jul 2021, at 08:19, Tobias Sattler <satt...@united-domains.de> wrote: > > Thanks, Murray. > > We will take this into account in the upcoming update. > > Tobias > >> On 28. Jul 2021, at 06:46, Murray S. Kucherawy <superu...@gmail.com >> <mailto:superu...@gmail.com>> wrote: >> >> Thanks, this is better. >> >> I'd like to suggest these as well, though I'll start Last Call now anyway >> and you can count this as Last Call feedback. >> >> Continuing on the theme in my previous feedback: In Section 3.3, for the >> "<maint:id>" tag, "maintenance" should be "maintenance event" or maybe just >> "event" (three instances in this paragraph). Similar for "<maint:type>" >> (1x), "<maint:pollType>" (5x), "<maint:systems>" (1x), "<maint:start>" (1x), >> "<maint:end>" (1x), "<maint:reason>" (1x), "<maint:description>" (1x). In >> 4.1.3.2, "the maintenance list" should be something like "the list of >> maintenance items", consistent with the paragraph before it (2x in this >> section). Also 4.1.4 (3x). >> >> -MSK >> >> >> >> On Sun, Jul 25, 2021 at 2:06 AM Tobias Sattler <satt...@united-domains.de >> <mailto:satt...@united-domains.de>> wrote: >> The new version (v16) is now online on datatracker. >> >> Best, >> Tobias >> >>> On 16. Jul 2021, at 13:03, Tobias Sattler <satt...@united-domains.de >>> <mailto: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 <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
