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