Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment]

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 16 July 2018 22:02 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: rfcplusplus@ietfa.amsl.com
Delivered-To: rfcplusplus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D24130E1E for <rfcplusplus@ietfa.amsl.com>; Mon, 16 Jul 2018 15:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qhHkWlNoyBDp for <rfcplusplus@ietfa.amsl.com>; Mon, 16 Jul 2018 15:01:59 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 176B5130E00 for <rfcplusplus@ietf.org>; Mon, 16 Jul 2018 15:01:59 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id c135-v6so14764707ywa.0 for <rfcplusplus@ietf.org>; Mon, 16 Jul 2018 15:01:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DgYheBPZRahgB32mhTIqfgpGArSS6UH8If0BqyLPBEc=; b=Ketnh4oFGwzq8W10MlF3J5BwJ52AOOi1EGk3eme99XttfuL3+1QDXxVmbOcR3E1kGd yRGRBynBo1tpIwN/mkaQC/BuULnA0VUJz1BuddU7W4kz1TixMj/VM6M9ROnDVMv6Eb1G cNWJ4f5Wc/V/BL4x9IjOiAvzHHzrAkR4wOPeFxH+lc1WmpzlJVizmYFT2MDKUfHX/LoS 3TyvCAj5ihMUtOGI9XARw6hB71U97tbjudTNpR3DmFK2bUBGQFhLKwiFjMmac3hkghts jfL1xG/5WVdVxl3KHuBV/zwGvoPiDH2TsFjTieZX7YBy5uA1Oy6xwI7CnF4N8dC5q4q6 hVWQ==
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; bh=DgYheBPZRahgB32mhTIqfgpGArSS6UH8If0BqyLPBEc=; b=GeVZzqrQjCmmUq6br+XDc5GBQ75awTAWMSzLHADeB/BqtNIfnRjpdlH7mZoSSW7FZP JR5ZZPSRW/s9UiaGIkX0FwtQPQAI7mWvgLUqE2sHnZJBMkOL1u66NiNMFwGvXzu4mOrZ C5Ci55+P2Yl5W9UygiOdXpnea5e5Yf5uyT5s5V8H7MRSn4inVjGyhDKcFaJwujML0bQp 5iNYNSckZkuKZJfAVHJrYrDNoC76eeMbwLTh0zXxNpxkq9Am7G68KGmz7vbNYmbAWaol C753BM/01RpTF9P45Nc1XOVnIVtIYlkIg1e6xlpl30DTprXxNZhScmiQwFqGNzdguTBo gClA==
X-Gm-Message-State: AOUpUlHmKVhJIEHHJRDsWRO2tvZeAU66SKI3CbmZFlpxgw2VbJL9AUgW Gb533rwuWmZkmhauz9y0Mh9nLCozkQnhB43ep/4=
X-Google-Smtp-Source: AAOMgpeFdfu/z0ADwcVh0SvhZEDMzN8D6ZJ1oVC+8jBrM02v4knlPsKoscHglHgLIwZYfHFvffLHK2c9a9xPOS4mvPg=
X-Received: by 2002:a0d:f481:: with SMTP id d123-v6mr9112764ywf.27.1531778518134; Mon, 16 Jul 2018 15:01:58 -0700 (PDT)
MIME-Version: 1.0
References: <027c01d4136c$8c86b0a0$a59411e0$@olddog.co.uk> <C6B739D8-81E9-4432-BCFA-987AFA934340@cooperw.in> <CCB29BFD25931BF9547DB993@PSB> <CABcZeBOnZ5c5CpJA4Au5HcYJ1qc=VOoQ7BvDY1KPRE8XjRWZdQ@mail.gmail.com> <2D7B9C1B-22D0-4B9B-BAC5-FE11AD29041B@gmail.com>
In-Reply-To: <2D7B9C1B-22D0-4B9B-BAC5-FE11AD29041B@gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 16 Jul 2018 17:01:44 -0500
Message-ID: <CAKKJt-cA6AipgwFJRd0Kd0vONEYuLWM_8f-=7yuFExKGzz9gHg@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Cc: Eric Rescorla <ekr@rtfm.com>, John C Klensin <john-ietf@jck.com>, Alissa Cooper <alissa@cooperw.in>, rfcplusplus@ietf.org
Content-Type: multipart/alternative; boundary="00000000000072b5f9057124fa2b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/X-M72yXMUdiTZO0Clu1-4Km3RAM>
Subject: Re: [Rfcplusplus] Would notes be dropped [Was: Outlining the experiment]
X-BeenThere: rfcplusplus@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: For discussion of the RFC++ BoF proposal and related ideas <rfcplusplus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfcplusplus/>
List-Post: <mailto:rfcplusplus@ietf.org>
List-Help: <mailto:rfcplusplus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2018 22:02:05 -0000

