Thanks, John. I fixed that on GitHub, and removed the second “for”. Best, Tobias
> On 7. Oct 2021, at 22:13, John Scudder <jgs=40juniper....@dmarc.ietf.org> > wrote: > > Thanks, Tobias. Your text in Github looks good with one small nit: > > not exist") [RFC5730]. The list of top-level domains or registry > zones returned in the "Info Maintenance Item" response SHOULD be > filtered based on the top-level domains or registry zones for which > the client is authorized for. Authorization of poll messages is done > > The “for” on the last line should be deleted (as shown). Or the “for which” > that I suggested can be deleted — either change makes it correct, I prefer > the “for which” form but it’s all good. I apologize if I introduced this bug > myself with the “for which” suggestion! > > Regards, > > —John > >> On Oct 7, 2021, at 2:57 AM, Tobias Sattler <m...@tobiassattler.com >> <mailto:m...@tobiassattler.com>> wrote: >> >> >> [External Email. Be cautious of content] >> >> >> Hi John, >> >> Thank you for your review and comments. >> >> We have added our replies inline below and updated v18 on GitHub >> (https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt >> >> <https://urldefense.com/v3/__https://github.com/seitsu/registry-epp-maintenance/blob/master/draft-ietf-regext-epp-registry-maintenance.txt__;!!NEt6yMaO-gk!QaMkUdypG2waXgAPr7jLy2ZxSZlacV6YOAPt3Zp9bBLoFmJ95ZG-Eas_RsHEfQ$>) >> accordingly. >> >> Please let us know if you have any questions. >> >> Best, >> Tobias >> >>> On 7. Oct 2021, at 02:14, John Scudder via Datatracker <nore...@ietf.org >>> <mailto:nore...@ietf.org>> wrote: >>> >>> John Scudder has entered the following ballot position for >>> draft-ietf-regext-epp-registry-maintenance-17: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ >>> <https://urldefense.com/v3/__https://www.ietf.org/blog/handling-iesg-ballot-positions/__;!!NEt6yMaO-gk!QaMkUdypG2waXgAPr7jLy2ZxSZlacV6YOAPt3Zp9bBLoFmJ95ZG-EavaOC_e7w$> >>> for more information about how to handle DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/ >>> >>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-registry-maintenance/__;!!NEt6yMaO-gk!QaMkUdypG2waXgAPr7jLy2ZxSZlacV6YOAPt3Zp9bBLoFmJ95ZG-Eatb9h4GHg$> >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thanks for your work on this spec. Thanks also to James Galvin for the >>> careful shepherd writeup. >>> >>> Below are some comments I hope may be useful. >>> >>> 1. Although it's normal for an IETF spec to speak primarily to its expected >>> audience, I do think it's both usual and helpful for the introduction to >>> offer >>> a little more context than this one does. It seems like a line or two at the >>> beginning, along the lines of "EPP is a protocol whose original motivation >>> was >>> to provide a standard Internet domain name registration protocol for use >>> between domain name registrars and domain name registries" would help; it >>> would >>> have helped me anyway. >> >> TS: Fixed that by tweaking Section 1. >> >>> >>> 2. Section 1, nit: >>> >>> s/Extensible Provision Protocol/Extensible Provisioning Protocol/ >> >> TS: Fixed that. >> >>> >>> 3. In Section 2 you use a couple of SHOULDs that don't have any additional >>> context to help guide an implementor to know when the implementor MAY want >>> to >>> do otherwise. Could the SHOULDs be turned into MUSTs? Could they be turned >>> into >>> lower-case "should"? >> >> TS: Thanks. We got another feedback on Section 2, which we will discuss with >> the EPP experts, and we will address your feedback in that context. >> >>> >>> 4. In Section 3, I'm having some difficulty with this paragraph: >>> >>> Servers MUST return a Registry Maintenance Notification poll message >>> matching the newest version of the maintenance extension, based on an >>> intersection of the maintenance <objURI> elements in the server >>> <greeting> and the client <login> command. If the intersection of >>> the maintenance <objURI> elements of the server <greeting> and the >>> client <login> command results in an empty set, the server MUST >>> return the newest version of the Registry Maintenance Notification >>> poll message supported by the server based on "Usage with >>> Poll-Message EPP Responses" in Section 6 of [RFC9038]. >>> >>> Possibly the first sentence is supposed to say "... matching the newest >>> negotiated version" (or "supported", or some other qualifier, if >>> "negotiated" >>> isn't technically accurate, which it may not be)? >> >> TS: Thanks. We got another feedback on Section 2, which we will discuss with >> the EPP experts, and we will address your feedback in that context. >> >>> >>> 5. Section 3.3, I think this has been mentioned by another reviewer, but >>> just >>> to be sure: please provide an expansion of "ote”. >> >> TS: v18 contains an explanation. >> >>> >>> 6. In Section 4.1.3.1, >>> >>> maintenance identifier does not exist, the server MUST return an EPP >>> error result code of 2303 [RFC5730]. >>> >>> I suggest inserting the textual name of the error code, as in "... error >>> result >>> code of 2303 ("object does not exist") [RFC5730]." >> >> TS: Fixed that. >> >>> >>> 7. Section 4.2 and subsections. This is clear and if you let it stand the >>> way >>> it is, that's OK. But do you really need five subsections to say this? >>> Surely >>> you could just add one sentence to the end of the paragraph in 4.2, such as: >>> "None of these commands have semantics that apply to maintenance objects, so >>> there is no EPP mapping defined for these commands." >>> >>> That saves a half-page (admittedly we don't pay by the page so it arguably >>> doesn't matter, but it's still nice to keep these things tight). About the >>> only >>> reason I can think of for enumerating all the subsections is that it makes >>> the >>> table of contents more descriptive. >> >> TS: Fixed that. >> >>> >>> 8. Section 7: when you write >>> >>> additionally a server MUST only provide maintenance information for >>> clients that are authorized. If a client queries for a maintenance >>> >>> do you actually mean >>> >>> additionally a server MUST only provide maintenance information to >>> clients that are authorized. If a client queries for a maintenance >>> >>> (substitute "to" for "for"). If you really mean "for", I am confused. >> >> TS: Fixed that. >> >>> >>> 9. Section 7: Much like my point 6, I suggest inserting the textual name of >>> the >>> error code, as in "... code of 2201 ("Authorization error") [RFC5730]." >> >> TS: Fixed that. >> >>> >>> 10: Section 7: nit: >>> >>> filtered based on the top-level domains or registry zones the client >>> >>> Insert "for which" after "registry zones". >> >> TS: Fixed that. >> >>> >>> >>> >>> _______________________________________________ >>> 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
