From nobody Tue Aug 18 06:54:25 2020
Return-Path: <vijay.gurbani@gmail.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 4EEF83A0AC7;
 Tue, 18 Aug 2020 06:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level: 
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
 header.d=gmail.com
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 zWMt5G4qb0NK; Tue, 18 Aug 2020 06:54:16 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com
 [IPv6:2a00:1450:4864:20::535])
 (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 C4BC83A0ADA;
 Tue, 18 Aug 2020 06:54:15 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id i26so15323246edv.4;
 Tue, 18 Aug 2020 06:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=0iID7431v6YsdCdlIgks9QksvwIrDEZCrck0h+M+Clw=;
 b=CsS/JX49hTLmzOE6IC7MDmZQpIZd1QuYWpGE30P7k0N2Cyy43NlWYAbdsfs8I7ykrh
 /WCNbK9+bZpK3A01UkHQo6EsJ0DBYVsHzS3uxvyK1wtPcXrEYy3cLlyaTmUH0n/7HSAX
 ogNwPEwhwe94/WSIeunVPWZJRjaUs1dc9m7iyx6VpL8eC1VezJK9l6xBusViX6D2nRTO
 s75fcijuI/KKiRT/L6gFrBmGhw30V4S1/Zi2aEP3XfBh+n9iamsxDRHR3o9KxOskni7m
 Ff3bEJWOLzfl6HcpP7DHyf0R74A4iMAQ51luhjFpgm7XpHqx2T1akrnxOdeHuXIqr0g5
 3xnA==
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=0iID7431v6YsdCdlIgks9QksvwIrDEZCrck0h+M+Clw=;
 b=Y6CFOuV+Lag9ghx9mTAJxGngWsbZ5Pt1ojW+JWHxaeAxXj1rIlfEIlJqvBc3pt/wN9
 SfhDSymhzaNOZx/Lg72m7Ka8Z8aFSpxsOh06JoZIfvUcQTLqvqMVnTEphiE86oni6SEf
 gEGMQ8g24IPck/fneEA7di3IYhtNhzWZC0xmuyyUkOVlE+W3KTtCkAoQj35naY0XjVl2
 v+kVQszMOQnBk424UQcIJo/UhnT7SDCWmczDEOfpzJgs9YH5u5mfg0vlfR1KFeNjXXkZ
 3uDoL4yS/cY/9pehNxSCko5r5iQnjVQ/LLun4tD2pMBN7K/a+7SVSsNICFpE0fXM4tQl
 Nugg==
X-Gm-Message-State: AOAM530nDsG2JWnwTegYgVFWgZyPNRqZ7jUbUQq6HwaBO6X7BgHLqsjf
 mZH14y2LjnjUIGcw3keiMDq+3/db8CU/qzC+7jc=
X-Google-Smtp-Source: ABdhPJwpwtLpzznTo5lqpErGMakdSruM7EQeW7cPXHpsvVJQ1PeMMNfepNFLS1h/Rd39633IWW3ogz0AUxV+0P0gPrI=
X-Received: by 2002:aa7:d5d5:: with SMTP id d21mr20214421eds.229.1597758854219; 
 Tue, 18 Aug 2020 06:54:14 -0700 (PDT)
MIME-Version: 1.0
References: <159753241794.3282.10287963728007886569@ietfa.amsl.com>
 <d07ed430-219a-0435-789b-03378c41fc91@iit.cnr.it>
 <CALaySJKXQfNVnQYQ0c1PTZbRd1-K7eHe6z0878ZddxEVB703CQ@mail.gmail.com>
In-Reply-To: <CALaySJKXQfNVnQYQ0c1PTZbRd1-K7eHe6z0878ZddxEVB703CQ@mail.gmail.com>
From: Vijay Gurbani <vijay.gurbani@gmail.com>
Date: Tue, 18 Aug 2020 08:52:45 -0500
Message-ID: <CAMMTW_L33v50vPupJT-fviqWQNap5B1tAE71GfsAHS8DOnQfag@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: Mario Loffredo <mario.loffredo@iit.cnr.it>, 
 draft-ietf-regext-rdap-sorting-and-paging.all@ietf.org, 
 "gen-art >> General area reviewing team" <gen-art@ietf.org>, last-call@ietf.org,
 regext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f14aa605ad273854"
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/J-lvC9cNp-CaiAnvFXcBDlhQB2w>
Subject: Re: [regext] Genart last call review of
 draft-ietf-regext-rdap-sorting-and-paging-15
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>,
 <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>,
 <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2020 13:54:21 -0000

--000000000000f14aa605ad273854
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 17, 2020 at 2:57 PM Barry Leiba <barryleiba@computer.org> wrote=
:

> Hi, Mario and Vijay.
>
> 7942 says that the Implementation Status section is inappropriate to
> include in an RFC because it=E2=80=99s transient information that changes=
, and is
> usually obsolete quickly.
>
> But I don=E2=80=99t interpret Vijay=E2=80=99s suggestion as asking you to=
 leave the
> section in the document in it=E2=80=99s entirety, but, rather, to put non=
-ephemeral
> information about a reference implementation into an appendix.  If there=
=E2=80=99s
> 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.
>

Dear Barry and Mario: Thanks for paying attention to my review, and Barry
is indeed correct.

Especially that the two implementations listed in the implementation
section appear to be almost fully conformant to the draft, and also appear
to have reasonable documentation, etc. around them.  It would seem to be a
waste of code to simply take this section out without preserving the good
work done here that can get other implementers started immediately.

Cheers,

- vijay

--000000000000f14aa605ad273854
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Aug 17, 2020 at 2:57 PM Barry Lei=
ba &lt;<a href=3D"mailto:barryleiba@computer.org">barryleiba@computer.org</=
a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div><div dir=3D"auto">Hi, Mario and Vijay.</div><=
/div><div dir=3D"auto"><br></div><div dir=3D"auto">7942 says that the Imple=
mentation Status section is inappropriate to include in an RFC because it=
=E2=80=99s transient information that changes, and is usually obsolete quic=
kly.</div><div dir=3D"auto"><br></div><div dir=3D"auto">But I don=E2=80=99t=
 interpret Vijay=E2=80=99s suggestion as asking you to leave the section in=
 the document in it=E2=80=99s entirety, but, rather, to put non-ephemeral i=
nformation about a reference implementation into an appendix.=C2=A0 If ther=
e=E2=80=99s a stable implementation that can be used in that way, I think i=
t would be appropriate, and I agree with Vijay that it could be helpful to =
other implementors to have that information available.</div></blockquote><d=
iv><br></div><div>Dear Barry and Mario: Thanks for paying attention to my r=
eview, and Barry is indeed correct.=C2=A0 <br></div><div><br></div><div>Esp=
ecially that the two implementations listed in the implementation section a=
ppear to be almost fully conformant to the draft, and also appear to have r=
easonable documentation, etc. around them.=C2=A0 It would seem to be a wast=
e of code to simply take this section out without preserving the good work =
done here that can get other implementers started immediately.</div><div><b=
r></div><div>Cheers,</div><div><br></div><div>- vijay<br></div></div></div>

--000000000000f14aa605ad273854--