File under "your mileage may vary" ...

On Mon, Jul 9, 2018 at 9:04 AM Kathleen Moriarty <
kathleen.moriarty.ietf@gmail.com> wrote:

>
>
> Sent from my mobile device
>
> On Jul 9, 2018, at 9:45 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Responding on a narrow point.
>
> On Mon, Jul 9, 2018 at 1:01 AM, John C Klensin <john-ietf@jck.com> wrote:
>
>>
>> By contrast, recent years have shown us several examples of WGs
>> with small numbers of active participants, all or almost all
>> from the same cooperating cluster of companies and more than a
>> few AD-sponsored documents that have made it through the system
>> with substantially no substantive community input on IETF Last
>> Call and then get through the IESG with the minimum number of
>> "yes" votes and many "no objections", presumably deferring to
>> the AD who made the decision to sponsor the document.
>>
>
> I certainly wouldn't argue with the claim that many poor quality documents
> get through the IETF with minimal review, etc. However, I would be wary of
> drawing that conclusion based on the IETF ballots.. Once a ballot is on the
> agenda, it almost always has a Yes from the AD who put it there (whether it
> is a WG document or AD-sponsored), and so the actual effect of "Yes" and
> "No-objection" is the same [0].. For that reason, I almost always ballot
> No-Objection, rather than try to distinguish between the cases where I
> think it's good and I just don't care [1]. My sense is that balloting
> procedures vary within the IESG, but I don't think I'm unique in this
> respect.. I suppose one could argue that I'm (we're)  Doing It Wrong and
> that the ballot procedures ought to be clarified/improved, but in any case
> it's not a signal that I'm just deferring to the AD.
>
>
> For non-sponsoring ADs, a YES means they believe in the work strongly
> enough that they would also be happy to sponsor it.  That’s come up as
> important as ADs roll off. I’ve used no objection in a similar way, but
> purposefully used YES on documents as well. For no objection, it means I
> trust the AD (person balloting didn’t have enough time), my parts are ok
> (no major security issues), or I read the document thoroughly and only have
> comment level suggestions and am fine publishing it anyway.  That maps well
> to the Alternate ballot procedure where no objection is the same as yes -
> it’s fine to publish this.
>

Keeping in mind that I served on the IESG with Kathleen for four years ...

I've balloted Yes on documents I wasn't responsible for,

   - when I thought the drafts were really the right thing to do, enough to
   have sponsored them if asked,
   - and usually, when I think I understand the document well enough to
   have been responsible for it (AD Evaluation, Last Call and Review Team
   comments, IESG Evaluation resolution ballots, and stuff like that).

Someone on the first IESG I served on suggested that mindset to me, and I
have no idea who that would have been now. Practice varies between ADs, at
least a bit.

Of course, literally the first RFC I was "responsible" for, was at Adrian
Farrel's request, because he had a doc that basically everyone even
marginally involved with the document was sponsored in some way by the same
company, and I wasn't, so I had to ballot Yes while marginally
understanding the draft, and under no delusion that I was a RTG AD or
likely to be one on this planet.

The details are at https://datatracker.ietf.org/doc/rfc7026/ballot/. It was
... short.

Spencer