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

[John Scudder via Datatracker <[e-mail]>]

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.

2. Section 1, nit:

s/Extensible Provision Protocol/Extensible Provisioning Protocol/

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"?

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)?

5. Section 3.3, I think this has been mentioned by another reviewer, but just
to be sure: please provide an expansion of "ote".

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]."

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.

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.

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]."

10: Section 7: nit:

   filtered based on the top-level domains or registry zones the client

Insert "for which" after "registry zones".