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

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 26 January 2020 23:11 UTC

Return-Path: <jmh@joelhalpern.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 9D66D1200E5 for <last-call@ietfa.amsl.com>; Sun, 26 Jan 2020 15:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.636
X-Spam-Level:
X-Spam-Status: No, score=0.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 8HH0N26Kmxjb for <last-call@ietfa.amsl.com>; Sun, 26 Jan 2020 15:11:41 -0800 (PST)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A6DB1200DB for <last-call@ietf.org>; Sun, 26 Jan 2020 15:11:41 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 485TCd45cpz1ny8c; Sun, 26 Jan 2020 15:11:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1580080301; bh=8CJW4jDKf/qkOC/Qd/ESQpw38xoho8nLMtT/rgJHTxQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RX3jTa760Vr8a63/uCIGkoEzOx5BMfjtnGGvhNGzOVLKV1sJVAkbrPaW92aKUN4LA /04e85MWyN426OC1Wug8oTjsyJrLtLmoN36hF4lPr4CsK1Sdl6qX8YGFR24WNG4ahz sBTPD+ZNMO1s1wPuBRBiToeUlpRW6uWjSYMiUuxo=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 485TCd0XgPz1nyY5; Sun, 26 Jan 2020 15:11:40 -0800 (PST)
To: Rob Sayre <sayrer@gmail.com>
Cc: last-call@ietf.org
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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <4a02a412-3761-c02d-c3f9-d6b0c833815e@joelhalpern.com>
Date: Sun, 26 Jan 2020 18:11:39 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <CAChr6SyzoTxJd1eMy+z_xLPhdE7v7UDE4LTop9JjooHkzvGEiQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/pGMasrHhRtH0t5pPY-sWUSl3C9k>
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:11:43 -0000

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.

Yours,
Joel

On 1/26/2020 6:03 PM, Rob Sayre wrote:
> On Sun, Jan 26, 2020 at 12:10 PM Christopher Wood <caw@heapingbits.net 
> <mailto:caw@heapingbits.net>> wrote:
> 
>     On Sat, Jan 25, 2020, at 12:30 PM, Joel M. Halpern wrote:
>      > With regard to citing RFC 5742, I will leave it to the judgment
>     of the
>      > document shepherd and AD as to whether they believe that is
>     called for..
>      > It seems more distracting than useful to me, but I will act as
>     they direct.
> 
>     For the reason above, I do not think citing RFC 5742 is necessary.
> 
> 
> There are 4 cases that could happen now:
> 
> Document Actions (WG) [ No IETF Last Call Issued ]
> Document Actions (WG) [ Last Call Issued, No Consensus ]
> Document Actions (Individual to AD) [ No IETF Last Call Issued ]
> Document Actions (Individual to AD) [ Last Call Issued, No Consensus ]
> 
> For each of these cases, there will be some interaction with RFC 5742 if 
> the document is to be published on another stream (the alternative 
> proposed in the draft).
> 
> Whether or not this draft is edited, it would be helpful to know what 
> people think is going to happen to these cases. No publication at all? 
> Or publication with one of the IESG messages in 5742? I looked for some 
> Informational and Experimental documents languishing in the IESG queue, 
> since the authors don't seem comfortable discussing the concrete 
> examples they are reacting to.
> 
> https://datatracker.ietf.org/doc/draft-seantek-ldap-pkcs9/  (676 days ago)
> https://datatracker.ietf.org/doc/draft-gutmann-scep/ (153 days ago)
> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/  (318 
> days ago)
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-lta-use-cases/   (269 days 
> ago)
> 
> IESG reviews that result in case #4 or #5 from RFC 5742 would likely 
> lead to no publication at all. As others have pointed out, the RFC 
> Editor could theoretically ignore this, but that doesn't seem likely in 
> today's environment.
> 
> It's not clear if this proposal intends to leave some documents 
> unpublished (maybe that is ok, but it should be clear).
> 
> thanks,
> Rob
> 
> 
> 
>