Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options

John Leslie <john@jlc.net> Fri, 22 February 2013 18:36 UTC

Return-Path: <john@jlc.net>
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 E588A21F8890 for <tcpm@ietfa.amsl.com>; Fri, 22 Feb 2013 10:36:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.08
X-Spam-Level:
X-Spam-Status: No, score=-106.08 tagged_above=-999 required=5 tests=[AWL=0.519, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gekzgh-3xzWs for <tcpm@ietfa.amsl.com>; Fri, 22 Feb 2013 10:36:18 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 222AA21F8810 for <tcpm@ietf.org>; Fri, 22 Feb 2013 10:36:18 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id E2D2A33DA3; Fri, 22 Feb 2013 13:36:17 -0500 (EST)
Date: Fri, 22 Feb 2013 13:36:17 -0500
From: John Leslie <john@jlc.net>
To: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
Message-ID: <20130222183617.GG63436@verdi>
References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com>
User-Agent: Mutt/1.4.1i
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 22 Feb 2013 18:36:21 -0000

Scharf, Michael (Michael) <michael.scharf@alcatel-lucent.com> wrote:
> 
> As co-chair, I would really appreciate further opinions, most notably
> regarding change (C).

   I was too confused by the original request to comment.

   Since you ask, I traced down the actual issue, which is on
draft-ietf-tcpm-experimental-options, not draft-touch...

   The plain fact is that the IESG state is three Yes vs. five Abstain.
Abstain is the way the IESG "votes" "No".

   The remaining ballot positions are two Discuss vs. five No-Objection.
No-Objection is the way the IESG "votes" "don't care".

   I recommend perusing the Narrative Minutes at
www.ietf.org/iesg/minutes/2012/narrative-minutes-2012-12-20.html
in which I heard a serious concern about variable-length nonces and
an opinion that the WG might not be able to agree on a length.

   My personal opinion is that variable-length is a terrible idea; and
that if we can't agree on a single length we should just give up.

   Frankly, I'm not sure the IESG is ready to approve this, even with
a fixed-length nonce. Wes has been supportive of this I-D; but Wes will
be off the IESG by the time this could return. Five Abstains is a
pretty stiff barrier (though I have seen more).

   I think the discussion in the Narrative Minutes is a good one; and
I agree with several IESG members who said we should look to an IANA
registry, strictly first-come-first-served, where _any_ individual
(even one with no connection to the group wanting to experiment) can
request a number, with no requirement to document the purpose of the
experiment, and be assured of a unique number.

   You asked for other opinions: that's mine.
====
   To Joe's specific questions:

A) I don't care what it's called
B) OK, but "unassigned values" needs a definition
C) only (i) is acceptable; (16 bits is fine)

   (I would expect we'd reserve the first 16-bits of known uses: any
further length they use is their problem, not ours.)

   If we ever exhaust 16-bits, I consider that sufficient justification
for allocating another TCP Option Number reserved for experimental use.

--
John Leslie <john@jlc.net>