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

S Moonesamy <sm+ietf@elandsys.com> Sat, 25 January 2020 10:04 UTC

Return-Path: <sm@elandsys.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 7F8CC120072 for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 02:04:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 uJHvoJIs0aEB for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 02:04:56 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id E365C12003F for <last-call@ietf.org>; Sat, 25 Jan 2020 02:04:55 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.146.21]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00PA4dLp022957 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jan 2020 02:04:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579946693; x=1580033093; i=@elandsys.com; bh=UPTJiZy/XvWbGUIu72LJG4p4gf+//vnzK/5Z7xE3q+0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=0EncfpxccNdz3bSy3nzFX/Dm6k8N/CddJUcDUQihZblrHdenJXlWbKn1TMImzhxvB 4kpTmKxNyUYcOuZDF1vNOGmZIzJ6BrGgjr1BUf9rSZbh8InU7EA1TCYHqS29nUiMg4 Tt/LEEUH70M9l3BtbEukTS/rMtYgCOzdHE9UDQxk=
Message-Id: <6.2.5.6.2.20200125012252.0c0d5220@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 25 Jan 2020 02:04:19 -0800
To: "Joel M. Halpern" <jmh@joelhalpern.com>, last-call@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Cc: Rob Sayre <sayrer@gmail.com>
In-Reply-To: <530e6ac9-4c52-fbf3-61fa-584ba8839f7e@joelhalpern.com>
References: <157988932717.22102.17207308469919846350.idtracker@ietfa.amsl.com> <6.2.5.6.2.20200124135843.14565e38@elandnews.com> <530e6ac9-4c52-fbf3-61fa-584ba8839f7e@joelhalpern.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/jVdSn78KZ-KJnrMA0NRExtGaX9g>
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, 25 Jan 2020 10:04:56 -0000

Hi Joel,
At 02:57 PM 24-01-2020, Joel M. Halpern wrote:
>The reason this document does not directly update the boilerplate is 
>that the last revision of the boilerplate RFCs explicitly said that 
>from now on the IAB updates the boilerplate without needing a new 
>RFC to do so.  Hence, this document is only concerned with 
>tightening the rules, not writing the boilerplate.

Ok.

>With regard to updating 2026, this updates the text in 2026 that 
>permits informational or experimental RFCs without IETF rough 
>consensus.  it removes that permission from the IETF stream.  I do 
>not know how to clarify the document in this regard.

What you are attempting to do is, in my opinion, about IETF Stream 
policy.  There isn't a written policy as such for that Stream.  One 
alternative is for the IESG to issue a statement to affirm its 
intention not to publish non-standards track documents if it believes 
that there isn't rough consensus to publish.

There is a point which Mr Sayre made about transparency.  One of the 
advantages of operating in a transparent manner is that it helps the 
public to determine, for example, whether a person is acting in good faith.

Regards,
S. Moonesamy