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

Barry Leiba <barryleiba@computer.org> Mon, 17 August 2020 19:57 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8773E3A0FC2; Mon, 17 Aug 2020 12:57:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLwsNaG5Mhup; Mon, 17 Aug 2020 12:57:10 -0700 (PDT)
Received: from mail-il1-f174.google.com (mail-il1-f174.google.com [209.85.166.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACAD13A0FAD; Mon, 17 Aug 2020 12:57:10 -0700 (PDT)
Received: by mail-il1-f174.google.com with SMTP id 77so15596257ilc.5; Mon, 17 Aug 2020 12:57:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LabVoqAEbiwujZrZHd5TJvcgDqiIctmN+Mae9lVaoe4=; b=brFzutCxduocPg/MuzS5VLcqAih6fpasWnzMllsGCrYjX0rfE5b+N8sgUeCzM/Ux5Q TaECxKgdOBWTvqpOxBUHwnOfUpkGNWQqgoEEon9sHT35278AYvZhEw499oIVXaUXopnr TzQl3tMcojxw60Q+lUa2KdcFqM273HDlR450dM6dACFTdQpOGiFJVbHtRkqw8cWxyve5 axSwGgwx8QJzBW+bJR3PaLCNaDCEtf0yOlxO+3iHgglMcVntvbMiaoRQVs/xcP+cTBDL A9KiH4Ms4NBKQu2h8eLZn5fZSrBzMlA0/9BG9R37bFeetn6SRMwh8sgqMAqMrt/mAZAM eBIg==
X-Gm-Message-State: AOAM530PzRVL+okfxiMipN2pBXa2aUkUtnfCDzmQcCKj831myHc8O7H+ FyANsagUah+PN37/iXE9TlqW/INX7Jr+HXHr33Y=
X-Google-Smtp-Source: ABdhPJxo6us+732n4k7Mn2pzGjtzSXMFtu5VdHrTD1VnHqBfrT27dxBIYlDDkppOImWMgt/2dkiSZjalu2bZwfTPv/A=
X-Received: by 2002:a92:48d7:: with SMTP id j84mr15320856ilg.52.1597694229814; Mon, 17 Aug 2020 12:57:09 -0700 (PDT)
MIME-Version: 1.0
References: <159753241794.3282.10287963728007886569@ietfa.amsl.com> <d07ed430-219a-0435-789b-03378c41fc91@iit.cnr.it>
In-Reply-To: <d07ed430-219a-0435-789b-03378c41fc91@iit.cnr.it>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 17 Aug 2020 15:56:58 -0400
Message-ID: <CALaySJKXQfNVnQYQ0c1PTZbRd1-K7eHe6z0878ZddxEVB703CQ@mail.gmail.com>
To: Mario Loffredo <mario.loffredo@iit.cnr.it>
Cc: Vijay Gurbani <vijay.gurbani@gmail.com>, draft-ietf-regext-rdap-sorting-and-paging.all@ietf.org, gen-art@ietf.org, last-call@ietf.org, regext@ietf.org
Content-Type: multipart/alternative; boundary="00000000000007255f05ad182dcb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/540HWpVXrc11x6CkxSiSz_0zAZY>
Subject: Re: [Gen-art] [regext] Genart last call review of draft-ietf-regext-rdap-sorting-and-paging-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Aug 2020 19:57:13 -0000

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