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.)