Re: [Gendispatch] some thoughts about ietf communication

[Eric Rescorla <[e-mail]>]

On Thu, Jul 29, 2021 at 9:02 AM Bob Hinden <[e-mail]> wrote:

> Joel,
>
> > On Jul 29, 2021, at 8:14 AM, Joel M. Halpern <[e-mail]>
> wrote:
> >
> > I may be misreading this, but it seems that it misses one important
> purpose for the plenary.
> >
> > Sometimes, the community has concerns that need to be expressed, whether
> the leadership thinks the issue is important or not.  That is why, even
> though it is usually vacuous, I consider the open mic portion of the
> plenary to be important.
>
> I agree.  One very important purpose of the plenary is for the community
> to speak to our leadership and for them to listen.
>

I 100% agree. While it might be worth thinking about how to make that part
more productive, it seems to me to be the one non-optional part.

-Ekr

Bob
>
>
> >
> > Also, sometimes it is important to air and compare perspectives on an
> issue (particularly in the4 above category) even if we do not know what a
> reasonable result could be, and can not arrive at a reasonable outcome
> during that time.
> >
> > I do not see how that would fit with what you have below.
> >
> > Yours,
> > Joel
> >
> > On 7/29/2021 5:45 AM, Eliot Lear wrote:
> >> Hi,
> >> As one of the people who think that the plenary function of the IETF
> needs a more serious rethink, I thought I would put this out to the
> gendispatch list and see what people think.  At the end of the day, I am
> aiming for an experiment, and might write this or something else up in a
> draft with others, if others are interested in this or some alternative to
> this (cough, Pete).  If nobody else is interested, or lots of people think
> that trying something new for plenary communication is A Bad Idea, this
> discussion will be the last you hear from me on it.  But what is written
> below is meant as a starting point, not an endpoint.
> >> FWIW, and with apologies to Joel and others, I've a copy of the below
> in Github at https://github.com/elear/ietf-plen/tree/main. Mostly so that
> all the below can be modified, substituted, etc, and later turned into a
> draft if there is interest.
> >> The Principles
> >>  * Plenary communication is expensive and burdensome, and should be
> >>    reserved for important issues that are cross-cutting.
> >>  * Plenary communication is necessary when there is an important
> >>    question for the community to consider.
> >>  * Discussion of such issues must be well organized and facilitated;
> >>    and the plenary discussion should be of finite duration.
> >>  * There should be some outcome.  The outcome may be a mailing list, a
> >>    BOF, dispatch to a dispatch group, an IAB program, or feedback from
> >>    a body such as the IESG or IAB.  The outcome shouldn't be an
> >>    immediate policy change, but if there is interest, some means to
> >>    focus the discussion that might later use our existing processes to
> >>    effect that change.
> >>  * Plenary discussions may not happen on a regular basis, because there
> >>    may not be anything important to discuss.
> >>  * The community should decide what's important.  This is a bit of a
> >>    chicken and egg issue, though.  Sometimes, an issue must get tossed
> >>    around before its importance is understood by others.  What's
> >>    important is that just because Eliot thinks an issue is important
> >>    and cross cutting doesn't mean that it is to others.
> >> How does this differ from *dispatch?
> >> There are two major differences:
> >> 1. The matter must be of cross-cutting importance.
> >> 2. The input to the process may not be a draft to be dispatched, but
> >>    simply an important question.
> >> Possible Examples
> >>  * How should the IESG/LLC organize its COVID response? (past)
> >>  * Is there anything the IETF should be doing to address particular
> >>    threats or changes to the Internet model? (potential future)
> >>  * What should be done about the RFC Editor process? (past)
> >>  * What sort of working group working methods should be acceptable?
> >>    (potential future?)
> >>  * Should our work take into account HR considerations (past and
> future?)
> >> The astute will note that this isn't much different from what you might
> expect at an in person plenary.
> >> Modalities
> >>  * EMail may not be the best way to hold plenary discussions.  I think
> >>    we've all seen bad interactions in email,  and we seem to do better
> >>    in person, and I think we largely enjoy each other's company, quite
> >>    frankly, even if that involves meetecho.  perhaps a "discussion"
> >>    might really be a set of meetings, the way Heather did consultations
> >>    toward the end of her tenor.
> >>  * We need a way for the community to upvote issues to the point that a
> >>    plenary discussion can occur.  Perhaps Github could provide us this
> >>    opportunity.
> >>  * IMHO a facilitator should drive the discussion (not lead it), and
> >>    help interested parties develop their views *prior* to a plenary
> >>    discussion.
> >>  * A good way to identify those interested parties would be *short*
> >>    position papers.  Again, not email.
> >> Comments?
> >> Eliot
> >
> > --
> > Gendispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/gendispatch
>
> --
> Gendispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gendispatch
>