Subject: [regext] Genart last call review of draft-ietf-regext-rdap-sorting-and-paging-15

From: Vijay Gurbani via Datatracker <[email-masked]>
Date: Sat, 15 Aug 2020 16:00:18 -0700

Reviewer: Vijay Gurbani
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-regext-rdap-sorting-and-paging-??
Reviewer: Vijay K. Gurbani
Review Date: 2020-08-15
IETF LC End Date: 2020-08-13
IESG Telechat date: Not scheduled for a telechat

Summary: The draft is ready for publication as a proposed standard, with a
couple of nits.

Major issues: 0

Minor issues: 0

Nits/editorial comments: 2

- Section 6: I understand that RFC7942 requests the authors to add a note to
the RFC Editor to remove this section, but I also understand that this is a
request to the author, and not a mandate (no normative language).   As an
implementer, I always find it easy to start with some bootstrapping  code, so I
find such implementation notes helpful.  You may wish to consider including
this information in an Appendix.

- Section 1, towards end of Page 3: s/that could be/that is often/ (Reason:
"could be" implies that truncation could happen, but is may not, "is often"
implies the same thing, but that phrase seems somehow more deterministic than
"could be".  This is a suggestion, please use your editorial discretion as
appropriate.)

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 17 Aug 2020 14:22:57 +0200

Hi Vijay,

thanks a lot for your review. I provide my responses to your feedback below.

> this information in an Appendix.

[ML] According to what is stated in RFC7942, the "Implementation Status" 
section "... is inappropriate for inclusion in a published RFC."

Despite this, I would agree with you if that section included a client 
implementation because clients are more likely than servers to be 
publicly available as open source applications.

Definitively, I believe that the examples included in the document are 
sufficient to explain the specification.

Hope you are okay with that.

> "could be".  This is a suggestion, please use your editorial discretion as

[ML] Sounds much better. I correct the phrase.

Best,

Mario

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

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: Barry Leiba <[email-masked]>
Date: Mon, 17 Aug 2020 15:56:58 -0400

Hi, Mario and Vijay.

7942 says that the Implementation Status section is inappropriate to
include in an RFC because it’s transient information that changes, and is
usually obsolete quickly.

But I don’t interpret Vijay’s suggestion as asking you to leave the section
in the document in it’s entirety, but, rather, to put non-ephemeral
information about a reference implementation into an appendix.  If there’s
a stable implementation that can be used in that way, I think it would be
appropriate, and I agree with Vijay that it could be helpful to other
implementors to have that information available.

Barry

---

From: Vijay Gurbani <[email-masked]>
Date: Tue, 18 Aug 2020 08:52:45 -0500

On Mon, Aug 17, 2020 at 2:57 PM Barry Leiba <[email-masked]> wrote:

> But I don’t interpret Vijay’s suggestion as asking you to leave the
> section in the document in it’s entirety, but, rather, to put non-ephemeral

Dear Barry and Mario: Thanks for paying attention to my review, and Barry
is indeed correct.

Especially that the two implementations listed in the implementation
section appear to be almost fully conformant to the draft, and also appear
to have reasonable documentation, etc. around them.  It would seem to be a
waste of code to simply take this section out without preserving the good
work done here that can get other implementers started immediately.

Cheers,

- vijay