Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

Warren Kumari <warren@kumari.net> Thu, 27 February 2020 20:06 UTC

Return-Path: <warren@kumari.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C4B3A0AD3 for <spring@ietfa.amsl.com>; Thu, 27 Feb 2020 12:06:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 dvL-lqnRU_kR for <spring@ietfa.amsl.com>; Thu, 27 Feb 2020 12:06:40 -0800 (PST)
Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26273A0ACE for <spring@ietf.org>; Thu, 27 Feb 2020 12:06:39 -0800 (PST)
Received: by mail-qt1-x82b.google.com with SMTP id e20so266357qto.5 for <spring@ietf.org>; Thu, 27 Feb 2020 12:06:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/KiOtUrVRX1tXjQeiqyCxQQqgl5VKJFHUDDfoLGKmVM=; b=ynT2CD1Jat27vnZNalMIXvZEBRQg7UcDlC6vvajEDNJ2Ipfuo9rGLw3ANwj5Pj9jfc MyBBbNa46OFdXIK6ESTXY0P+6uM0TgvW9FFIAkqL2CHN6Gh+tEaFViaRv0kBiAniPRKD xGoFCVsZE2/XZWeMwPfTcpzmlOc7rX1Ani8IExfut2mGiuHlLzPTy5v9C1c4zudlK1Uu CJT+C8okCeTv7Jvo9qIpEvSr4E0C3c96/hFcH1efBMT7WDGl6x2eqi681XZlqWT0q9xq NB07CB59wbwKTYlN+CgUYHHKnGCN1gzGH9fR9p0/Wroxw3o/ISBLertGXodHucapRagX SXXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/KiOtUrVRX1tXjQeiqyCxQQqgl5VKJFHUDDfoLGKmVM=; b=oOdYDRNog/OI5AzhdjEwtT2R36yATCpmSBTOHFExLMghkosEnkWsEyA9hqeOgljK+P 8D5Wzkp7smz10r96ek9rZBX4FZPqACa7bTYwmQ1TL8l4ouOsfBhKPHYKDnQiXhzGIaSf Ar3M5gimTqBiMCpUEE2xNp1WCZ2CKSz2RZx8IIRW8/l2T7GA9u/KuHrO2fsPIGQe3S7A M9n4X0xzdmg2/3hh+17fB8mSRIVD2/eC/Zj8DsXlqYaZIhBmZCL36zrMwOQ5853wUSpk mSTwMnAKNUaysnyFHq9wYjMJ4OsHgIYvdAFFlIDtCxJjUDY7hp0iaDeVydQvhPL5ov7x 8M5Q==
X-Gm-Message-State: APjAAAUyJEPVwbzvLqCDmlzDkoTqiqn2yjPBwC+1xzp+dzKYRFy1ZYOc uqFjlKl/xPcncP/PmQJdU9FUvxj33VMjut2x34pxOA==
X-Google-Smtp-Source: APXvYqyAdRtn9H3mvU0aJin0X8zaaZQCT9MFntNMSTseHUWwPNRGapJDdfupfJHLUzKcz9j7XUa8qFjT72xWMZ6rT2g=
X-Received: by 2002:ac8:6c26:: with SMTP id k6mr1042573qtu.364.1582833998725; Thu, 27 Feb 2020 12:06:38 -0800 (PST)
MIME-Version: 1.0
References: <F88E3F76-DD4B-4807-A458-85FABFF20D96@gmail.com> <5D218BFB-0D6F-4F7D-858F-B571A67DC47F@leddy.net> <CAHw9_iJ_ipEvU0NUx44XbK0_DrLe_GRw6G=m+chK4wZcRP8BMg@mail.gmail.com> <ACA082A4-BC78-4C63-9F91-5C9A44F47642@cisco.com> <b693c244-95f9-473e-de21-166393280d18@gmail.com> <CAHw9_iL6oM73JnSU1QL0+PRohSH6sEskD=enH7QsPrWiUfStDg@mail.gmail.com> <CAOj+MMGQqoMXnU-VAjx_PTL-ObbsXTYqhjwuQG6eDxfCwmyJ9g@mail.gmail.com> <30908949-9150-4784-A0FD-69F92889FB3D@fugue.com> <b5cbd567-bfa3-c803-d3d2-025cbcbccfd8@joelhalpern.com>
In-Reply-To: <b5cbd567-bfa3-c803-d3d2-025cbcbccfd8@joelhalpern.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 27 Feb 2020 15:06:02 -0500
Message-ID: <CAHw9_iL5Y47_r0vdgmFY-qJH5muTChWvoj9JLO-gvgjJ-QZc3w@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Ted Lemon <mellon@fugue.com>, SPRING WG List <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>, Bob Hinden <bob.hinden@gmail.com>, "Zafar Ali (zali)" <zali=40cisco.com@dmarc.ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/kfQaKR1j1wL3xd1X1IwSlVGtQUI>
Subject: Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 20:06:42 -0000

