Re: [tcpinc] AD review of tcp-eno
David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Fri, 28 July 2017 20:22 UTC
Return-Path: <dm-list-tcpcrypt@scs.stanford.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 2D944131C91; Fri, 28 Jul 2017 13:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 PHNtJbLJEDlz; Fri, 28 Jul 2017 13:22:41 -0700 (PDT)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01E1B12ECF0; Fri, 28 Jul 2017 13:22:40 -0700 (PDT)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id v6SKMehC021229; Fri, 28 Jul 2017 13:22:40 -0700 (PDT)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id v6SKMe5R099229; Fri, 28 Jul 2017 13:22:40 -0700 (PDT)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
Cc: draft-ietf-tcpinc-tcpeno.all@ietf.org, tcpinc <tcpinc@ietf.org>
In-Reply-To: <36738439-CAEC-4694-87EF-00EC91426D9C@kuehlewind.net>
References: <55B07DA5-E274-4720-A919-83483094B9A0@tik.ee.ethz.ch> <80C705CD-8A24-49A9-A1B8-6FA7B2162941@kuehlewind.net> <87fudh62um.fsf@ta.scs.stanford.edu> <36738439-CAEC-4694-87EF-00EC91426D9C@kuehlewind.net>
Date: Fri, 28 Jul 2017 13:22:40 -0700
Message-ID: <87shhg2twv.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/9UbJ_nSDPWcS9y_ja3mE-5-GMT8>
Subject: Re: [tcpinc] AD review of tcp-eno
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: Fri, 28 Jul 2017 20:22:42 -0000
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> writes: > This is what early allocation is for. We could have also asked for > early allocation for tcpinc as soon as the spec was reasonably stable > but given there was no-one who was actually about to deploy this in > the Internet, it was probably not necessary. Is there something I can put in the document to clarify that early allocation should be the norm not the exception? The think I like about "Specification required" is that RFC7120 2a says: The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC. So I like the fact that the specification required allows early allocation *if* an RFC is anticipated. Basically I want something in this document to make it clearly easier to get ENO TEP IDs than TCP option kinds. On a related note, I think there might be an inconsistency in the draft that I would appreciate some input in resolving. Section 7.1 says: TLS can currently only be added to legacy applications whose protocols accommodate a STARTTLS command or equivalent. TCP-ENO, because it provides out-of-band signaling, opens the possibility of future TLS revisions being generically applicable to any TCP application. Of course what, we really wanted to say was TCP-ENO was designed to support TCP-use-TLS. However, if I recall, there's a citation issue because we aren't supposed to cite an internet draft in an RFC unless the two will become RFCs at the same time, and TCP-use-TLS has been delayed. But then in 0x30, we still cite TCP-Use-TLS to assign it code point 0x30. Given the work invested in TCP-Use-TLS, should we indeed reserve TEP Id 0x30 for that effort in case anyone wants to pick up it up again, and if so how should we do that without citing an expired internet draft? Can we just reserve TEP ID 0x30 for future use by TLS and cite TLS? Or what should we do? Thanks, David
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Black, David
- Re: [tcpinc] AD review of tcp-eno Joe Touch
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Joe Touch
- Re: [tcpinc] AD review of tcp-eno Joe Touch
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno David Mazieres
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Kyle Rose
- Re: [tcpinc] AD review of tcp-eno Kyle Rose
- Re: [tcpinc] AD review of tcp-eno David Mazieres
- Re: [tcpinc] AD review of tcp-eno David Mazieres
- Re: [tcpinc] AD review of tcp-eno Black, David
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)
- Re: [tcpinc] AD review of tcp-eno Mirja Kuehlewind (IETF)