Re: [tcpm] On TCP option codepoints

"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> Wed, 09 October 2013 16:58 UTC

Return-Path: <michael.scharf@alcatel-lucent.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 BAE9A21F89EB for <tcpm@ietfa.amsl.com>; Wed, 9 Oct 2013 09:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOv8O1gO+fKb for <tcpm@ietfa.amsl.com>; Wed, 9 Oct 2013 09:57:57 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1432C21F9DE9 for <tcpm@ietf.org>; Wed, 9 Oct 2013 09:57:09 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r99Gut87008698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Oct 2013 11:56:57 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r99Gur6l000908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 18:56:54 +0200
Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.203]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 9 Oct 2013 18:56:53 +0200
From: "Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com>
To: "mallman@icir.org" <mallman@icir.org>, Wesley Eddy <wes@mti-systems.com>
Thread-Topic: [tcpm] On TCP option codepoints
Thread-Index: AQHOxFVP70P5YCtSS/uinwT7ojflKZnskfXA
Date: Wed, 09 Oct 2013 16:56:52 +0000
Message-ID: <655C07320163294895BBADA28372AF5D0DA306@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <52544EF5.2040200@mti-systems.com> <20131008183633.984F9232DD1F@lawyers.icir.org>
In-Reply-To: <20131008183633.984F9232DD1F@lawyers.icir.org>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Joe Touch <touch@isi.edu>
Subject: Re: [tcpm] On TCP option codepoints
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: Wed, 09 Oct 2013 16:58:05 -0000

> In general I am not adverse to naming and shaming.  And, I agree with
> this:
> 
> > I think saying "unauthorized use by company X's product Y and Z"
> would
> > not be mistaken as an endorsement.

I guess shaming is not IETF's core business. But the IANA page could probably link to IETF contributions if available (such as draft-ananth-middisc-tcpopt). Some of the Web pages I found originate from admins that observe an option in a trace, go to the IANA page, and wonder why the codepoint is not mentioned there...

However, I was not aware of any IETF "disclosure" for the two codepoints identified by my small Web search. 

> I would also say the above could be amended with ", but fixed in
> version
> V" or something like that.  I.e., flagging the problems is fair, but I
> also think it'd be fair to indicate the problems have been taken care
> of.

Naming products could be difficult. Products may exist with various versions and different releases, and without detailed insight it is probably impossible to figure out if a codepoint is indeed used, or not. Also, company X might actually not be only user of the codepoint. For instance, in case of a security vulnerability, some malware might try use the codepoint as well... Taking care of this class of users is non-trivial ;)

Michael