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

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@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
>
> > regext@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
>
>
>
>