Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tcpeno

Joe Touch <touch@isi.edu> Mon, 06 February 2017 16:25 UTC

Return-Path: <touch@isi.edu>
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 D51FE129F16; Mon, 6 Feb 2017 08:25:19 -0800 (PST)
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 qFp0WBcToHut; Mon, 6 Feb 2017 08:25:14 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 AB429129F0F; Mon, 6 Feb 2017 08:25:14 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v16GOpeX029468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Feb 2017 08:24:52 -0800 (PST)
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>, "Holland, Jake" <jholland@akamai.com>, David Mazieres expires 2017-05-03 PDT <mazieres-pkpvjfsmw3tssivxtan28pfsqw@temporary-address.scs.stanford.edu>, "tcpinc@ietf.org" <tcpinc@ietf.org>
References: <D668D28F-42BB-40A4-81D1-1FF2D3D95ECB@akamai.com> <87fujvonza.fsf@ta.scs.stanford.edu> <1FD85C9B-BE52-4E9F-A6D9-54BAD0425C8A@akamai.com> <655C07320163294895BBADA28372AF5D48D1DE65@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <35ea9173-b362-15fb-d324-cc0cb46ad1f8@isi.edu>
Date: Mon, 06 Feb 2017 08:24:51 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <655C07320163294895BBADA28372AF5D48D1DE65@FR712WXCHMBA15.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/KzojviNrLyD4o3P6Idxql_81tUE>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpinc] [tcpm] WGLC for draft-ietf-tcpinc-tcpeno
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 06 Feb 2017 16:25:20 -0000


On 2/4/2017 10:57 PM, Scharf, Michael (Nokia - DE) wrote:
> [CCing TCPM for the part that matters to TCPM]
>
>> 4. citing drafts in support of future large SYN options:
>> “Is there harm in doing this?  E.g., is it bad practice to cite internet
>> drafts (non-normatively, of course) in an RFC?”
>>
>> 4.a. Citing drafts does go against the current BCP, as I understand it.
>>
>> From https://tools.ietf.org/html/rfc2026#section-2.2, in a big star-box:
>> “Under no circumstances should an Internet-Draft be referenced by any paper,
>> report, or Request-for-Proposal, nor should a vendor claim compliance with an
>> Internet-Draft.”

FWIW, Internet Drafts are cited when it is appropriate to refer
non-normatively to a concept.

Additionally, RFC20236 was published when Internet Drafts actually
expired; that's a fantasy these days, as they are archived by the ISOC.

>> There’s a partial exception right afterward, which I’m not sure how well it
>> applies in this case:
>> “
>>    Note: It is acceptable to reference a standards-track specification
>>    that may reasonably be expected to be published as an RFC using the
>>    phrase "Work in Progress" without referencing an Internet-Draft.
>>    This may also be done in a standards track document itself as long
>>    as the specification in which the reference is made would stand as a
>>    complete and understandable document with or without the reference to
>>    the "Work in Progress".
That would be exactly the exception that does apply here.  If you want
to talk about using extended option space, then it's better to cite a
known discussion thereof and provide a summary than to speculate about
it or give the impression that it is not an investigated topic.
...
> While TCPM discusses large SYN options (for a long time already), all known solutions have downsides. I do not believe that a non-TCPM document should speculate on the feasibility solutions.
>
> Michael

Agreed, but the point is that this doc probably SHOULD state that all
known solutions have deployment difficulties. An option (such as this)
that has SYN space limitations and does not address this issue is (IMO)
giving a misleading impression about its own limitations.

Joe