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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Vijay,

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

Il 16/08/2020 01:00, Vijay Gurbani via Datatracker ha scritto:
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.

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


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

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


Best,

Mario



_______________________________________________
regext mailing list
regext@xxxxxxxx
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

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux