Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options

Joe Touch <touch@strayalpha.com> Thu, 01 August 2019 14:20 UTC

Return-Path: <touch@strayalpha.com>
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 938A3120193 for <tcpm@ietfa.amsl.com>; Thu, 1 Aug 2019 07:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Level:
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 4gJPnKJrfGWs for <tcpm@ietfa.amsl.com>; Thu, 1 Aug 2019 07:20:28 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 C4BB51200CC for <tcpm@ietf.org>; Thu, 1 Aug 2019 07:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uWkIIcGyVTeMBJhcumYX8Kq2SOnkS0Gbmb5WmnNdd2Y=; b=Gx3xsFvCKwl1HxBsdG/vxL8dB nCAHSVHVUqCeIVBCAsFbJ8alEv4a+63VEiLR0YFVEDa9OkLyXVgAK/8DW5cdYB7xOGxdRrFb3oF+h 3Si5ER6rA19iTuaS075JbYG6uFjdlyC+3GZFXHwqdvL4Fil/GaEs5aOPJpDa2dSTH11y9GooPspEo g5jP2voX6kIwOCFIIzso207V9GAVzEbeCse1pYQ5K3JEYDAlr62xmSxNx3v4BzTX4QEehNp0jlMCy 9wYzvSID6sUhr074mPPwLK/M7Sje9DIBq9ojj9bxpkNXVkV5qUKK/pfngH3jGloy3Rq/AVkQhdS5E Xgo7hSPVA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:52156 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1htBwN-00106D-QQ; Thu, 01 Aug 2019 10:20:28 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_80D3DFC7-03B4-4E1B-BCFC-2B0C668B6E24"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312F7CAF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Date: Thu, 1 Aug 2019 07:20:20 -0700
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Message-Id: <9D52173A-CA9B-47DA-9EA4-46B4823DD2A9@strayalpha.com>
References: <787AE7BB302AE849A7480A190F8B9330312EB710@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <c99ba8aba56ad3e1cebb27e7a47ff4b4@strayalpha.com> <787AE7BB302AE849A7480A190F8B9330312F7CAF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
To: mohamed.boucadair@orange.com
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/k1GCqDjREFvN2aGnb8HI8DnNtqE>
Subject: Re: [tcpm] draft-ietf-tcpm-rfc793bis-14: options
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 01 Aug 2019 14:20:32 -0000

Hi, Med, 

See below…

Joe

> On Jul 31, 2019, at 10:38 PM, mohamed.boucadair@orange.com wrote:
> 
> ...
>  
> [Med] What I had in mind is to import the option layout and key information into 793bis.

I don’t think it’s particularly useful to duplicate information this way - esp. for experimental options.

> What I’m hoping with this change is to avoid having discussion similar to https://mailarchive.ietf.org/arch/msg/tcpinc/fVCnrvMouTdeIuwTytoBRNmztHU <https://mailarchive.ietf.org/arch/msg/tcpinc/fVCnrvMouTdeIuwTytoBRNmztHU> (end of the message) each time a new option is discussed.    

We’re going to have that discussion every time anyway - that is about 
a) whether a new option under development should be treated as experimental or standards-track from the start
b) whether to endorse squatting on assigned code points

Defiance is not ignorance. No amount of text avoids the former.

>  
> - these are not details needed for standards-compliant operation
>  
> [Med] I’m not sure to parse this comment. RFC6994 is a standard track RFC.
>  
> (esp. because they shouldn't be used for final standards-track options).

The sentence is explained in the note I put below it - although the method is standards-track (as is congestion control, FWIW), the details are not critical to a minimal, standards-compliant implementation for a few reasons:

- standards-compliant implementations shouldn’t be deployed publicly with use of experimental options at all (at best, disabled by default)
- 6994 explains how others will interpret the fields of those code points anyway, so if you ignore them you’re just risking overlapping use with others. the length of the EdIDs (esp longer values) makes that sufficiently unlikely anyway

----