Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice

"R. Atkinson" <rja.lists@gmail.com> Sat, 08 February 2020 19:19 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301C712004C for <last-call@ietfa.amsl.com>; Sat, 8 Feb 2020 11:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 F1imHAtZ6idP for <last-call@ietfa.amsl.com>; Sat, 8 Feb 2020 11:19:15 -0800 (PST)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 87100120026 for <last-call@ietf.org>; Sat, 8 Feb 2020 11:19:15 -0800 (PST)
Received: by mail-qk1-x736.google.com with SMTP id v195so2572416qkb.11 for <last-call@ietf.org>; Sat, 08 Feb 2020 11:19:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2UCphUFbA90pu4ih9CFLFGvutQu9Z0DDKNVtEWn+x0Q=; b=a2+L5RQIbjO5Vc9DOqbS4JvNa59f/+Dw25uG6a4jZpt/SybCgJd5XD1Q3+oK1vNZ8a 7RZoZL8z7KEmb8QwL5Te2EOin/JhQJaG7dinpeN89aXPxYAondC/TwPU+3cj8gq129+S lFWjVwvseT68F1zuHaoOYMK6ch8PHazzasOxPm/XeMPy9k1j7qWuwlXpdYU7oRUiMQBf RG/MTchrIMeEfQ6cnaQddTECIrUkJUVayfSZXSmuiaiBh1tqWX2KPLJScHqODeF1t/oT 2inkxuUCsPMbgQlipEvrxH0EutYdY8gDYCfAIbxaNbmVMpV06LlHJKdch3xNqQnFhas1 WlIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2UCphUFbA90pu4ih9CFLFGvutQu9Z0DDKNVtEWn+x0Q=; b=becw2OPM9RNVYIKlHQ5puf4keN/h5NM2Dvzym6jbWxcQGTFCKiF4Aj245qlGbo+/al i64fh4hMEO1bkEZXsWvXLjGLWlC8Ih8QP8F3zLJuEOSL29x6cyWDuvNvHFJMzd1/5J7k rBoNHp0+gtb79OQQjY3wAIPrvLBM+TgNZr1BD35YBDpiOFfahYzp34ssHzFoKa0yRT7/ J6ZP7z4lMgBjKnybdCFE3LyW7zyNE4yPbI+XBuVJMaGaNF5yVT18PHNHXROVQ83Lh86d Dsl1KRN6XuHXtf5A0hmSaG7BHmW6LkufUf36TZQipfE92BG9qRoIYtTf893qrotzr8nD JKUQ==
X-Gm-Message-State: APjAAAWnXgNzUJRkK3fFMcXzDd7O66nDNos2gKi4Zoq7Yx4mwKktnoYp DDgmsC+BW3uGM+9DJ4yVAyoKlEZc
X-Google-Smtp-Source: APXvYqxfdh3LQvmdvDvRthAxXvHRy92r+PKssqWqiNbdKF1JGOx2IC1lame/E0cqYCJM0QcTpyFjDg==
X-Received: by 2002:a37:a80e:: with SMTP id r14mr4579286qke.192.1581189554719; Sat, 08 Feb 2020 11:19:14 -0800 (PST)
Received: from [10.30.20.11] (pool-72-83-171-38.washdc.east.verizon.net. [72.83.171.38]) by smtp.gmail.com with ESMTPSA id t23sm3308652qtp.82.2020.02.08.11.19.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Feb 2020 11:19:14 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: "R. Atkinson" <rja.lists@gmail.com>
In-Reply-To: <CAChr6SzXFPbcPL++gftey9T_nCVBds+Sb1Z4MpkC2GraZCNfKw@mail.gmail.com>
Date: Sat, 08 Feb 2020 14:19:13 -0500
Cc: last-call@ietf.org, Joel Halpern <jmh@joelhalpern.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A10A397-12E4-4C2C-9A81-DA1F6DE8E0F3@gmail.com>
References: <CABcZeBOMVYpEYaEUzYsa0ApDfGtA6oD5P67A40=HQVBN+yTuKQ@mail.gmail.com> <CAChr6Sz7vihWaoeG8H11JzQ5YqrbYLPLneuY3PD4syMYEaKQ4w@mail.gmail.com> <99d34ee9-8ea6-a77f-39fc-f1889a050358@joelhalpern.com> <CAChr6SwHd2=Qf2SSbQeKs1CS_c1UuBqPEtO_x4MmF71iv0zE9Q@mail.gmail.com> <CABcZeBMdonehuZ3re4UnGY2_B6A2sOBqkoE+m4SfBa8N3vYEhg@mail.gmail.com> <CAChr6Sw1LSXj=L2WAu=R1QfBi4UFDXC5Z6EODqwJ6-z9o5Z5vw@mail.gmail.com> <CABcZeBPBhGZDxnh2p=trL8yHveBiMsy38+-G_7oQu_eR+45d5w@mail.gmail.com> <CAChr6SyNTsz9uZNiN16OHLj6e=Xhcn1A8pr105Of+y_Jw8HSFw@mail.gmail.com> <994c4462-ef24-6d46-3bec-8aa5e14b9f78@joelhalpern.com> <CAChr6Sy80-74g4cgKESwmdn3WSNjU_2XsjkChH9_8-ELnytC_Q@mail.gmail.com> <20200125184550.GF77560@kduck.mit.edu> <CAChr6SzXFPbcPL++gftey9T_nCVBds+Sb1Z4MpkC2GraZCNfKw@mail.gmail.com>
To: Rob Sayre <sayrer@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/OC7REr_mGf-PbCYxAyBHZjtGilU>
Subject: Re: [Last-Call] Last Call: <draft-halpern-gendispatch-consensusinformational-02.txt> (IETF Stream Documents Require IETF Rough Consensus) to Best Current Practice
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Feb 2020 19:19:17 -0000


> On Jan 25, 2020, at 14:44, Rob Sayre <sayrer@gmail.com> wrote:
> 
> OK. The questions in my original message are still unanswered. Currently, dissenting or non-consensus Informational or Experimental documents can be published through any of the channels, with the rationale that they don't require consensus anyway.

I’ve been active in IETF for ~30 years now, including being chair/co-chair of some WGs.

(A) As near as I can tell, this is not true for the IETF stream at present, unless the IESG approves.  The proposed change would mean the IESG could not ignore lack of IETF Consensus, as near as I can tell.  I support that change limiting the IESG authority.

(B) True for other streams IF AND ONLY IF either (a) IESG doesn’t complain during the existing pre-publication processes or (b) the IESG complains but the responsible authority for the alternate stream proceeds with publication anyway [very unlikely].

> While I understand (and have understood this entire time...) that this document only intends to change the IETF stream process, my question is whether it would also add to the set of documents that are considered an "end run".

As near as I can tell, documents have __always__ been categorised either as “end run” or “not end run” by the IESG on a document-by-document basis, after considering the standards environment at the time of attempted/proposed publication.  

This I-D does not propose to change the timing/method of that determination, as near as I can tell.

Yours,

Ran