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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 04 February 2016 17:29 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 D1CEB1A1B0B for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 09:29:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.302
X-Spam-Level:
X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 CuUDCap_bBeP for <ietf@ietfa.amsl.com>; Thu, 4 Feb 2016 09:29:28 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D64B1A1A9E for <ietf@ietf.org>; Thu, 4 Feb 2016 09:29:28 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 077A4BE33; Thu, 4 Feb 2016 17:29:25 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkvthuoxOEy7; Thu, 4 Feb 2016 17:29:24 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 73D36BDD0; Thu, 4 Feb 2016 17:29:24 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454606964; bh=9Oik0H0ZXZs3KunuSC89MI5PNRqOhFUYtNXvnBH0KFs=; h=From:Subject:To:References:Cc:Date:In-Reply-To:From; b=Nm9RSvXTxgPXnrToK1UYSQqxR9oNh7Y6HiKeeSl89nyQ6fQdjWuDoQ2yfxebBoAkI PXHgGRIFCBlEK29TrIEDVuMOyGV/AOnCqQeLoh8aHCJ+p/OqnrHoOoAdSv+jUb6Z9R 6mAzYTW5hrh0i7Z+wbLuKgI7IOMhv32XxIloYd6k=
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <20160125231333.27786.50459.idtracker@ietfa.amsl.com> <56A897AE.9060900@alvestrand.no> <56B371A0.1080200@gmail.com> <E3DC5614-0181-4EE9-BD97-F4B2ABB6931C@vpnc.org>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
X-Enigmail-Draft-Status: N1110
Message-ID: <56B38A73.5060607@cs.tcd.ie>
Date: Thu, 04 Feb 2016 17:29:23 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <E3DC5614-0181-4EE9-BD97-F4B2ABB6931C@vpnc.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/8FPNlZMcq3nyh_YxVJgXHmZT-uA>
Cc: Martin Stiemerling <mls.ietf@gmail.com>, 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: Thu, 04 Feb 2016 17:29:31 -0000

Hi Paul,

On 04/02/16 16:15, Paul Hoffman wrote:
> FWIW, the reason I'm pushing on this is that it feels like the IESG is
> violating the spirit of RFC 5742 by saying "The IETF doesn't want to
> work on this draft, so you should not publish it". That removes a lot of
> the independence from the ISE.

That wasn't the IESG's conclusion but see below...

> 
>> The TCP option detailed in draft-williams-exp-tcp-host-id-opt is
>> extending an IETF protocol, and a very important IETF protocol, i.e.,
>> TCP, that requires IETF review and consensus. Furthermore, the
>> proposed mechanism allows middleboxes to tag TCP connections with
>> additional identifiers that persistently can mark users. Therefore,
>> the IESG concluded that this draft violates RFC 7258, and does so
>> while extending an IETF protocol.
> 
> To reiterate what some others have said on this thread: please specify
> how this draft "violates" RFC 7258. My reading of that RFC and the
> discussion that lead to it, comes to a very different conclusion.

"violates" comes from 5742, option #4.

I think one could indeed argue that the formal IESG response text
isn't at all clear, but it's one of the 5742 options - we don't have
an option for "this extends an IETF protocol in ways that require
IETF review, and it has in fact already had such review (though
not an IETF LC) which rejected progressing with the work, so there
doesn't seem to be any point in sending it back to the IETF, but
since we think this does conflict with BCP188 as well, we're formally
going with option 4."

But I think all of that is clear from the comments and other links
that Martin sent, isn't it? I hope, and assume, it's clear to
the ISE. (Who was cc'd on much of the IESG email on this by the
tracker.)

I should also point out that 5742 email responses to the ISE do
always include pointers to the tracker comments, and do ask the ISE
to consider those, so while the formal response text is I agree
so terse as to be misleading, one has to also read the comments
etc. in the tracker to get the context here.

> 
>> The draft was reviewed in the TCPM working group and received negative
>> feedback:
>> http://mailarchive.ietf.org/arch/msg/tcpm/lM9-Frq945LP12GKbp02hnynuWw
> 
> Note that this is a pointer to a message about a much-earlier version of
> the draft that has less explanatory text than the one being reviewed by
> the ISE. To me, this is an indicator that the draft needed fixing in
> order to meet the requirements of RFC 7258 of documenting the design
> decisions, and that the authors may have done so between -04 and -07.

So that brings up an independent problem for the IESG with this, which
is the one about which we hope to chat with the ISE: It seems wrong to
ask the IESG to do a full IESG review of the modifications that the
authors have made after a first DNP response was sent, for text that
has not had an IETF LC. If the IESG do such a review, then this
basically becomes an IETF stream document as the DNP ends up the same
as a DISCUSS with the IESG and authors haggling about the text
(possibly via the ISE).

So, since the document obviously hadn't undergone major change, I
(and I think other ADs) felt that we had to re-send the same response.
Doing otherwise would I think be damaging to the independence of the
ISE.

Note though that we have had one other 5742 review recently where we
sent a DNP, but where the fix (to remove text about extending IKEv1)
was simple and obvious. In that case we didn't go around the full 5742
review again. So there's stuff to chat about to make that bit of
process work  better I reckon, or at least so folks have the same
expectations of what'll happen with a returning item, after a DNP
response.

> 
>> There have been also other places in the IETF where this draft was
>> presented and rejected.
> 
> If that's true, why did the IESG say that this draft is related to work
> in INTAREA? I interpreted that as a request that the authors take this
> draft to INTAREA, but now you're saying because the draft was

(Was your mail truncated?) Anyway, the intent was not to say "please
send this to the IETF" as explained above.

Cheers,
S.


> 
> --Paul Hoffman
> 
>