Last Call Review of draft-ietf-regext-rdap-sorting-and-paging-15
review-ietf-regext-rdap-sorting-and-paging-15-genart-lc-gurbani-2020-08-15-00
Request | Review of | draft-ietf-regext-rdap-sorting-and-paging |
---|---|---|
Requested revision | No specific revision (document currently at 20) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2020-08-13 | |
Requested | 2020-07-30 | |
Authors | Mario Loffredo , Maurizio Martinelli , Scott Hollenbeck | |
I-D last updated | 2020-08-15 | |
Completed reviews |
Genart Last Call review of -15
by Vijay K. Gurbani
(diff)
Secdir Last Call review of -15 by Rifaat Shekh-Yusef (diff) |
|
Assignment | Reviewer | Vijay K. Gurbani |
State | Completed | |
Request | Last Call review on draft-ietf-regext-rdap-sorting-and-paging by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/E3fSyM9gNp55ztZWgsLnPtkNq9A | |
Reviewed revision | 15 (document currently at 20) | |
Result | Ready w/nits | |
Completed | 2020-08-15 |
review-ietf-regext-rdap-sorting-and-paging-15-genart-lc-gurbani-2020-08-15-00
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.)