Re: [Mtgvenue] Fwd: New Version Notification for draft-daley-gendispatch-venue-requirements-01.txt

[Mallory Knodel <[e-mail]>]

Hi Jay,

Thanks for updating this important document. I've done a review of the text.

First I'd like to share a review that was done in 2018 of this document 
before it was published, which you might want to read just because it 
provides a bit of narrative and explanation for some suggestions that 
were taken and others not, at the time: 
https://gitlab.com/hr-rt/documents/-/blob/master/HR-RT%20Review%20of%20draft-ietf-mtgvenue-iaoc-venue-selection-process?ref_type=heads

Second I want to express support for the previously discussed preference 
for a shift in focus of the document to update RFC8718 since the crucial 
sections like the Venue Selection Objectives and Core Values remain 
important considerations for affordability, accessibility etc. It's 
important that any future text reflect these underlying principles 
within the discussion sections for a document meant to guide decision 
making.

However I want to reflect that RFC8719 already allows for the 
flexibility in meeting location that you are seeking and so perhaps it 
is worth asking "why" first, rather than assuming that a rewrite will 
achieve those results, when the possibility has been available for some 
time.

More suggestions for your text:

  * In 4.1. you might add a discussion item about locations in which 
there is a concentration of IETF participants as the costs are split 
between IASA, participants and local participants, where for local 
participants costs are lowest. The exposition of this dynamic might 
support the policy's choice to move around-- say, if we only met in San 
Francisco this might be the most efficient cost sharing configuration, 
but it would not be equitable.

  * In 4.3. I would strongly encourage us to have at least one overflow 
hotel option that has a lower price point than the main hotel. You could 
also only invoke this section in the "one-roof" cases. I think it 
provides a recognition that not all attendees do use the alternate 
hotel, and possibly with just one "alternate" hotel (not sure overflow 
is the right word anymore) this could precipitate a satellite community 
vibe at the second hotel.

  * In 4.4. the Tao might not exist shortly after the publication of 
this RFC, so potentially characterising this citation differently would 
be prudent, or just removing that reference all together would be fine.

  * Under 5, I am not convinced that we can just handwave about 
filtering. Invariably there will be a lot of grey area and this proposed 
revision makes things less clear than before. I strongly prefer the 
original text. I have great aversion to the invocation of the acronym 
CSAM in this document. The original text already has qualifications for 
handling filtering due to local laws. Again, I do not think that this 
text should be changed at all.

Thanks,

-Mallory



On 10/12/23 1:33 PM, Jay Daley wrote:
> Here is an updated version of the I-D that was presented as gendispatch at IETF 116 Yokohama.  Discussion [e-mail]  please.  This is on the genarea session at IETF 118 Prague.
>
> This version takes a different approach, based on the feedback received, as follows:
>
> 0.  The original approach of this doc was "as the community wrote the original BCPs, here’s our suggestions for a new BCP" but the feedback was to just propose what should go into a new BCP, which this now does like this:
>
>     clarifies how the IETF Administration Support
>     Activity (IASA) should interpret some elements of RFC 8718, and
>     proposes a replacement meeting rotation policy, thereby obsoleting
>     RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF".
>
> 1.  Take out anything that’s already in the LLC remit to control or is not actionable.  So commentary about the IETF network in hotels has gone.  There are still questions around that, but they can be resolved more directly.
>
> 2.  Instead of asking questions, make recommendations that can be discussed.  This has now been done for the Internet filtering part.
>
> 3.  There was lots of feedback about the "one-roof" preference so the recommendation here is adjusted to try to include it all.
>
> 4.  We have not replaced the word "walk" (or variants) as requested - the original BCPs use it and so we’ve retained it to keep the continuity of context.
>
> 5.  Since the first version, we’ve had lots of direct feedback that the rotation policy in RFC 8719 and the process for exploratory meetings are too rigid and too prescriptive. This doc now proposes a new rotation policy.
>
> Jay
>
>
>> Begin forwarded message:
>>
>> From:[e-mail]
>> Subject: New Version Notification for draft-daley-gendispatch-venue-requirements-01.txt
>> Date: 12 October 2023 at 14:53:44 BST
>> To: "Jay Daley"<[e-mail]>, "Sean Turner"<[e-mail]>
>>
>> A new version of Internet-Draft
>> draft-daley-gendispatch-venue-requirements-01.txt has been successfully
>> submitted by Jay Daley and posted to the
>> IETF repository.
>>
>> Name:     draft-daley-gendispatch-venue-requirements
>> Revision: 01
>> Title:    IETF Meeting Venue Requirements Review
>> Date:     2023-10-12
>> Group:    Individual Submission
>> Pages:    12
>> URL:https://www.ietf.org/archive/id/draft-daley-gendispatch-venue-requirements-01.txt
>> Status:https://datatracker.ietf.org/doc/draft-daley-gendispatch-venue-requirements/
>> HTML:https://www.ietf.org/archive/id/draft-daley-gendispatch-venue-requirements-01.html
>> HTMLized:https://datatracker.ietf.org/doc/html/draft-daley-gendispatch-venue-requirements
>> Diff:https://author-tools.ietf.org/iddiff?url2=draft-daley-gendispatch-venue-requirements-01
>>
>> Abstract:
>>
>>    Following a review of the IETF meeting venue requirements, this
>>    document proposes updates to RFC 8718 “IETF Plenary Meeting Venue
>>    Selection Process”, clarifies how the IETF Administration Support
>>    Activity (IASA) should interpret some elements of RFC 8718, and
>>    proposes a replacement meeting rotation policy, thereby obsoleting
>>    RFC 8719 "High-Level Guidance for the Meeting Policy of the IETF".
>>
>>
>>
>> The IETF Secretariat
>>
>>
-- 
Mallory Knodel
CTO :: Center for Democracy and Technology
newsletter ::https://internet.exchangepoint.tech