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

From: John Scudder via Datatracker <[email-masked]>
Date: Wed, 06 Oct 2021 17:14:11 -0700

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

---

From: Tobias Sattler <[email-masked]>
Date: Thu, 7 Oct 2021 08:57:17 +0200

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 <[email-masked]> wrote:
> 

TS: Fixed that by tweaking Section 1.

> s/Extensible Provision Protocol/Extensible Provisioning Protocol/

TS: Fixed that.

> do otherwise. Could the SHOULDs be turned into MUSTs? Could they be turned into

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.

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

> to be sure: please provide an expansion of "ote”.

TS: v18 contains an explanation.

> code of 2303 ("object does not exist") [RFC5730]."

TS: Fixed that.

> table of contents more descriptive.

TS: Fixed that.

> (substitute "to" for "for"). If you really mean "for", I am confused.

TS: Fixed that.

> error code, as in "... code of 2201 ("Authorization error") [RFC5730]."

TS: Fixed that.

> Insert "for which" after "registry zones".

TS: Fixed that.

> 
> 
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: John Scudder <[email-masked]>
Date: Thu, 7 Oct 2021 20:13:33 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

[External Email. Be cautious of content]

Hi John,

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.

Best,
Tobias

On 7. Oct 2021, at 02:14, John Scudder via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

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$>

2. Section 1, nit:

TS: Fixed that.

6. In Section 4.1.3.1,

TS: Fixed that.

TS: Fixed that.

do you actually mean

TS: Fixed that.

TS: Fixed that.

10: Section 7: nit:

TS: Fixed that.

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext

---

From: Tobias Sattler <[email-masked]>
Date: Thu, 7 Oct 2021 22:48:26 +0200

Thanks, John. I fixed that on GitHub, and removed the second “for”.

Best,
Tobias

> On 7. Oct 2021, at 22:13, John Scudder <jgs=[email-masked]> wrote:
> 
>> On Oct 7, 2021, at 2:57 AM, Tobias Sattler <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> 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.
>> 
>>> On 7. Oct 2021, at 02:14, John Scudder via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> 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$>
>>> 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$>
>>> 
>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/regext <https://www.ietf.org/mailman/listinfo/regext>