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

[Benson Muite <[e-mail]>]

On 12/01/2024 14.59, Mallory Knodel wrote:
> 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.
It would be helpful to indicate specific characteristics of successful
meetings.
> 
> 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.
RFC8719 does need an update as it does not align with IETF core values
as expressed in RFC3935 - an internet for everybody. Unaware of this
update on venue requirements, had started an update of RFC8719 at:
https://codeberg.org/bkmgit/meeting-locations/src/branch/main/draft-mtgvenue-meeting-policy-00.xml
but would be happy to see the changes incorporated here if that is
preferred. The current draft is still incompatible with RFC3935.
> 
> 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.
This is helpful. Non-financial barriers to travel such as visas are also
important, as is travel time.
> 
>  * 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.
The main concern with RFC 8719 is that the policy is discriminatory and
not objective in defining exploratory meetings, for example a meeting on
in Greenland could be considered non-exploratory and within North
America and Europe all at once but the number of IETF participants from
Greenland is small and travel maybe problematic. A criteria such as X
number of active participants in the last Y years or Z number of RFCs in
the last Y years within a radius of 200Km of the meeting site is more
objective. Ideally, though, suggestions for what makes a meeting
successful would be better. If ease of travel is an important
consideration, Dubai while having few IETF participants has relatively
easy travel for at least Europe and Asia.  The proposed rotation policy
does not address such concerns.
>>
>> 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
>>>
>>>