IETF Logo Mail Archive

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 20:43 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 52131120048 for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 12:43:53 -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 JgVaJdlVDne0 for <last-call@ietfa.amsl.com>; Sat, 25 Jan 2020 12:43:52 -0800 (PST)
Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 5D94D12001E for <last-call@ietf.org>; Sat, 25 Jan 2020 12:43:52 -0800 (PST)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.21.169]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 00PKhdhD007523 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jan 2020 12:43:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1579985031; x=1580071431; i=@elandsys.com; bh=s9ib2Qj0YZNmX81NkC2out83rrBCQTWZlY5gBgaSHaE=; h=Date:To:From:Subject:In-Reply-To:References; b=dHW2SDDI4rMXZnNwowF5AqluNTCwLuPSpqGoKXjwL4oyXp2RC+7fwRHIWnDVMlEhi FXV46jNRacRgcYYFqRXbaZESGO3YR1ajGx5t4SYo8wuSDMBw+iFmSQoW90cYfkQB88 9zZkxyiUX0ZB5KPr4LRrRr1kLsHXqkKHjYS6nQWA=
Message-Id: <6.2.5.6.2.20200125115103.0c0d7748@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 25 Jan 2020 12:43:08 -0800
To: Joel Halpern Direct <jmh.direct@joelhalpern.com>, last-call@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <0b556483-fc96-6447-6edd-d77382b03aac@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> <6.2.5.6.2.20200125012252.0c0d5220@elandnews.com> <0b556483-fc96-6447-6edd-d77382b03aac@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/TLJDlimbNIZT3IMK7_TGpDsiFZA>
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 20:43:53 -0000

Hi Joel,
At 07:04 AM 25-01-2020, Joel Halpern Direct wrote:
>As the document says, there already is an IESG statement.  There are 
>several concerns with this.  The important one as far as I am 
>concerned is that the IESG can change its policy.  While it might be 
>bad practice to change it without IETF rough consensus, that is not 
>aformally required.  This way, changing it DOES require IETF rough consensus.
>And it seems to me (and others I have talked to) that it is quite 
>appropriate for an IETF stream BCP to update IETF Stream policy. 
>That is where we define such things.

A BCP does not prevent the IESG from approving the publication of a 
(IETF) RFC as it is the IESG which makes a determination about 
whether there is or there isn't rough consensus.  The available 
recourse in case of disagreement is to request the IESG to reverse 
its decision.  Has there been any appeal in such cases over the last 
five years?

Regards,
S. Moonesamy

v2.23.0 | Report a Bug | By Email