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

Joe Touch <touch@isi.edu> Fri, 22 February 2013 18:46 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 4267921F8A90 for <tcpm@ietfa.amsl.com>; Fri, 22 Feb 2013 10:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.021
X-Spam-Level:
X-Spam-Status: No, score=-103.021 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, 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 ikk-0SS2Vq6J for <tcpm@ietfa.amsl.com>; Fri, 22 Feb 2013 10:46:12 -0800 (PST)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A907E21F89A3 for <tcpm@ietf.org>; Fri, 22 Feb 2013 10:46:12 -0800 (PST)
Received: from [128.9.184.100] ([128.9.184.100]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1MIjHLU000728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 10:45:19 -0800 (PST)
Message-ID: <5127BCC0.3030903@isi.edu>
Date: Fri, 22 Feb 2013 10:45:20 -0800
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: John Leslie <john@jlc.net>
References: <511ED5B3.1040803@mti-systems.com> <511ED5F2.4030100@mti-systems.com> <2A886F9088894347A3BE0CC5B7A85F3E9AA10D6224@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> <20130222183617.GG63436@verdi>
In-Reply-To: <20130222183617.GG63436@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
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:46:13 -0000

On 2/22/2013 10:36 AM, John Leslie wrote:
> 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".

AFAICT, 'discuss' is how they vote "no", since a position can pass with 
abstains so long as there are enough "yes" votes. Nothing happens until 
a discuss is resolved, though, so that's the only vote that blocks 
things if there are enough 'yes' positions.

>     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.

This note posted a solution that addresses IESG concerns to see what the 
WG feedback would be.

>     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).

Some of those positions might be changed based on this update.

>     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.

The IESG lives in a fantasy world where IANA registry assures users of 
assignment; we live in the real world where that doesn't happen. So we 
can update this doc to encourage people to register, but the solution 
MUST be robust to the squatting that a) has already happened and b) will 
continue to happen, either out of malice or ignorance.

Joe


>
>     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>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>