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.loffredo@xxxxxxxxxx> 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
> 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
