Re: [Mtgvenue] [Iasa20] Terminology issue in mtgvenue

"Livingood, Jason" <Jason_Livingood@comcast.com> Mon, 05 November 2018 16:01 UTC

Return-Path: <Jason_Livingood@comcast.com>
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 65B7F130F19; Mon, 5 Nov 2018 08:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 r55YslBVHph5; Mon, 5 Nov 2018 08:01:27 -0800 (PST)
Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) (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 E9BB6130E1B; Mon, 5 Nov 2018 08:01:26 -0800 (PST)
X-AuditID: 60729ed4-6c5ff7000000b46f-4e-5be06946bc8c
Received: from COPDCEXC40.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 7D.C8.46191.64960EB5; Mon, 5 Nov 2018 09:01:10 -0700 (MST)
Received: from COPDCEXC37.cable.comcast.com (147.191.125.136) by COPDCEXC40.cable.comcast.com (147.191.125.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 5 Nov 2018 11:01:23 -0500
Received: from COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94]) by COPDCEXC37.cable.comcast.com ([fe80::3aea:a7ff:fe36:8a94%15]) with mapi id 15.01.1466.009; Mon, 5 Nov 2018 11:01:23 -0500
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
To: Alissa Cooper <alissa@cooperw.in>
CC: Pete Resnick <resnick@episteme.net>, "iasa20@ietf.org" <iasa20@ietf.org>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>
Thread-Topic: [Iasa20] Terminology issue in mtgvenue
Thread-Index: AQHUdSDMT8W5oMAIGkCpu62FHWMpAA==
Date: Mon, 5 Nov 2018 16:01:23 +0000
Message-ID: <57CCDBD1-B66A-4C96-A51A-E15F1EF7EC60@cable.comcast.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.3.181015
x-originating-ip: [96.115.73.254]
Content-Type: text/plain; charset="utf-8"
Content-ID: <161A2716F554E649A1B9DE451CE30547@comcast.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsWSUDRnsq5b5oNog9cnxS2mn/nLaLFk+kYm i6WH/7BY7P6wntWBxePLk5dMHk9uLWH2WLLkJ1MAc1QDo01JRlFqYolLalpqXnGqHZcCBrBJ Sk3LL0p1TSzKqQxKzUlNxK4MpDIlNSezLLVIH6sx+ljNSehiyri3+RJjwTbjio+HPrI1MPYY dTFyckgImEicerCbsYuRi0NIYBeTROP5D2wQTjOTxLo1U5lAqoQETjFKfJkkAGKzCZhJ3F14 hRnEFhFQlbh67AcbiM0sUC5xbfIysLiwgLHEujaQqRxANSYSX5+bQZTrSRy/0MMCYrMIqEg8 erkTrJVXwEViy6tZYHFGATGJ76fWMEGMFJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKYosK6Evs nnCcESKuKPFr3hU2kLXMApoS63fpQ4yxkvi56AvUlYoSU7ofskOsFZQ4OfMJC0SruMThIztY JzCKz0KyeRbCpFlIJs1CMmkWkkkLGFlXMfJZmukZGproGZpa6BkZGm1iBKeaeVd2MF6e7nGI UYCDUYmH93zMg2gh1sSy4srcQ4wSHMxKIrxKbEAh3pTEyqrUovz4otKc1OJDjNIcLErivJuO 3IwWEkhPLEnNTk0tSC2CyTJxcEo1MG7cs1JouvkJnbf3tnpHC6+4khxymWWJ1jTLp1J5c8s0 p6TUH7Vc9zyV4WtrjVPXrzXS+ypPXDh4f/KqCU0SfDcO35uzdK/v9Nb1+tyegeLlP6X5c8+n Z299J77l5VWd4i2/7NZvbdvbF+GfLGKx8VzA2qcMeWtCu/nWPH3+YsuSuu/THiw6w5ihxFKc kWioxVxUnAgAX98KxDEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/t_L35JfME9Mr_YIA3VFPDg5Y0-Y>
Subject: Re: [Mtgvenue] [Iasa20] Terminology issue in mtgvenue
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: Mon, 05 Nov 2018 16:01:32 -0000

Sorry for the delay! I just took a detailed look at the -16 version of the document at https://tools.ietf.org/pdf/draft-ietf-mtgvenue-iaoc-venue-selection-process-16.pdf and the diff in question at https://www.rfc-editor.org/authors/rfc8491-auth48diff.html.  

