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

Alissa Cooper <> Tue, 16 October 2018 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0DE5B130E2B for <>; Tue, 16 Oct 2018 11:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=PxCcH1ib; dkim=pass (2048-bit key) header.b=Mo3PIyG+
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id olM35l3U_WNF for <>; Tue, 16 Oct 2018 11:38:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 56932124C04 for <>; Tue, 16 Oct 2018 11:38:58 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id BE3732206C; Tue, 16 Oct 2018 14:38:56 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute7.internal (MEProxy); Tue, 16 Oct 2018 14:38:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=6 RnNHdrexv3Q5HfcgUs979l3ZR5Ii+y7BdUYJNB5WMY=; b=PxCcH1ibypxXZcYcg qqPgAg8OGv9BRTz4b4PCS1hRFelc8PkkSaiHNIE+ANLROnNrtO0juL2nrpa4nVGy jCpFZM+Vh+o5WyyWIiqeWHnBgXUO6CfEEUev3dTGYfjcmBYivBxg/8/QcifhgHkY TLB+V5sUEBSN5kOAOlRuhFmxlb+eFOkDlxDcqV771tDtVyN5Mt6dd+FJ+MjIzyIa ATH7U3n3IeahK1A9TqHqjwaHm+Q47x96h3srY/LJbWEk2pjQTu3ks9bU/H8+6Tg8 vbdTrUFihBmgqfHqkaA1WGNGKgs2jLhx93qpIxKtBaA+iKf7+K/LBgOjRGyD+NDV 7r/pQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=6RnNHdrexv3Q5HfcgUs979l3ZR5Ii+y7BdUYJNB5W MY=; b=Mo3PIyG+i0why48QGDNxOctaEfI7DggUBG11tNoiuBuccs8cGGuxT9dtR J9mz6aNIUNCYtWfYutBMG7owIK7gxCG32U2d7shRNP5RH1Rgz8QYRKDqqO8xgwSA Xpks5p2cIq5Vo7yJ25nLvY1TTtl3gmyLO3BN1Vj1Gko2lkYJ7oYgCjBVdjmUwbpJ +/wAPmhDq2qrjcllAdNM5yoSTnHtnA7X+vFukB5Qj4jvtmtkHPAtVdsHPFHMN/7b 5yiuOKioiYjBxaveCDpN88fPMprisIcdjW7NDRmmbf3+XMkX0LszwKCxsE1ktPRt mTf2krEGNH00XUshbC4PT8//A1Igw==
X-ME-Sender: <xms:QDDGW4AVh1szMylfw83m8az9zPiF0vfXIc2C5-5kUO_lOkX2Yc9l4A>
X-ME-Proxy: <xmx:QDDGWz0pvt4K5umgHhhcRffKtyjByW5QFED6ik4vVjCh_j7jRo4D8w> <xmx:QDDGW4h-CqQLDnahsBXXV30ONc4toPkAczdFCXbdwl85s3HJhe2HvA> <xmx:QDDGWxbElKXpM9YB7FAafGD3KT9FdvzZ2SaPXmHw6tPN-j-ynrDoKA> <xmx:QDDGWxNPhX-rdwzWVbzugDD0Bkusnj8WjPnzc_Q1kp0xmSUi5Y5o-Q> <xmx:QDDGW1RuIw7onnFcbp1ZaTC5FIUNaegW0qePie9SAWpDYPcandX6yg> <xmx:QDDGW4mLeum0elFqfTHCOKym2_RtxPsXoHWa68kEvLEcwCuDmnSv1g>
Received: from (unknown []) by (Postfix) with ESMTPA id 49BFC102F4; Tue, 16 Oct 2018 14:38:55 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Tue, 16 Oct 2018 20:38:52 +0200
Cc: Lou Berger <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Eliot Lear <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Mtgvenue] About draft-ietf-mtgvenue-iaoc-venue-selection-process
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for email discussion of the IAOC meeting venue selection process." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Oct 2018 18:39:01 -0000

Thanks to Eliot for raising this. I think there are some subtelties here so it’s good that we are talking about this now. This may belong better on the IASA 2.0 list but let’s see.

My understanding is that “IASA” as defined in RFC 4071 refers to an activity. Despite it being an activity and not an explicitly defined group, RFC 4071 attributes responsibilities to it and says that the IASA will do things (like enter into contracts). 

As documented in draft-haberman-iasa20dt-recs-02, some of the goals of IASA 2.0 are to more clearly define roles and responsibilities and to more clearly define the IETF-ISOC relationship.  These were big motivating factors in creating the LLC. So, although we still have the term IASA 2.0 around, my assumption had been that in documents like draft-ietf-mtgvenue-iaoc-venue-selection-process we could be explicit about who has responsibility and who is expected to take responsibility for getting things done. When we discussed on this list the use of the term “IASA” in this document I figured that was what we needed to do at the time because it was the only term that we had. But now we have a clearer term that more accurately describes the actual entity responsible — the LLC. (This doesn’t foreclose the possibility of the LLC using contractors and volunteers to do things, it just indicates who is ultimately responsible.)

Notably, draft-ietf-iasa2-struct (which is now being proposed as the replacement for RFC 4071) does not use the term “IASA” to represent an entity that has responsibility.

So, I don’t think “IASA” is going away as long as people still want to use the term to describe the activity, but I think we can and should be specific about roles and responsibilities, and this document seems like a good first place to do so.

The LLC is already using the criteria and process in this document for meeting venue selection, so I think it’s worth taking the time to sort this out before publication — no rush.

Regarding section 1, the full end of the second paragraph is accurate, I think, but perhaps not clear: "the Nominations Committee (NOMCOM), the Internet Engineering Steering Group (IESG), and  the ISOC Board of Trustees, from which the LLC Board is constructed.” Maybe "the Nominations Committee (NOMCOM), the Internet Engineering Steering Group (IESG), and  the ISOC Board of Trustees, which together select the LLC Board” would be better.


> On Oct 16, 2018, at 5:57 PM, Eliot Lear <> wrote:
> Lou,
> I'll let Alissa answer this further, but I'd ask you to answer my
> question.  The IASA previously was an actual group and not just a
> function.  Now what is left that is not covered by the LLC?
> Eliot
> On 16.10.18 17:21, Lou Berger wrote:
>> Eliot,
>> I think you are conflating IASA with IAOC.  IASA is being updated to
>> replace the IAOC with the LLC.  By leaving the document as is, the
>> document won't have to be update if we change how IASA is implemented
>> in the future.  I think the other RFC updates that need to be done to
>> remove references to IAOC highlight how keeping IASA in this document
>> is really the right answer.
>> Lou
>> PS I think the following change is particularly unneeded:
>>     the ISOC Board of  Trustees, from which the LLC Board is constructed.
>> On 10/16/2018 8:58 AM, Eliot Lear wrote:
>>> On 16.10.18 14:13, Lou Berger wrote:
>>>> Hi Eliot,
>>>> Given the LLC is more specific than, i.e., part of, IASA why is this
>>>> change needed or even a good idea?
>>> I'm not an IASA 2.0 expert, and of course I could be wrong, but from my
>>> vantage point, what you might think of as the IASA is really just the
>>> LLC.  So far as I can tell, All functions from the old IASA are
>>> transferring either into the LLC or beyond the bounds of what was the
>>> IASA. Given that the distinction is lost, there is value in losing the
>>> IASA monogram so as to avoid confusion with the old structure.
>>> Eliot
>>> _______________________________________________
>>> Mtgvenue mailing list
>> _______________________________________________
>> Mtgvenue mailing list