Skip to main content

Minutes IETF114: gendispatch: Wed 13:30
minutes-114-gendispatch-202207271330-00

Meeting Minutes General Area Dispatch (gendispatch) WG
Date and time 2022-07-27 17:30
Title Minutes IETF114: gendispatch: Wed 13:30
State Active
Other versions markdown
Last updated 2022-07-29

minutes-114-gendispatch-202207271330-00

GENDISPATCH Hybrid Meeting @IETF-114

Wednesday 27 July 2022

Room: Liberty C, Ballroom

13:30-14:30 UTC-4

Log into the IETF datatracker to access:


Status and Agenda Bash - Chairs and AD (5 min)

Presenters: Chairs & AD

Chairs: Pete is stepping down from the gendispatch co-chair position,
due to taking on RSWG. Please contact Lars Eggert or Kirsty Paine if you
are interested in being a gendispatch co-chair.

There is a slight, late change to the second agenda item today - instead
of Martin Duke presenting, Pete Resnick will present the update from the
side meeting earlier this week.

RFC 6722 and Updating the Tao (is the process in RFC6722 to update the Tao working?) (25 min)

Presenter: Lars Eggert

Messages

Slides

Issues include: the revision process for the Tao (datatracker, IESG
approval), that folks cite of older versions (as they are RFCs), and
that RFC 6722 is quite prescriptive.

Stephan Wenger: these options are not mutually exclusive, you could use
a combination.

David Schinazi, document enthusiast: somewhat horrified in 2021
[note-taker: I know, it's 2022] that we see strict specification of
http. That's about to be obsoleted. On discoverability and target
audience, I think of the Tao as the 'decoder ring' of the IETF, you
understand what these words mean and why all these people are so
strange. But I'm confused because I don't know about Taoism, and the
name itself is confusing, we could rename it too so that people can
understand what it is.

Barry Leiba: Now that David spoke, I can agree briefly. This should be
targeted to beginners at the IETF and target it differently.

Jim Reid: Keep publishing it as an RFC, this is how people cite and
reference it. Would be icky to put it as a URL that changes, or Github.
It seems overkill for the whole IESG to review, you could just have the
IETF Chair approve it alone.

Lars: If it is a RFC on the IETF stream, the whole IESG has to approve
it - that's the rule.

Karen O'Donoghue: A note on discoverability - it's on the newcomers
page, it goes out to newcomers and it's on the tutorial, so it is sent
to newcomers.

Robert Wilton: IESG review is also overkill. I didn't read this when I
came to IETF and I managed, let's make it more useful.

Eric Rescorla: Two aspects: what we provide to newcomers, and what to do
with this artefact. This artefact is outdated, people expect layered
information, not a history. I understand people care about the history -
put it somewhere else, not here. Let's decouple the questions. Firstly,
the Tao as a history could be published as an RFC, if that's important
to people. And secondly, newcomer information should be webpages,
tutorials, YouTube, etc. Put it on the website.

Donald Eastlake: In favour of putting material out for those who are
'less successful' in the IETF to get better. Could have the site and RFC
in tandem.

Lars: In practice, if we update the RFC every 3 years, do we allow
pushes to the website more periodically inbetween and then can the IESG
overturn the webpages?

David Schinazi, now web enthusiast: Agree with Eric Rescorla. Brought
three newcomers to this meeting, I didn't tell them to read the Tao
first as it is inscrutable. The correct solution would be a mutable RFC
but we can't do that. Take something that takes the website, turns it
into text once a year, and get the ISE to publish it. Let's not waste
our time and energy on things that ultimately aren't so important -
let's make more time for creating tutorials for newcomers.

Andrew Campling: Agree with Eric Rescorla, let's change the name so it's
more obvious what it's for. The process isn't fit for purpose, but by
the stats - it's been updated 5 times in a decade. Because of the
process or the need? If it only needs 5 updates, that's maybe OK for
this process. But if it needs more updates, perhaps someone can manage
the page. Possibly with emodir for oversight?

Lars: There is a space for folks to make requests on Github and chime
in. I didn't mention that option as a mechanism.

Mirja Kühlewind: There is a need as it needs updating more regularly,
but also no need as no-one seems to use it or care about it. The only
useful information that I didn't have to wear a suit - was helpful but a
long doc for only that! I would suggest getting rid of it, and it will
still be around as it's kept an RFC forever (that's part of our culture
too)

Jim Fenton: Github or something of that sort is well-suited; it keeps
history, can take a modular approach. Perhaps publish one more RFC to
update the latest one that was published that says "look at this place
instead of these places" and then leave it. Focus on making document
useful to participants, rather than how people reference it.

Daniel Gillmor: Echo what everyone says about it being inappropriate to
newcomers. It was interesting but you shouldn't have to read it. Someone
said, "people who don't have the time or patience to read it won't do
well at the IETF" - I don't think that's good, it's hazing, I don't like
hazing. Let's make it accessible so that it's useful.

