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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 30 January 2017 15:57 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 0BDE5129527 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 07:57:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level:
X-Spam-Status: No, score=-7.5 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_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 x22gBJy2XKkC for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 07:57:51 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8BE129518 for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 07:57:50 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8BAC8BE2E; Mon, 30 Jan 2017 15:57:48 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnHP2QgXEDQd; Mon, 30 Jan 2017 15:57:48 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 03A32BDCC; Mon, 30 Jan 2017 15:57:48 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485791868; bh=4usDEhoX8I7URqm8gVPw4vK1KI+BTbPws/2fTM5zhcg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Q4+oqAwnempxoJt3A+Z7PBqdZFXQjOfPU+y9cbFSck2ARciv8ecegVPzXJyqlWxYR TT8aFzU8Sqpz/cAbWsMTRpUTWSy9LI8BGWZTroAN3iDcT7MswL+pH+ktzoxpT6dvuv OKkuoQ4FN0yvdl9eEQmK6iYwnGsbIWN+wariXwts=
To: dcrocker@bbiw.net, 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> <d5d75e80-1285-f510-709e-9f1e24240ec5@dcrocker.net>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <518a705f-096d-cc4d-6402-5ae605c71f36@cs.tcd.ie>
Date: Mon, 30 Jan 2017 15:57:47 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <d5d75e80-1285-f510-709e-9f1e24240ec5@dcrocker.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms070603070609080509050604"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/BWV3_cPcFzsSGTnD3UdeqnYU7o0>
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
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:57:53 -0000

Hiya,

On 30/01/17 15:34, Dave Crocker wrote:
> 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.

Hmm, that's not very well phrased, from this reader's
perspective. (It reads as fairly condescending to me.)

In any case, I disagree about section 5 - my suggestion has
the substantive statement that the IAOC would publish the
ways in which they're diverging from the text there and that
the community get to say what they/we think of that. You
may consider that solely a form of entertainment, I do not.

Absent such a statement I think we would still need some
way to ensure that section 5's text doesn't turn into another
of those things that we say but no longer do after some time
has elapsed.

Cheers,
S.


> 
> d/