Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07
John C Klensin <john-ietf@jck.com> Sat, 30 January 2016 20:18 UTC
Return-Path: <john-ietf@jck.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 AF3891A892A for <ietf@ietfa.amsl.com>; Sat, 30 Jan 2016 12:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-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 OVc21RKXAhMn for <ietf@ietfa.amsl.com>; Sat, 30 Jan 2016 12:18:17 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D075A1A8927 for <ietf@ietf.org>; Sat, 30 Jan 2016 12:18:17 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aPbyE-000OEN-F7; Sat, 30 Jan 2016 15:18:10 -0500
Date: Sat, 30 Jan 2016 15:18:05 -0500
From: John C Klensin <john-ietf@jck.com>
To: Eliot Lear <lear@cisco.com>, Ted Hardie <ted.ietf@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
Subject: Re: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07
Message-ID: <3350DFABED5E1DDD190D0C27@JcK-HP8200.jck.com>
In-Reply-To: <56AC7416.2000206@cisco.com>
References: <20160125231333.27786.50459.idtracker@ietfa.amsl.com> <56A897AE.9060900@alvestrand.no> <CA+9kkMC+43PFvd_ZdR4EXV6zW2+FH67dpXeghWU8NtvbB8RzOg@mail.gmail.com> <56AC7416.2000206@cisco.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/jEWCO6WbpLfOSZbAhLVTFAJnRXU>
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 20:18:19 -0000
--On Saturday, January 30, 2016 09:28 +0100 Eliot Lear <lear@cisco.com> wrote: >> 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. One clarification: independent of whatever 5742 has to say about what complaints the IESG can make, the instructions and guidance for the ISE are in 4846. For all practical intents and purposes, that document say that the IESG can only make two types of "do not publish" requests and both, as Brian notes, are _requests_: (1) "If you decide to publish, please delay doing that for a reasonable period of time until related IETF work can be completed and published". (2) "We think this is a dumb and/or dangerous idea and that the ISE should consider whether or not to publish it." As far as I know, the ISE (and the RFC Editor before we split the ISE function out) have never declined to honor a delay request that involved a reasonable and more or less fixed amount of time. As to the second, while I would expect the ISE to give special consideration to such a comment from the IESG, any member of the community can make similar comments and expect them to be treated seriously. I believe the general expectation is that such comments will be taken seriously to the extent to which they are well and clearly justified and that comments based on assertions of authority are less likely to be treated seriously. The latter is, of course, consistent with most of our expectations about arguments and statements of positions in the IETF. That is ultimately a key part of what "independent" is all above. The most powerful option that either the IESG or any member of the community has is to prepare and submit a document containing a dissenting view, one that explains why a particular idea is a bad one. john (Like Brian, I'm a member of the Editorial Board and I hope it is no surprise or secret that these issues are being discussed there as well.)
- Re: Results of IETF-conflict review for draft-wil… Harald Alvestrand
- Re: Results of IETF-conflict review for draft-wil… John C Klensin
- Re: Results of IETF-conflict review for draft-wil… Fernando Gont
- Re: Results of IETF-conflict review for draft-wil… Jari Arkko
- Re: Results of IETF-conflict review for draft-wil… Ted Hardie
- Re: Results of IETF-conflict review for draft-wil… Brian E Carpenter
- Re: Results of IETF-conflict review for draft-wil… Stephen Farrell
- Re: Results of IETF-conflict review for draft-wil… S Moonesamy
- Re: Results of IETF-conflict review for draft-wil… Eliot Lear
- RE: Results of IETF-conflict review for draft-wil… Dr. Sandeep Joshi [MU - Jaipur]
- Re: Results of IETF-conflict review for draft-wil… Brian E Carpenter
- Re: Results of IETF-conflict review for draft-wil… John C Klensin
- Re: Results of IETF-conflict review for draft-wil… Ted Hardie
- Re: Results of IETF-conflict review for draft-wil… Brian E Carpenter
- Re: Results of IETF-conflict review for draft-wil… Martin Stiemerling
- Re: Results of IETF-conflict review for draft-wil… Paul Hoffman
- Re: Results of IETF-conflict review for draft-wil… Stephen Farrell