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

[Jay Daley <[e-mail]>]

Thanks Mallory

Responses below:

> On 12 Jan 2024, at 11:59, Mallory Knodel <[e-mail]> wrote:
> 
> 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.

I agree.  This was too broad a proposed change when the specific issue we have with RFC 8719 is the very high bar in the process for agreeing an exploratory meeting.  We have text for a replacement for that section that is in the process of being finalised for the next version of the I-D.

> 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.

There is already a core value in RFC 8718 of 'Economics' that explicitly weights that balance towards participants as a whole:

"Meeting attendees participate as individuals. While many are underwritten by employers or sponsors, many are self-funded. In order to reduce participation costs and travel effort, we therefore seek locations that provide convenient budget alternatives for food and lodging, and that minimize travel segments from major airports to the Venue. Within reason, one's budget should not be a barrier to accommodation."

I think that is sufficient to cover your point without getting into considerable extra detail of what equity means in this process.
 
> 
>  * 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.

A number of people have asked for this, but unfortunately our experience of this is that this is both very hard to obtain (often because we get such a large discount at the main hotel due to our block size) and only very lightly used when it is negotiated.  That does not mean that we will not do this, for example we are actively aiming to do so for IETF 120 Vancouver, but we do not want to be required to do so.

>  * 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.

Will do.

> 
>  * 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.

I think we have general agreement that the LLC has more discretion here than we have so far understood from our reading of the text and that therefore a change is not needed.

thanks again
Jay

-- 
Jay Daley
IETF Executive Director
[e-mail]