Re: [tcpinc] Warren Kumari's Yes on draft-ietf-tcpinc-tcpeno-17: (with COMMENT)

Warren Kumari <warren@kumari.net> Wed, 29 November 2017 21:48 UTC

Return-Path: <warren@kumari.net>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25875126CF6 for <tcpinc@ietfa.amsl.com>; Wed, 29 Nov 2017 13:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 QGZSsUGqBW2t for <tcpinc@ietfa.amsl.com>; Wed, 29 Nov 2017 13:48:03 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 59E8B124239 for <tcpinc@ietf.org>; Wed, 29 Nov 2017 13:48:03 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id t8so9215884wmc.3 for <tcpinc@ietf.org>; Wed, 29 Nov 2017 13:48:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WnPL9H9rQwYt7kULYqkoM+HAN8OscPgY6RNuxU2YdoA=; b=Y3eBRnYZ6zthv3mjcfbeHM2IHaVRWyzzOn56nhN6aJwlrWjHp43rkY2yck6HiDyxWO mW3wad/c/AznRatg+LOodFOk6cnEIXUT6En/lt6j1ByZmu6kz7xp+dBwgil+FMh7lFkl 12dLgu7oRMtTjaaYzNJkAWl1z2YehTIhjITfUQbenbjg6Mc39YA6Q09QLFOi/pKrwiiY fjHw/dS1JBMD9SFJ+8j+umyEBPy4COFUE4UVo6WSZy7Y1WAGaL6fduxRBwZH4tJWgE6d WLvQzklBBzHnPUIVQefMfx5T3ZbS8WKbVd0mdOsy8AwY50qpFJRA0rCWv/YtXtLHwEEP fOgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WnPL9H9rQwYt7kULYqkoM+HAN8OscPgY6RNuxU2YdoA=; b=aAP+OV3LrkJdQSN9SxJSuIciDZs6texM9sRDP4GHxbO+BtnGNoGs5JjnmvJ3jEe5Xa CBRqQnCXzkZw+6MELX4Xav4072CN2IQ3fN4mZwq4bG61skeHTpGfa8CQ41eyYpmRpMja k55y3hGu39TftBO/JJYvqqaAxPHAtsqtKPy9Y8E081S8AGLUeLIF7W0FC+Hf7UUeUVG6 q2+s6cd0TE/6XT+CVgqz2lD5ibTMZ7eGmEk6SFzEVF00Jdn1AkEnnWBvfjdzWNyHXhon MDAnqtPbI93fcQXGCJ8X2odDeVChuHxE+gMMu1AGdmgUDdTtOCkxBW+Q2Wmv2Aic7dLJ qFXA==
X-Gm-Message-State: AJaThX5VWzy0+CYUXFwHp2T7DCpSLAxZm0+/468U4hnZKOEnw5k6m5Yz InP11T7Hnd/VYh46qR4YpvvD/r0E1zyGB6qwfhshGw==
X-Google-Smtp-Source: AGs4zMZx241vOmUh1zx2GUGD0mLOZdJCRKVZbfqcmIsVMz02g1PnRAAcHE2I/G72v5hbewonMHJtvKEbaU69OgkJ/Vc=
X-Received: by 10.28.239.12 with SMTP id n12mr149490wmh.140.1511992081670; Wed, 29 Nov 2017 13:48:01 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.160.149 with HTTP; Wed, 29 Nov 2017 13:47:20 -0800 (PST)
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD94A37@MX307CL04.corp.emc.com>
References: <151190700381.8033.14862699233030432760.idtracker@ietfa.amsl.com> <CE03DB3D7B45C245BCA0D243277949362FD94A37@MX307CL04.corp.emc.com>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 29 Nov 2017 16:47:20 -0500
Message-ID: <CAHw9_iLS750N4q2xUeMvpnApJR4=C9MhiEfiCO9V=xuWuCJKDw@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-tcpinc-tcpeno@ietf.org" <draft-ietf-tcpinc-tcpeno@ietf.org>, "tcpinc-chairs@ietf.org" <tcpinc-chairs@ietf.org>, "tcpinc@ietf.org" <tcpinc@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/wp_daaZyIjl0zqG852VQAgj7AXc>
Subject: Re: [tcpinc] Warren Kumari's Yes on draft-ietf-tcpinc-tcpeno-17: (with COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Nov 2017 21:48:06 -0000

On Wed, Nov 29, 2017 at 4:14 PM, Black, David <David.Black@dell.com>; wrote:
> Hi Warren,
>
> Many thanks for the Yes position and for the positive comments on the shepherd writeup ... two comments as shepherd are inline ...
>
> Thanks, --David
>
>> -----Original Message-----
>> From: Warren Kumari [mailto:warren@kumari.net]
>> Sent: Tuesday, November 28, 2017 5:10 PM
>> To: The IESG <iesg@ietf.org>;
>> Cc: draft-ietf-tcpinc-tcpeno@ietf.org; Black, David <david.black@emc.com>;;
>> tcpinc-chairs@ietf.org; Black, David <david.black@emc.com>;; tcpinc@ietf.org
>> Subject: Warren Kumari's Yes on draft-ietf-tcpinc-tcpeno-17: (with
>> COMMENT)
>>
>> Warren Kumari has entered the following ballot position for
>> draft-ietf-tcpinc-tcpeno-17: Yes
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I'd like to echo what others have said, especially Adam's Section 4 comment,
>> and Benoit's "what is the actual experiment?" - if this doesn't explain what
>> the experiment will test, perhaps it should be Std Track? (Section 9, while
>> nice, doesn't really cover this). Just because it is new / untested doesn't
>> mean that it cannot be standard and then updated later.
>
> [David>] "new/untested" is the major reason.  The Transport Area has a practice of applying Experimental status to TCP changes until there is sufficient "soak time" (e.g., operational experience) to demonstrate that they don't break anything.

Oh, well there you go then. Happy.

>
>> I was also confused by the "option kind" - I'd assumed that it was simply a
>> term of art for TCP option, but seeing as Spencer is also mystified I'm
>> guessing not -- for my own education, can you please explain?
>
> [David>] The "term of art" explanation is correct, e.g., see: https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1 .

Wow, somehow I'd missed that <embarrassed> -- I'd always thought that
they were just TCP Options and were Type-Length-Value. Rereading
RFC793 "Kind" is starting to feel a bit familiar though...

Thank you,
W

>
>> Also, once again a nice shepherd writeup from David.
>>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf