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> Fri, 24 January 2020 22:21 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 BB259120B12 for <last-call@ietfa.amsl.com>; Fri, 24 Jan 2020 14:21:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 STmFMBR2VFFc for <last-call@ietfa.amsl.com>; Fri, 24 Jan 2020 14:21:21 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 670AD120C2E for <last-call@ietf.org>; Fri, 24 Jan 2020 14:21:21 -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 00OML8td021299 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <last-call@ietf.org>; Fri, 24 Jan 2020 14:21:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579904479; x=1579990879; i=@elandsys.com; bh=x6P2+TpVDKRvymslWEgA4RmyAg8v3RauQWiyexa0204=; h=Date:To:From:Subject:In-Reply-To:References; b=huL0P2hTWUECARPaMiNn3azydM6oLlLyoRio4zWIPSCqf+w7I8vtIwBxlPyJVEvP6 Dw3DtSUXuz95edl+hvWc6Oxmyu3SHqiFxh1iObv0nNWdm3zhVOgPljbLOgzSnVbq8B Qg/va3N+dxBn1D1JzxmVgrIz03eXNlQJGka+Vvu8=
Message-Id: <6.2.5.6.2.20200124135843.14565e38@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 24 Jan 2020 14:20:36 -0800
To: last-call@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <157988932717.22102.17207308469919846350.idtracker@ietfa.am sl.com>
References: <157988932717.22102.17207308469919846350.idtracker@ietfa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/QJbUZ58xbDFEatUsyNCxmugmUnc>
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: Fri, 24 Jan 2020 22:21:27 -0000

Hello,
At 10:08 AM 24-01-2020, The IESG wrote:
>The IESG has received a request from an individual submitter to consider the
>following document: - 'IETF Stream Documents Require IETF Rough Consensus'
>   <draft-halpern-gendispatch-consensusinformational-02.txt> as Best Current
>   Practice
>
>The IESG plans to make a decision in the next few weeks, and solicits final
>comments on this action. Please send substantive comments to the
>last-call@ietf.org mailing lists by 2020-02-21. Exceptionally, comments may

The usage of uppercase in Section 3 makes it look like the IETF only 
understands an absolute prohibition when it is written in 
uppercase.   Is that really necessary?

The current boilerplace (RFC 7841) states has the following text: "It 
represents the consensus of the IETF community".  Is there a reason 
why that that RFC if is not being update to match what Section 3 defines?

Which section of RFC 2026 will be updated?

An IETF participant is allowed to disagree with the IESG if he/she 
believes that the IESG is taking a bad decision by approving the 
publication of a document.  There hasn't been any such case in recent 
IETF history.  I don't understand the rationale for having such a 
significant change to address certain corner cases when there isn't 
any factual information about such cases.

Regards,
S. Moonesamy