Re: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis

Joe Touch <touch@isi.edu> Fri, 21 July 2017 15:19 UTC

Return-Path: <touch@isi.edu>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333F31317A4; Fri, 21 Jul 2017 08:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 LIqydVMAU1NL; Fri, 21 Jul 2017 08:19:14 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 5CA59131761; Fri, 21 Jul 2017 08:19:14 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v6LFISMU027463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 21 Jul 2017 08:18:42 -0700 (PDT)
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "tcpm@ietf.org" <tcpm@ietf.org>
Cc: "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>
References: <AM5PR0701MB2547BD06C515C0854E09FAAD93CD0@AM5PR0701MB2547.eurprd07.prod.outlook.com> <AM5PR0701MB25475FA77B86528822E0473D93A40@AM5PR0701MB2547.eurprd07.prod.outlook.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <cb5dbd61-5860-fc38-63b1-8bd7a67166a3@isi.edu>
Date: Fri, 21 Jul 2017 08:18:26 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <AM5PR0701MB25475FA77B86528822E0473D93A40@AM5PR0701MB2547.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/S-UtSqaEROh8BzGBifBIEbYQpBU>
Subject: Re: [tcpm] Working group acceptance call for draft-touch-tcpm-2140bis
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jul 2017 15:19:15 -0000

Hi Michael, et al,

On 7/21/2017 2:37 AM, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> If reviews would disagree with BCP status, a consensus call will be required and TCPM may decide to request publication as INFO instead, which would be a simple editorial change without wasting work.
I disagree with both this approach and this conclusion.

The original RFC was informational because it provided no specific
recommendations.

The whole point of this document centers around the concept of BCP:
- a survey of existing deployed practice
- an analysis of which behaviors are recommended and which should be
corrected
- an indication of the boundaries within which future deployments can be
safe

If the WG were to decide that this doc were to be informational, then
there would be no reason to have spent WG time and resources debating
those issues, and (more to the point) the specific recommendations would
need to be removed.

Speaking for myself both as author and WG member, I don't think it is
useful to waste those resources if we don't have consensus to create a
BCP document. Although any document could be reclassified at any time in
the WG process, I see no reason to delay that debate for this document
or treat it differently.

I.e., if there is insufficient WG consensus to move forward as BCP, I
propose that this revision is not needed and we can save a lot of time
and effort now.

Joe