Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07

Eliot Lear <lear@cisco.com> Sat, 30 January 2016 08:28 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69851B3661 for <ietf@ietfa.amsl.com>; Sat, 30 Jan 2016 00:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 OhVKVrspZkDN for <ietf@ietfa.amsl.com>; Sat, 30 Jan 2016 00:28:10 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0D81B365F for <ietf@ietf.org>; Sat, 30 Jan 2016 00:28:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8718; q=dns/txt; s=iport; t=1454142490; x=1455352090; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=w2LthX3fSQO7VFtQWXHZa7ACDR67HOFY3CtJENoXGF8=; b=BX+z/ZXOpNWvMWyIFWYJi80t8RtSQoaRRPTF0YdixaNkkWAB5eER9VS+ enfApFJBSPxYaMLznvvXyGg3k5XnlpCYKueULweshfe2Z7Bv344MeX2hE gG+nz4x2pV/1XCOMqgs+wYnD3GLI36bwZlEBbIS7u8Lb3eAB7FRNZduuG E=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B7AgDjcqxW/xbLJq1djVGvI4ITDoFjhg8CgWUUAQEBAQEBAYEKhEIBAQQjVQEQCxgJFgsCAgkDAgECAUUGAQwIAQGIF7EYjmEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4IikaHMoE6AQSSbIQDgnqBY4huiR+FUY4+HgFDggIZgVI7iSsBAQE
X-IronPort-AV: E=Sophos;i="5.22,368,1449532800"; d="asc'?scan'208,217";a="648919651"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2016 08:28:07 +0000
Received: from [10.61.70.44] (ams3-vpn-dhcp1580.cisco.com [10.61.70.44]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u0U8S7u7030319; Sat, 30 Jan 2016 08:28:07 GMT
Subject: Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07
To: Ted Hardie <ted.ietf@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
References: <20160125231333.27786.50459.idtracker@ietfa.amsl.com> <56A897AE.9060900@alvestrand.no> <CA+9kkMC+43PFvd_ZdR4EXV6zW2+FH67dpXeghWU8NtvbB8RzOg@mail.gmail.com>
From: Eliot Lear <lear@cisco.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56AC7416.2000206@cisco.com>
Date: Sat, 30 Jan 2016 09:28:06 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <CA+9kkMC+43PFvd_ZdR4EXV6zW2+FH67dpXeghWU8NtvbB8RzOg@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="dxpd3emSBk4xuKwj6ispVsgqxjmgXkNX2"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/zUx9UawQrAcQ-K9HGIS0qFtcg8E>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2016 08:28:12 -0000

Hi,


On 1/27/16 4:50 PM, Ted Hardie wrote:
>
>
>    Recent proposals discussed in the IETF have identified benefits to
>    more distinctly identifying the hosts that are hidden behind a shared
>    address/prefix sharing device or application-layer proxy.  Analysis
>    indicates that the use of a TCP option for this purpose can be
>    successfully applied to some use cases. 
> ​The proposals have identified benefits according to the authors,
> but the IETF declined to adopt them because there were far bigger
> downsides.  This abstract gives the opposite impression, which is not
> exactly kosher.

I agree with Ted about the abstract; that at the very least it should be
reworded.  Referring to the IETF needs to be fairly done in the
independent series.  We already have enough problems with people
distinguishing IETF from independent work.  However...

>
>  
>
>     Armchair lawyers will also note that the procedure refers to "IETF
>     specifications". An independent-submission RFC is *not* an IETF
>     specification.
>
>
> ​Yes, and we have historically said that publishing things in
> the ISE stream when they counter IETF specifications can
> only be done when the IESG deems there to be no conflict
> with IETF specifications.  This clearly does conflict with the
> thrust of efforts in the IETF (e.g. tcpinc). ​

RFC 5742 is quite explicit.  BCP88 itself is not a specification but a
Best Current Practice, and limits its applicability to IETF, and not
independent, specifications.  As to whether this conflicts with "the
thrust of efforts in" tcpinc, that is not what the IESG wrote.  If it
had written it, the justification would have to again be based on what
is stated in RFC 5742, specifically in Section 3.  There should be at
least sufficient information to indicate what the nature of the conflict
is.  Having a different opinion than that of the IETF or a working group
is *not* a justification for non-publication, but rather a justification
for the existence of the ISE.

In short, I believe the IESG erred procedurally, and would suggest they
revisit their approach.  Haralds query about attaching an IESG note
seems entirely appropriate.

Eliot