My opinion is that the draft revision made on 9/12/2017 to change instances of the IAOC to IASA are probably sufficient, though we have tended to update other docs to refer to the IETF Administration LLC when it was IAOC previously. Yes, you could make it IETF LLC as the diff proposes, but just generalizing to IASA also appears to work. So either approach will work IMO -- IASA or IETF LLC.

As a side note, one thing the diff does is drops the reference to RFC 4071's general appeals process. The diff proposes dropping that and the associated normative reference to RFC 4071. This might be one thing worth doing in the draft because there does not seem like there's much need to specifically call out the appeals process per se, and that appeals process is specified in IASA-related or other IETF process-related documents.

But... this is just my opinion as a co-chair. Will ask others in the IASA2 WG for feedback now (new thread).

JL


On 10/26/18, 8:22 AM, "Alissa Cooper" <alissa@cooperw.in> wrote:

    Is there any update on this? 
    
    Thanks,
    Alissa
    
    > On Oct 19, 2018, at 11:51 PM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
    > 
    > Thanks for this heads-up, Pete! We in the IASA2 WG will put this in our work queue. I will take a look as co-chair early next week and try to actively start up list discussion on the details.
    > 
    > Jason
    > 
    > On 10/19/18, 5:38 PM, "iasa20 on behalf of Pete Resnick" <iasa20-bounces@ietf.org on behalf of resnick@episteme.net> wrote:
    > 
    >    IASA 2.0 folks:
    > 
    >    With my mtgvenue chair hat on: An issue has come up over in mtgvenue 
    >    that I think really needs to be resolved by iasa20, and in particular 
    >    not by the mtgvenue folks alone.
    > 
    >    The Venue Selection document, 
    >    <https://datatracker.ietf.org/doc/draft-ietf-mtgvenue-iaoc-venue-selection-process/>, 
    >    refers to "IASA" throughout. When written, the document presumed that we 
    >    were working under IASA 1.0, and had references to RFC 4071. When our 
    >    documents got to AUTH48, we realized that it was going to come out right 
    >    on the heels of the IASA 2.0 docs and that it would be silly to publish 
    >    only to have to turn around and fix things. The initial suggestion in 
    >    mtgvenue was to pretty much do a global replace of "IASA" with "IETF 
    >    LLC" (with some other editorial changes). The document editor's version 
    >    with those edits is here: 
    >    <https://www.rfc-editor.org/authors/rfc8491-auth48diff.html>. However, a 
    >    few folks (and in particular, folks who are active in iasa20) noted that 
    >    in fact "IASA" was correct, because under IASA 2.0, the LLC is under 
    >    IASA, and that using "LLC" might be incorrect in some instances. 
    >    Conversely, some folks thought that "LLC" was a clearer reference. As 
    >    that discussion has evolved, your faithful mtgvenue chair is no longer 
    >    sure that we've gotten this exactly right. On top of that, Alissa has 
    >    indicated that it's probably better to have iasa20 figure out what 
    >    terminology is appropriate to refer to the assorted entities, for the 
    >    sake of all documents, not just mtgvenue's.
    > 
    >    So, I would ask that the iasa20 WG review the above two documents and 
    >    let us know whether we've got it right or wrong, and generally let us 
    >    know which terminology should be used in which circumstances. I'm sure 
    >    mtgvenue folks will pipe up with their concerns, but guidance should 
    >    really be coming from a discussion in iasa20.
    > 
    >    BTW: Don't worry about the fact that the document is in AUTH48 or 
    >    whether it will need a new Last Call or whatever. Let's get the document 
    >    correct first, and then we'll figure out what process knobs, lights, and 
    >    buttons need to be operated.
    > 
    >    Cheers,
    > 
    >    pr
    >    -- 
    >    Pete Resnick http://www.episteme.net/
    >    All connections to the world are tenuous at best
    > 
    >    _______________________________________________
    >    iasa20 mailing list
    >    iasa20@ietf.org
    >    https://www.ietf.org/mailman/listinfo/iasa20
    > 
    > 
    > _______________________________________________
    > iasa20 mailing list
    > iasa20@ietf.org
    > https://www.ietf.org/mailman/listinfo/iasa20