On Thu, Feb 27, 2020 at 2:27 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> THere is one nuance that is worth noting.  It is not for the case of a
> controversial document.
>
> Rather, the case where +1 can be useful is when the question is whether
> the working group even cares about the document.  I have had several
> cases of calls for adoption or WG last call where there was almost no
> response on the mailing list.  In the absence of decent indication, I as
> chair feel compleed to say "no, I do not see enough support to adopt /
> advance / ... this document".

That's a very good point - thank you.

> In that situation, even +1s can help.  (And yes, I do watch for the case
> of all the +1s coming from the same company as the author, and then
> start judging whether they are folks who participate, along the lines
> Warren outlined.)

Yup.

Also specific flexibility / human judgement aspect is an important
part of the IETF - chairs are expected to have knowledge of their WG,
and be able to weight viewpoints, ignore clear company / coalition
bias, etc. If they abuse this, there is the appeal process. ADs are
equally make judgement calls -- and again, there is an appeal / recall
procedure. Appeals are a critical part of our process, and should be
used when appropriate (the very fact that they exist and can be
invoked is also a useful mechanism for mitigating abuse).

W

>
> Yours,
> Joel
>
> On 2/27/2020 2:07 PM, Ted Lemon wrote:
> > On Feb 27, 2020, at 1:59 PM, Robert Raszuk <robert@raszuk.net
> > <mailto:robert@raszuk.net>> wrote:
> >> It is very unfortunate that IETF does not have a good way of
> >> retrieving judgement from real group of folks who understand given
> >> proposal.
> >
> > We do.   It’s called “substantive comments.”
> >
> >> "+1" is just only one demonstration of it. Humming is another. Raising
> >> hands one more. We say there is no voting but while there is no formal
> >> ballot box nor even e-ballot version of it all of the above ways to
> >> gather "consensus" are examples of voting.
> >
> > Actually, the purpose of humming is not to make a decision, but to
> > figure out whether there is general consensus.   If you ask for a hum
> > and you get a 50-50 response, there probably isn’t consensus, and you
> > might just say “we don’t have consensus” and go on to figuring out how.
> >    If the “no” hum has no loud participants, you might say “looks like
> > we’re good to go, we’ll confirm on the list.”   If there’s someone
> > humming loudly no when everybody else is in favor, and you don’t know
> > why they’re humming that way, that’s a good time to ask them if they are
> > willing to explain.
> >
> > But bear in mind that humming does not take place on the mailing list,
> > and that consensus is called on the mailing list, not in the room.
> >
> > On the mailing list, people pretty much have to raise objections
> > verbally.  No amount of +1s should be considered meaningful at all.
> > The work is chartered; the wg is supposed to do it.   If there are no
> > objections, and people feel the document is ready, then it should move
> > forward, whether there are +1s or not.   If objections are raised, and
> > they are substantive (that is, not opinion or conjecture), then they
> > have to be addressed.   They can be addressed by saying “we considered
> > that, and the working group as a whole agrees that the problem exists,
> > but it doesn’t need to be addressed because this document is only
> > applicable in a situation where the objection raised doesn’t matter.”
> >   Or it can add text to address the objection, as Brian I think has
> > suggested.   Or it can do additional work to address the problem, as
> > Brian has also suggested.
> >
> > But the WG can’t simply ignore the objection.  That is not what “rough
> > consensus” means.
> >
> >
> > _______________________________________________
> > spring mailing list
> > spring@ietf.org
> > https://www.ietf.org/mailman/listinfo/spring
> >



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf