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

[Eric Rescorla <[e-mail]>]

On Fri, Oct 13, 2023 at 4:24 AM Jay Daley <[e-mail]> wrote:

> Thanks for the feedback, responses below:
>
> > On 13 Oct 2023, at 02:38, Mark Nottingham <[e-mail]> wrote:
> >
> > Hi Jay,
> >
> > Thanks for this. My feedback:
> >
> > ## The Meeting (Rotation) Policy
> >
> > This proposal leaves open the possibility of rotating all or most
> meetings through two regions (e.g., North America and Europe).
>
> That’s incorrect.  The proposed new policy is based on a set of
> restrictions that specifically prevent concentration (there are three core
> regions):
>
>     • No two adjacent meetings in the same region.
>     • No more than one meeting per region in a calendar year.
>     • No more than one meeting in a non-core region in a calendar year.
>     • No more than one meeting per country in any two adjacent calendar
> years.
>

They also seem to seriously overconstrain the problem. This is particularly
true in North America, especially given the concerns people have expressed
about the US and that the IETF has never held a meeting in Mexico, so we
have no experience on how successful it will be.

-Ekr


> > While that may not be the intent, there will be strong pressure from
> some to tilt things this way, which would have significant consequences not
> only for diversity and inclusion, but also the IETF's reputation as a
> worldwide, rather than merely Western, institution.
>
> I am not aware of any such strong pressure.  I am aware of strong concerns
> with the IETF meeting in two countries - the US and China - but I’ve seen
> no evidence of a more regional bias.
>
> It’s important to note that even a minimal application of the new policy
> is better than a minimal application of the current policy because Mexico
> is now included in North America (a core region) and the fourth bullet
> above would now prevent us meeting in the same country twice in two
> adjacent years.
>
> It should also be noted that under the current policy it requires
> community consensus before the LLC can book an exploratory meeting, which
> means that if there is a strong movement to restrict meetings to core
> regions then that will inevitably prevent that consensus.  Under the
> proposed policy this decision now sits with the LLC, making it far more
> likely that exploratory meetings will happen.
>
> >
> > 1-1-1-* serves a very specific purpose -- it helps to keep us honest
> about being a global organisation. Even if we allow temporary divergences
> (for example, allowing a year where we have two European and one North
> American meetings) it has negative impact -- for a participant from
> elsewhere who only participates for a short time (relative to long-term
> participants), doing so reduces the opportunities for them, increases their
> costs, and leaves an impression that we only care about Western inputs.
>
> The new policy is intended  improves upon this, which it does this in two
> ways:
>
> 1.  It reduces the concentration of the 1-1-1 part, as explained above.
> 2.  It removes the high barrier of community consensus for the -* part and
> makes that an LLC decision in line with the choice of venues for the 1-1-1
> part.
>
> > That said, it's regrettable that 1-1-1-* causes administrative issues.
>
> Clearly, this text needs revising, as much of the motivation here is to
> make it much easier to schedule exploratory meetings, which is all about
> "being honest about us being a global organisation".
>
> > Earlier, you say:
> >
> >> The view of the community appears to have shifted since RFC 8719 was
> written, towards a less rigid policy for IETF meeting rotation, with the
> key goal of avoiding excessive geographic concentration, and with greater
> discretion being given to the IASA.
> >
> > What are you basing that judgement upon? It would be more helpful to
> have a discussion about the issues that 1-1-1-* causes, rather than jumping
> to proposals. This wasn't part of -00 AFAICT.
>
> This is indeed new.  It comes from multiple conversations with people so
> yes we can’t claim that the view of the community has shifted, only that it
> appears to have shifted, which is something we hope to test in this I-D.
>
> > ## Hotels and Facility
> >
> > I'm fine with these proposals. Just to clarify -- the 'one-roof'
> preference (not requirement) is remaining, correct?
>
> Yes.
>
> > ## Unfiltered Internet Access
> >
> > This proposal seems reasonable to me.
>
> Thanks.
>
> Jay
>
> >
> > Cheers,
> >
> >
> >
> >> On 13 Oct 2023, at 4:35 am, Jay Daley <[e-mail]> wrote:
> >>
> >> (posting this for info only on gendispatch as the discussion venue has
> now moved to mtgvenue following the agreement at gendispatch)
> >>
> >> Here is an updated version of the I-D that was presented as gendispatch
> at IETF 116 Yokohama.  Discussion on [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
> >>>
> >>>
> >>
> >> --
> >> Jay Daley
> >> IETF Executive Director
> >> [e-mail]
> >>
> >> --
> >> Gendispatch mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/gendispatch
> >
> > --
> > Mark Nottingham   https://www.mnot.net/
> >
>
> --
> Jay Daley
> IETF Executive Director
> [e-mail]
>
> _______________________________________________
> Mtgvenue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mtgvenue
>