Re: [regext] John Scudder's No Objection on draft-ietf-regext-epp-registry-maintenance-17: (with COMMENT)

[Tobias Sattler <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext