IETF Logo Mail Archive

Re: [Mtgvenue] comments on draft-ietf-mtgvenue-iaoc-venue-selection-process-04

Dave Crocker <dhc@dcrocker.net> Mon, 30 January 2017 15:34 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD58129530 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 07:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 zfJHqsFTmHBD for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 07:34:44 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 575D8129527 for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 07:34:44 -0800 (PST)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v0UFaFdU027685 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Jan 2017 07:36:15 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1485790575; bh=M1oo8OwRgkpwMIhIq4Y2HPlBcchlkPgi3ddIJxejKtM=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=fuvQzo2NI+LFOoJEucDxjyxBx6Wj/h8rl/3hhW1W8xq8mU0jhhaWC624KCAowoj4y kRCzXlUdHIH/zxRy4EoZE8gyyqQxus3D0BNBt03eNP2e4RfiNoBtK67Z5cKWd7IpcA k75bYdbOEqDhFLFRqVnuZLbC0yPNfgW/Ewm8UJ4o=
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, mtgvenue@ietf.org
References: <9139334c-9c5e-814d-4299-c6f5950039b8@cs.tcd.ie> <f9b2a33d-db49-54a0-a657-be58a08ff021@labn.net> <a1a08b89-9088-07e0-d878-2c171c04602b@cs.tcd.ie>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <d5d75e80-1285-f510-709e-9f1e24240ec5@dcrocker.net>
Date: Mon, 30 Jan 2017 07:34:31 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <a1a08b89-9088-07e0-d878-2c171c04602b@cs.tcd.ie>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/o--1TOPmoVe5E4_v-HKivixRHbk>
Subject: Re: [Mtgvenue] comments on draft-ietf-mtgvenue-iaoc-venue-selection-process-04
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2017 15:34:48 -0000

On 1/30/2017 4:45 AM, Stephen Farrell wrote:
> So how about emphasising more that this section is a guideline
> that's expected to evolve, that what's listed here is the
> current practice (assuming it is) and that the IAOC may change
> this but must publish their changes and follow community
> consensus on such changes (as evaluated by the IESG)?


Stephen,

A number of your suggestions show this kind of basis:  Things might 
change and we should say something about that.

In specification-writing terms, this has no utility.

There is nothing that we can /do/ with such text.  It is, therefore, 
cruft.  We need to mitigate against cruft that makes the writer feel 
better (and maybe even the reader) but has no actual utility.

The issue is not that such text is wrong but that it has no effect. 
Everything can change.  Most things will.  Eventually.  Adding generic 
text about this universal truth is entertainment, not specification.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

v2.23.0 | Report a Bug | By Email