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

Rob Sayre <sayrer@gmail.com> Sun, 26 January 2020 23:37 UTC

Return-Path: <sayrer@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 21A001200CC for <last-call@ietfa.amsl.com>; Sun, 26 Jan 2020 15:37:21 -0800 (PST)
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_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 24vFVeyDw01O for <last-call@ietfa.amsl.com>; Sun, 26 Jan 2020 15:37:19 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 B6E2212004A for <last-call@ietf.org>; Sun, 26 Jan 2020 15:37:19 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id m25so8029893ioo.8 for <last-call@ietf.org>; Sun, 26 Jan 2020 15:37:19 -0800 (PST)
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=9dDVpDt/Nh8PV7a6gIxBSF9QzXQU8Hp32tWnRNWbABc=; b=TB1zS5r7BVfESjGHcN2Sh59uwLuQLIOTRyuUI/H1PmI5SA03v6bAY/PgPNU71e3DPa i3L4MBdT5TExjb3r4TOR7zsRzKmB/EVHoTy8DMzFkUC6rhH6ZxD1dXap+DiwExdwJ8XO LEUdWP+eWmWOO/V5oOWxx7EIJJov+LIps9HBgKdltHPRsWeyB/dBb6E2gQ1w5sXLZ5x0 +H3wyN4BNrsscaPw/D1Tvwc4mtefcBvdePBDgd8QWB612D/MtiM1tdxY+X78VwrLpWwh ccrKFqZaFzFKY9OAcZbpZJX3vOUOzl3SNix4hxDItTJJmyix+bE+axDzaqx/ztw15Aqm EVnA==
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=9dDVpDt/Nh8PV7a6gIxBSF9QzXQU8Hp32tWnRNWbABc=; b=S0pfydH70mAeAMCZdiR+ur2HddnbFa8jr70s1HfgDoC5HVc+ZfQY6yuC2xLaRTdVcz 4lkIQylK1GjVwM09ZnF5cOVtHU8sH31m1hUQzqWHqJEK9jrudPq6fr65H3VEcOkXuQVD BG6RR3XgLaNIYMmU8OiWPpbJ9GuKhDKK9fs1D+8GIhf14B2fFbTbIzw30w1Lvn2xSBUs jyCQ8m3Ji3zQ00ITdGKkm4CCXu9n7OkRJ++UlBRXhDAAp1BlEO4/31C/qp2fT+pkKaO6 IlTxx2rDJ9q2wxVmEcs/n8yuWtA15tNroOBLNXJmH9PRReDf4qwQGNBgndjjqfwhmIRk UqSA==
X-Gm-Message-State: APjAAAUv3lTBAA2TxuymaFRwvtr3Lp7x4iGByAyQFLoBSERLVrpJs9Tc UXNLV0MwwHrRGENMo1GAXqVIN7ocs1M5po7S5UI=
X-Google-Smtp-Source: APXvYqyEa86/xkl0olfq0fibjFjmCrVdXBT9OTRlLsRE5vRSGE+Wp0ENDdG6KCv505dwq12064geY1Kx9mNNpCdsM/k=
X-Received: by 2002:a02:cd82:: with SMTP id l2mr10884046jap.103.1580081839024; Sun, 26 Jan 2020 15:37:19 -0800 (PST)
MIME-Version: 1.0
References: <CABcZeBOMVYpEYaEUzYsa0ApDfGtA6oD5P67A40=HQVBN+yTuKQ@mail.gmail.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> <c220d99f-d69a-ede0-630b-2f593412daca@joelhalpern.com> <CAChr6Sy9=1Gewkq-E=+d9sLFrGS0kL33RUNLxvs44tX0czoUCg@mail.gmail.com> <b6b6bc7a-998b-4cd7-3684-18df02c6a537@joelhalpern.com> <238b2086-80cb-4227-947e-aa7bd565e79e@www.fastmail.com> <CAChr6SyzoTxJd1eMy+z_xLPhdE7v7UDE4LTop9JjooHkzvGEiQ@mail.gmail.com> <4a02a412-3761-c02d-c3f9-d6b0c833815e@joelhalpern.com>
In-Reply-To: <4a02a412-3761-c02d-c3f9-d6b0c833815e@joelhalpern.com>
From: Rob Sayre <sayrer@gmail.com>
Date: Sun, 26 Jan 2020 15:37:06 -0800
Message-ID: <CAChr6Sys0COO0-cOo=uDZLLTG3-1MBJOfNCyGz3Ew0ZXgTXFQg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: last-call@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bb2ede059d137807"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/3JXtKyX6cC5PFDuy00q96C5oih4>
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: Sun, 26 Jan 2020 23:37:21 -0000

Hi,

I didn't ask for any edits to your document in that message. I was just
wondering what might happen to these documents, in the absence of a
concrete example (which you refuse to provide).

For example, this draft could prevent publication of security technologies
that disintermediate some vocal subset of IETF participants (like, say,
router manufacturers). As I reflect on this draft, I am not sure it is a
good idea. I could see it curbing process abuses, but I can also see it
entrenching insecure protocols that people make money from exploiting.
That's why I want to learn about some concrete examples.

thanks,
Rob

On Sun, Jan 26, 2020 at 3:11 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:

> In my view, the question of how one could / may / should / might publish
> a document that does not achieve IETF rough consensus is not the task of
> this document.  The text simply observes that there are means outside of
> the IETF stream to publish (some of) such documents as RFCs.
>
> This is an IETF process RFC, not a publication tutorial.
>