Re: [Mtgvenue] About draft-ietf-mtgvenue-iaoc-venue-selection-process

Lou Berger <lberger@labn.net> Wed, 17 October 2018 12:45 UTC

Return-Path: <lberger@labn.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 8CE4012D7EA for <mtgvenue@ietfa.amsl.com>; Wed, 17 Oct 2018 05:45:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.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 c61AxugkpSUt for <mtgvenue@ietfa.amsl.com>; Wed, 17 Oct 2018 05:45:49 -0700 (PDT)
Received: from outbound-ss-579.bluehost.com (outbound-ss-579.bluehost.com [74.220.218.175]) (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 D105F12008A for <mtgvenue@ietf.org>; Wed, 17 Oct 2018 05:45:49 -0700 (PDT)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 5CE291E0D19 for <mtgvenue@ietf.org>; Wed, 17 Oct 2018 06:45:47 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id ClCtgQyHWd20TClCtgONNR; Wed, 17 Oct 2018 06:45:47 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=fZQIoP5oJV5lRfK7A7+BMZqdIbr4r6tcg66gcFjKgK4=; b=cBXc/VI2ULakPCyJ6sBhv2tUAS +PS7HMbm0H9LKQJpEOecQXos8tvvL2zOs6DVOVK5fC9CXSQB1Xi55m3Zc2aGv1PFZ0aWpjV7/t4Nr K5EQzJQHUO4mgl3e6vNCYlAm4;
Received: from [172.58.185.210] (port=30689 helo=[IPV6:2607:fb90:6434:8392:0:12:2f55:d701]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1gClCs-0024zE-No; Wed, 17 Oct 2018 06:45:47 -0600
From: Lou Berger <lberger@labn.net>
To: Eliot Lear <lear@cisco.com>, mtgvenue@ietf.org
CC: Alissa Cooper <alissa@cooperw.in>
Date: Wed, 17 Oct 2018 08:45:43 -0400
Message-ID: <166820f74d8.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <1ffec901-2a99-8af5-b42f-978a79b17266@cisco.com>
References: <328e9dfe-8e30-6388-68be-95b55af0a5b0@cisco.com> <1667ccb8a70.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <471f7ba9-0b9e-256c-513d-78559ff200a1@cisco.com> <58f9ebdd-355e-129f-a987-dab72bc5da6f@labn.net> <9472f4e7-86bc-121c-ae43-13fcdde451d4@cisco.com> <38ad1b3b-309c-4bdb-fe14-0bbd584bb808@labn.net> <adc56f21-0f57-0be0-799e-126072c62fe0@cisco.com> <1667f3a9670.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <6b18f4f3-1e5a-24ac-36e1-54c509139d25@cisco.com> <1668199fe88.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <1ffec901-2a99-8af5-b42f-978a79b17266@cisco.com>
User-Agent: AquaMail/1.16.0-1193 (build: 101600006)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------166820f78981d6e27ceb3014bd"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.185.210
X-Source-L: No
X-Exim-ID: 1gClCs-0024zE-No
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPV6:2607:fb90:6434:8392:0:12:2f55:d701]) [172.58.185.210]:30689
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/dbaRHQXkczn26HLQFFbsgvfZ2Y4>
Subject: Re: [Mtgvenue] About draft-ietf-mtgvenue-iaoc-venue-selection-process
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 17 Oct 2018 12:45:53 -0000

Eliot,



----------
On October 17, 2018 7:25:08 AM Eliot Lear <lear@cisco.com> wrote:

> On 17.10.18 12:37, Lou Berger wrote:
>>> I asked twice, and I've yet to get an answer as to what part of IASA
>>> remains that is NOT the LLC.  Can I get a straight answer to that? 
>>
>> I don't think this is a fair statement.  I do accept that I have
>> failed at describing the difference between iasa, something that was
>> defined many years ago, and the LLC which is still nacent, to your
>> satisfaction.
>
> Lou, I'm a pretty easy guy to satisfy on this one.  Just tell me what
> remains in IASA that is relevant to this work, and I'll back the change
> out.  I've looked and I don't see anything.  If there is nothing, let's
> not make this more confusing to the reader than it needs to be, nor
> unnecessarily delay (see below).

So there's a difference between what is an umbrella and what is under the 
umbrella even if what is covered is completely constrained.

So what happens when the LLC decides that it's going to delegate all 
meeting venue responsibility? Do we do a bis on this document so people 
aren't confused?

At this point I don't think I can answer your question anymore to your 
satisfaction than I already have. We clearly disagree on the value of the 
proposed change. I'm happy to leave it at that.


>>
>>> Otherwise, this really *is* not much more than a simple sed.  The
>>> fundamental: adding unnecessary levels of indirection is confusing to
>>> the reader.
>>
>> Iasa was sufficiently clear for all the LC reviews.
>
> But the reason we're having this discussion is because the circumstances
> have changed, much faster than many of us (most notably your humble
> editor) had expected they would.
>> I therefore see this proposed change as a difference without
>> distinction, but if the working group consensus is to make the change
>> it will do no harm other than causing a delay in publication.
>
> I care less about the publication date than I do about not having to do
> this again for a while.  But if you are worried about the publication
> date, if people insist on the IASA term staying in, we're going to need
> to block for quite a while until there is a replacement for 4071 because
> it is no longer applicable. 

you could just remove the details and say "according to BCP 101" which will 
automatically be updated once 4071 is updated.

> I'm not fussed, tired, or proud.  This
> document blocking won't kill anyone or stop sales of anyone's product. 
> But I do think we should ask if there is a point to blocking.
>

I'm not following you here. on one hand you're saying let's get the details 
right and there's no rush, on the other hand you're saying let's not wait 
until the details are solidified.

I'm also fine with not rushing this - but cramming this into Auth48 
certainly seems like that is the intent, and what triggered me to send mail 
in the first place. (Together with being one of the original authors of 
this document.)

>>
>> If this change is made, I do I think we have to get the language right
>> and also agree with Bob that a normative reference to the document
>> defining the LLC is needed in this document
>
> The reason we needed a normative reference to 4071 was for the appeals
> process (we directly referred to it).

so change the text to say the appeals process defined in BCP 101 and we're 
done.

> That process is no longer
> applicable.  If people want an informative reference, I'm neutral.  I
> can point to the legal doc or the LLC web site.  Probably that's a good
> idea.

Well that would certainly be an interesting precedent.

I think I've reached my process limit on this discussion, and will step 
back and see where things fall on this without my further input on the topic.

Lou

>
> Eliot
>
>
>
> ----------
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
>