¶ Topics for possible 2nd retreat
Please list topics or sessions here that you would like to see on the agenda if the IESG were to hold a 2nd retreat Oct 8-11, 2019. Please provide a lot of detail, including how much time you think the topic/session would take, if you would want others from the community or external people involved, etc.
Deadline to add topics: end of your day on August 6.
¶ Structure and organisation of the admin plenary and open mic (Mirja)
I know we have discussed this many time in the past but I think it is time to discuss it again. I may put this on the agenda for the next informal telechat, however, if others agree that some changes may be needed I believe that's a longer discussion which could eventually also benefit from joint time with the IAB.
¶ List of issues ? (Éric)
[Sorry to spam this wiki page for dumb/weird/actual suggestions]
I am sure that I am not the only IESG member (applicable to liaison & IAB members obviously) having noticed that there are open questions/issues with the IETF:
- about the Internet: there is a tendency to globally converge to a 'centralized cloud' (= read some commercial companies) as opposed to a peer-to-peer Internet... The train has left the station as far as I can tell... But, can the IAB/IETF still try to correct this course IF we believe it is the wrong one?
- about the industry: IETF processes are good for quality but appear as too slow, too 'design then implement' (not always though
), ... Meaning that other initiatives Open.* (often lead by major vendors with $$$ hence not so open) appear as more useful. If we put our own individual goals aside, is this centralized/controlled Internet what we want? I hope not 
- about the IETF community: based on plenary and ietf@… (heavy bias on the latter), there is a disconnect between our peers in the 'community' and the IESG... I guess that all of us have been approached/contacted by some community members about some of those issues
It would be impossible to fix everything in one retreat of course but can we start with a draft list of issues?
¶ Leveraging side meetings (Éric)
It is clear that side meetings are a success. Until today, there are really informal (which is good) and disjunct from the IETF process (which is possibly less good). Should we try to bridge the chasm between side meetings and WG meetings? Is there still a point to have non-WG forming BoF with side meetings? Should the IESG or WG chairs also propose / create side meetings?
There is a positive momentum behind side meetings, this momentum must be kept obviously and perhaps leveraged.
¶ Are we overdoing the 'politically correct' ? (Éric)
There are obvious bad behavior (booing a speaker, calling names, ...) but shouldn't we be realistic as well? For exemple, an applause to a question at an open mike seems perfectly correct for me and should not deserve any verbal or written comments. Sorry for being direct here.
The IESG is about steering a community for the community's goals and objectives, not really about 'parenting' the community, after all, we are coming out of this community so we are not better
I understand that this is a very sensitive topic.
¶ Assessment on where we are with conduct in the IETF (Alissa)
I took a bunch of actions from IETF 105 related to conduct: drafting strawman text harmonizing our various conduct-related BCPs, getting a start on documenting sergeant-at-arms escalation procedures, looking into training for WG chairs. These efforts will be at various stages by the time October rolls around, and it's hard to say exactly what stages -- some might be out to the community for comment, others not yet. We could use a bit of F2F time to sync up on all of this if we were meeting.
¶ General area general working group (Alissa)
We briefly discussed this idea in Montréal. I have it on my to-do list to try to draft a charter. As with the item above, it's unclear what the status of that will be by October, but some F2F discussion might be useful at that time.
¶ Assessing the effectiveness of the IETF (Alissa)
Christian Huitema has started a little project to evaluate the effectiveness of the IETF: https://tools.ietf.org/html/draft-huitema-rfc-eval-project-00. The general topic of measuring the participation, productivity, and reach of the IETF has been on my wish list for a long time. With the permanent executive director coming in I anticipate we'll soon have some more attention and resources to throw at these questions in 2020. It would be interesting to have a brainstorming session to talk about what we would want to measure if we could measure it.
¶ Lessons to be learned from Cacao (Éric)
While a single event cannot be generalized, I find disturbing the message sent by the past Cacao BoF proponents, esp "For those supporters here that wish to participate (I know there are a lot of you) you can join the technical committee directly if your organization is already a member of OASIS [2]. If not, you can join for less than it costs to attend three IETF meetings a year. Another option for you is to contribute via the public comment list that will get created ... So I would encourage you to join us at OASIS, as we move this work forward."... Which is of course fine to be sent on an IETF mailing list but is a cruel view on our weaknesses.
What can we do to avoid another work item moving to another organization? Of course, the IETF cannot be the home for all technical/policy efforts for all topics but identifying the core issues of this missed opportunity is important (the ones cited -- costs & delay -- but possible others as well).
¶ Old New style updates, constrained changes, and document consolidation (Magnus)
It is fairly clear that the resulting old/new soup produced by IASA2 as well as other WG, e.g. NFS 4.1 update, results in bad results that has poor readability. And the discussion has convinced me that we should avoid producing documents in that form. At least unless we have something that produces a consolidated version of these changes that are possibly to normativly reference. I still think there exists room for targeted updates, but they really should not be of the style old/new, they need to provide a consolidated update at least on a functionality level inside protocol. In the case of IASA2.0 the result is also that we can't point to contained set of document for a specific part of our process or policies.
So do we have so horrible experience with attempting to constrain a working group or a wg item through charter text is not sufficient? Alissa referenced the IESG behavior on 7437bis which is something we quite easily can do something about. For example we can task WGs to after having done the targeted update and noting significant issues, that the WG can be tasked with addressing these also in a future replacement document. We should also consider where we should try to get WGs to produce consolidated updates.
¶ Reorganizing IoT work (Ignas)
Details TBD
¶ Topic/session (Name)
Details
The content of this page was last updated on 2019-09-06. It was migrated from the old Trac wiki on 2023-02-17.