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