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 On Mon, Aug 17, 2020 at 8:26 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: > 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 > > > reg...@ietf.org > > > 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 > > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