Jay Daley: The tone ("you, the newcomer" and "you might think this, but
no - we do this") is off. However it is the only place that tells us
what the dots on people's badges mean. A lot of folklore. I agree, let's
take a different approach that is multi-layered. Let's keep the
folklore, the community approach, and have some basic newcomers guides
too. I cringe when I tell newcomers to look at the Tao, I'd love us to
take a different approach.

Martin Duke, enthusiast for IESG having less work: 1. It's not a metric,
how frequently this is updated - especially if it's just a cultural
artefact. 2. Regarding IESG review, it just requires 1 ballot to move
forward. I wouldn't feel compelled to review this if I didn't care about
it. Datatracker ease is helpful, simplify the paperwork without making
more work for the IESG.

Georgios Karagiannis: This is missing some things like leadership of
groups. (Lars: there are other places for that) Two types of
information: for newcomers and things that are more formal.

Lars: This is not formal because it's an informational RFC. Dots are
also defined in newcomer slides.

Wes Hardaker: We refer every newcomer to it, a lot of people say it's a
useful document. So a discrepancy exists. On the Thursday newcomer
feedback session, we will ask how many people read it and if they found
it useful. Please don't get rid of it, we need something to point to -
even if it's shorter, simpler, different - I need something to point to.

Peter Thomassen: Agree with Wes. I'm quite new, just over a year, I did
read the Tao and I did find it quite useful. It could be more concise,
but that doesn't require a change in format. I agree that frequency of
change isn't a good metric for understanding whether the format or
process is right. The frequency of change indicates how often we want to
update it. We should understand how much people read it and if they
care, if they don't care they might not care about other material too.

Stephan Wenger: I have seen newcomers put weight on this.

Sam Weiler: I heard suggestions I don't like - namely, snapshotting
updates as RFCs. I don't want to find two versions that look current -
RFCs and webpages. Please don't go back to the RFC, save the IESG work
and ignore RFC 6722 or issue an update. Don't have multiple conflicting
versions to confuse people.

Dispatch outcome: Hard to say, we need to reflect. No clear indication
of a consensus, but plenty of good options/suggestions. We could boil
down to a few general suggestions, and choose one. We could also ask the
editors of the Tao what they want to use as their process going forward.
That might also capture consensus.

NomCom Eligibility Discussion (draft-duke-gendispatch-rfc8989bis) (25 min)

Presenter: Pete Resnick

draft-duke-gendispatch-rfc8989bis

Messages

Slide appears on the chair slides. Quick summary of what happened
this week: side meeting resulting in this charter.

Ted Hardie: Also use NomCom Eligibility for other things, so do we mean
exactly and only this, or those other linked processes (e.g. recall
committees)? Clarity would be welcome.

Pete Resnick: Barry Leiba gave a thumbs up for this.

Eric Rescorla: Has to cover other eligibilities too.

Robert Sparks (Jabber): +1 to being explicit and to the scope Ted
suggests.

John Klensin (Jabber): Charter draft looks good (or at least close
enough) to me... and agree with Ted (or we need to separate those
contingent eligibilities).

David Schinazi: +1 to everything said, do it, make it happen.

Rich Salz: It should happen and quickly. Datatracker changes etc and Rob
has only so much time to implement those.

Lars: Are we content to do a BoF-less working group?

No objections raised, a few hands raised in favour.

Olaf Kolkman (Jabber): +1 - should do this, with broad interpretation of
the eligibility applicability. BOFless is good.

Jabber has a lot of BOF-less agreement from Robert Sparks, Russ Housley,
Mirja Kühlewind, David Schinazi, John Klensin

Martin Duke: Happy for the record to be the author after my gendispatch
draft. Based on the side meeting, I will strip out the criteria changes
and use the RFC8989 criteria as a baseline.

Suresh Krishnan: Talks about multiple docs for NomCom things - would be
good to keep them all in one place.

Martin Duke: RFC 8713 addresses a range of NomCom issues, where 8989 is
more specific.

Pete: what gets updated where seems like weeds.

Barry Leiba: Will adjust the charter text appropriately and send it to
the mailing list before proceeding.

Rich Salz: Would prefer we didn't open the whole NomCom process
document, and needn't have a big update to change this in line with the
modern world, virtual meeting.

Suresh: Fully understand, but I want it to be easier to find these
things in the same place.

Lars: I think Suresh is suggesting RFC 8713 is updated to be aligned but
only that section on eligibility, nothing else. So that RFC 8713 is
updated and aligned.

Rich: What does ELEGY stand for? (Eligibility.)

Dispatch outcome: Update it, BOF-less working group. Revised charter to
be sent to the mailing list.

AOB & Summary (5 min)

Huge thanks to Pete for his time serving as gendispatch chair during a
tumultuous term!