Narrative Minutes interim-2021-iesg-08 2021-04-08 14:00
narrative-minutes-interim-2021-iesg-08-202104081400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-04-08 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
Michelle Cotton (ICANN) / IANA Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (F5 Networks Inc) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Martin Vigoureux (Nokia) / Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Gorry Fairhurst
Mike Jones
Keith Moore
Ketan Talaulikar
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda? Any other changes?

Lars: I wanted to ask if there any need to further discuss the April 1 drafts
we pulled and/or commented on today, either in public session or executive
session? I don't think so but I want to hear if anyone else does.

Ben: I got some unicast feedback that it might be worth relaying to the rest of
us.

Lars: Do you want to do that in an executive session at the end?

Ben: Sure.

Lars: Can you add that, Amy? Thank you.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the March 25 telechat
being approved? I'm hearing no objection. I also saw final narrative minutes;
any objection to posting those? Hearing no objection there either and they will
both be posted.

1.4 List of remaining action items from last telechat

     o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at
       updating the I-D Checklist.

Murray: Robert Sparks has stepped in and said he wants to take a run at
re-doing this from the ground up. There's enough stuff that's stale about the
RFC Editor function, formats of things, and xml to rfc version 3, that stuff.
He'd like to take a run at re-doing the whole thing and doesn't think it's
salvageable from where it is, so that's the status. If he's really going to
take a run at this, what do we we do with such an item? Should I hold the IESG
pen while someone else is working on it, or is it no longer an IESG work item?

Lars: Did you say Robert?

Murray: That's right.

Lars: I don't want to stop him, but I think he's pretty busy with tools stuff,
so maybe we want to check if he really feels he has time for this or if he's
just offering because he wants to be nice to us. Because there's this migration
from tools.ietf.org that I think he's pretty underwater with at the moment.

Murray: I'll check with him.

Amy: We'll keep this in progress for you for now.

     o Alvaro Retana and Martin Vigoureux to draft text on guidance
       regarding the number of document authors on documents.

Amy: I know we talked about this last week and there's a new action item for
Alvaro at the end of the list. Is this one now done?

Alvaro: Yes, I think this one is done. Martin and I picked up that action down
there and a couple of others.

Amy: Okay, so we'll mark this one as done.

     o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to
       investigate ways to recruit, recognize, and retain volunteers in the
       IETF.

Warren: We have not managed to meet again but we're getting schedules sorted
out.

     o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035].

Ben: Still in progress.

     o Eric Vyncke to draft text for the WG Chairs about requesting early
       review of documents by existing Directorates.

Eric V: It's actually started now and we'll finish discussion during the
retreat. There's an item there about directorates.

     o Alvaro Retana, Rob Wilton, and Martin Vigoureux to draft text on the
       framework for a long-term future plan for the IETF.

Alvaro: This is in progress. One of the things is that SWOT/PEST survey we
wanted to do. Only four of you have filled anything out, so if you could take a
look that would be great. Our intent is to collect everything and summarize
something for next week's informal. I sent the link out again yesterday and
I'll paste it in the chat as well.

Lars: Is this something we should talk about at the retreat, possibly together
with the IAB?

Alvaro: Yes I think so. I also sent the link to the IAB for their feedback. I
think the objective is that next week when we talk about a summary, we can then
pick out some topics from here that would go to the retreat.

Lars: This is also related to updating the mission statement, right? Or is that
something else?

Alvaro: Yes.

Lars: Okay, then we probably want to talk to Greg or some other comms people.
Whatever we do here we'll probably want to have text in there that is useful
for them.

Alvaro: This is just the initial steps. Yes.

     o Murray Kucherawy to find additional designated experts for RFC 8855.

Murray: I found the first one and I'm really having a hard time finding these
additional ones, which makes me think if a WG wants to set up a registry they
should probably suggest who should be [experts], rather than having to chase
these. But anyway, it's in progress.

     o Lars Eggert to draft an email to the community announcing that use
       of the last-call email list is no longer an experiment, and will be
       the way IETF Last Calls are run going forward.

Lars: The email got sent. There are two follow on items; Barry was holding the
action item for this in the past. The email that was sent six months after this
experiment was started promised two things on the conclusion of the experiment:
one is an update to the IESG statement, I think it's the Discuss Criteria
thing, that talks about the IETF list that now needs to be the Last Call list;
the second one is the charter for the IETF mailing list, I think it's BCP 45,
needs to be updated because it also talks about Last Call stuff going there. I
submitted an individual draft for that and it's being discussed on gendispatch.
There's also some other discussion there about what to do with the IETF list.
Depending on what the trajectory is for those two things, and what that broader
revamp is, I would push for a quick update to the charter that just says Last
Calls go to the Last Call list. But for this action item, we can rephrase it to
track the update of the IESG Statement and the update to BCP 45.

Amy: Okay, we'll mark this done and put in some new action items for those two.

     o Francesca Palombini to find additional designated experts for RFC
       8949 [IANA #1193081].

Amy: This is going to come up as a management item at the end of the telechat.

     o Alvaro Retana to draft text to update the IESG Statement
       on Internet Draft Authorship to include "Contributors."

Amy: This one is in progress.

     o Warren Kumari to find designated experts for RFC 9018 [IANA
       #1194832].

Amy: This is a brand new item for you, Warren.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-tls-exported-authenticator-14  - IETF stream
   Exported Authenticators in TLS (Proposed Standard)
   Token: Roman Danyliw

Amy: There are no Discusses for this document, so unless there's an objection
now it looks like this one is approved.

Roman: Just waiting to hear if there are any objections.

Ben: I'm not objecting, I did want to ask the group if you want the document to
come back to us if we try to make changes to the registry structure, which is
one of the proposed resolutions I suggested. I think it's pretty
straightforward so I don't think we would need to, just calling that out.

John: As far as I'm concerned, that doesn't seem like it needs to be run past
me, anyway.

Roman: Anyone else have thoughts? Okay, so maybe not then. There is a ton of
feedback that the authors need to action here, though. Thank you for the
detailed reviews.

Amy: So it sounds like this is Approved, Revised ID Needed?

Roman: Definitely. Thank you.

 o draft-ietf-oauth-access-token-jwt-12  - IETF stream
   JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens (Proposed
   Standard)
   Token: Roman Danyliw

Amy: There are no Discusses for this document, so unless there's an objection
now it looks like this one is approved. I'm hearing no objection. There are no
notes in the tracker; are any needed?

Roman: Again, this is a case where I very much appreciate the detailed review
from everyone. Revised ID Needed here, please, and we'll handle it.

 o draft-ietf-lsr-ospf-prefix-originator-11  - IETF stream
   OSPF Prefix Originator Extensions (Proposed Standard)
   Token: Alvaro Retana

Amy: There are no Discusses for this document, so unless there's an objection
now it looks like this one is approved.

Alvaro: We're going to need a Revised ID to catch the last couple of things.
Thank you.

Amy: Okay, this will be Approved, Announcement to be Sent, Revised ID Needed.

 o draft-ietf-acme-star-delegation-07  - IETF stream
   An ACME Profile for Generating Delegated Certificates (Proposed
   Standard)
   Token: Roman Danyliw

Amy: I have a couple of Discusses. Do we need to discuss any of those today?

Roman: From what I look at, these are solid Discusses the authors just need to
work. Unless the Discuss holders want to provide commentary, I think we just
need to iterate.

Francesca: Sounds good to me.

Michelle: We are waiting for the authors to get back to the expert comments
from the expert review, so that is still an open item.

Roman: Okay.

Francesca: I have added this to my Discuss so it can be tracked there as well.

Roman: I appreciate that. Thank you.

Amy: Okay, so it looks like this will stay in IESG Evaluation, Revised ID
Needed.

 o draft-ietf-grow-bmp-local-rib-10  - IETF stream
   Support for Local RIB in BGP Monitoring Protocol (BMP) (Proposed
   Standard)
   Token: Warren Kumari

Amy: I have a Discuss in the tracker for this document; do we need to discuss
that today?

Warren: I don't believe so. I think the authors can address the concerns and
I'm assuming Alvaro is happy to chat with them. Thank you everybody who
balloted.

Amy: Is this going to require a Revised ID?

Warren: Yes. Can I ask a process question? Have we ever had a thing where a
Discuss didn't need a Revised ID? Should we make that default instead of having
to ask the question each time?

[several voices] Yes.

Murray: I don't have an opinion on whether it should be the default, but yes
we've had cases where the AD was set straight and no change was made.

Warren: Okay, never mind. Fair enough.

 o draft-ietf-lamps-crmf-update-algs-06  - IETF stream
   Algorithm Requirements Update to the Internet X.509 Public Key
   Infrastructure Certificate Request Message Format (CRMF) (Proposed
   Standard)
   Token: Roman Danyliw

Amy: There are no Discusses for this document, so unless there's an objection
now it looks like this one is approved. Hearing no objection. There are no
notes; are any needed?

Roman: We're going to need a revised ID. I think some of the comments have been
addressed but I'm not sure so I just want to double check that. In addition to
thanking everybody for the reviews I just want to respond directly to John
about why this isn't a bis. Honestly, it's a convention thing, but good
question. In my inheritance of the WG many of the work products were just
created like that and I haven't pushed back on that style since it looks like
it's been rolling with that process.

John: Okay. My rule of thumb for bis vs updates is that something feels more
like an update if as part of the overall draft we just have to  update one
thing, but if the document basically looks like a patch file against the
previous RFC it feels to me more like a bis. Either way can work, it's just
harder for the consumer of the documents.

Roman: I don't disagree.

Amy: So it sounds like this is going to Approved, Announcement to be Sent,
Revised ID. There's also a downref; do we need to add RFC 8018 to the downref
registry?

Ben: Yes. It's an updated version of a document that an older version of was
already in the downref registry.

Amy: Terrific. Thanks.

 o draft-ietf-cbor-tags-oid-06  - IETF stream
   Concise Binary Object Representation (CBOR) Tags for Object
   Identifiers (Proposed Standard)
   Token: Francesca Palombini

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Francesca: I don't think we need to discuss it today. I think the authors
wanted to go to the WG for feedback before answering you, Rob. Thank you
everybody for the comments. This will definitely need a revised ID.

Amy: Okay, that will stay in IESG Evaluation, Revised ID Needed.

2.1.2 Returning items

 o draft-ietf-oauth-jwsreq-32  - IETF stream
   The OAuth 2.0 Authorization Framework: JWT Secured Authorization
   Request (JAR) (Proposed Standard)
   Token: Roman Danyliw

Amy: There are no Discusses for this document, so unless there's an objection
now it looks like this one is approved. I'm hearing no objection.

Lars: I think they're going to do an update, or at least somebody responded to
me and said they applied changes I'd suggested.

Roman: We're going to need a Revised ID for this. I think some of [the changes
are done] and there are some more to do. Thank you for everyone's patience and
to some of you for looking at this more than once.

Amy: Great, this will be Approved, Announcement to be Sent, Revised ID Needed.
You may want to look at the ballot writeup, since it seems rather long. Maybe
it's necessary, you just might want to take a look.

Roman: Will do.

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-bess-evpn-oam-req-frmwk-08  - IETF stream
   EVPN Operations, Administration and Maintenance Requirements and
   Framework (Informational)
   Token: Martin Vigoureux

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Eric V: Just to say that I support your Discuss, John.

John: I'll just comment that Donald has been responsive and I'm iterating with
him, so I think he'll be able to take care of my concerns and nothing further
will be needed. I can loop you in too, Eric, if you want.

Eric V: Thanks.

Amy: Okay, so this will be IESG Evaluation, Revised ID Needed.

 o draft-ietf-tsvwg-transport-encrypt-20  - IETF stream
   Considerations around Transport Header Confidentiality, Network
   Operations, and the Evolution of Internet Transport Protocols
   (Informational)
   Token: Martin Duke

Amy: There are no Discusses for this document, so unless there's an objection
now it looks like this one is approved. The Consensus is unknown, so I'll mark
that yes for you.

Martin: Thanks, and thanks for everyone's comments.

Eric V: This document really should receive congratulations. It's really an
academic paper, and really well written.

Martin: I'll pass that on. It was quite a battle to get it in the shape it's in
and they've bene working hard on it.

Eric V: I appreciated also the document shepherd's writeups. He went into many
details about this pre-WG Last Call and it was very useful.

Martin: Again, I'll pass that on to the authors. Revised ID needed, based on
these comments here.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-smyshlyaev-mgm-00
   IETF conflict review for draft-smyshlyaev-mgm
     draft-smyshlyaev-mgm-19
     Multilinear Galois Mode (MGM) (ISE: Informational)
   Token: Benjamin Kaduk

Amy: There are no Discusses for this conflict review, so unless there's an
objection now it looks like this one is approved and can go back to the ISE.
Hearing no objection, so we will get that sent with the note in the tracker.

 o conflict-review-crocker-email-author-00
   IETF conflict review for draft-crocker-email-author
     draft-crocker-email-author-04
     Email Author Header Field (ISE: Experimental)
   Token: Murray Kucherawy

Amy: There are no Discusses for this conflict review, so unless there's an
objection now it looks like this one is approved and can go back to the ISE.
Hearing no objection, so we will get that sent with the note in the tracker.

3.4.2 Returning items

 NONE

4. Working Group actions
4.1 WG creation
4.1.1 Proposed for IETF review

 NONE

4.1.2 Proposed for approval

 o Effective Terminology in IETF Documents (term)

Amy: I do have a blocking comment for this one.

Lars: That's expected. We got quite a bit of comments in the last few days. I'm
working with the prospective chairs to incorporate that into the next charter
revision. I put a link to the Google doc into the jabber chat for people to
take a look. Once I have that done I will share with the IESG to see if we
captured what, for example, Ben has outlined here. The feedback from the
prospective chairs was similar to what Ben has in his message. After we discuss
it with the IESG I think it needs another IETF Last Call to the community, so
this is not approved.

Roman: Just to reiterate, I think that's exactly all the right process things
to do.

Lars: For comparison you can read what Ben wrote. I've gotten feedback from
others that we should strengthen the text in the charter that talks about
giving guidance to IETF contributors to use language that is most effective and
helpful, and deemphasize the point about inclusivity or exclusivity, and talk
much more about that it's useful to use language that's most easily understood
and widely accessible. That's what the current rewrite is trying to do. You can
all wordsmith in the Google doc if you like. One thing I wanted to briefly
mention, you've seen there was some feedback that we should punt this to the
RFC Editor and basically have them define the guidance for us. I don't think
this is the right approach for two reasons. One is that it would come very late
in the game if we wanted to have the RPC fix terminology years after documents
and protocols and specifications are being discussed in the IETF and their
language and terminology are pretty much settled by then.  The second reason is
that we don't have an RFC Editor and we probably won't have one for another
year; and even then this is probably not the first thing they're going to start
working on. So it basically means nothing would happen for a couple of years.
Both of those things make me not want to punt this to the RFC Editor. This is
something the IESG can decide to do for the IETF.

John: Another suggestion along the same vein was that it could be done as an
IAB workshop.

Lars: I don't quite understand where that comes from and how it fits in, given
that the IAB doesn't really have control about IETF processes.

John: I took it to be a couple of things, one that it's a convenient way to
move the problem to someone else's inbox. The other thing is that it seemed
like the people who were proponents of that were most interested in making sure
that the recommendations coming out of the process, WG, whatever, were not
mistaken for mandates.

Lars: Right. That's another point we need to stress in the charter text. I
tried that already by saying the focus is to give guidance to IETF
participants. I think we already say there's no agreement particularly about
the motivation towards inclusivity and exclusivity. But yes, we should
definitely stress that this will not become a formal checkbox in the
Datatracker or something. This is guidance for individual contributors to pay
attention to if they feel like it.

Warren: What if we word it as, this is a convenience to authors to help them
understand what words might be better? I might be wrong but I think fairly much
everyone would like to use words that are more effective and are not harmful or
hurtful.

Lars: That's a good suggestion. The current charter uses the word
"recommendation" a couple of times and several people have said it's too close
to the 2119 term and I've changed that. I like your phrasing better than mine
so I'll edit that in. Or you can make a suggestion also in the google doc. I
think we don't really need to spend much more time on this, other than to say
there will need to be another round through the community before we can charter
this.

Ben: I have a couple of questions. One, should I leave my block there, or clear
because it's going to be moot?

Lars: Leave it there. We'll definitely come back tot his anyway and at least
this way I see the little red thing when I look at it.

Ben: The other thing, to loop back a little bit, I think one of the reasons
people were suggesting an IAB workshop is because they have a history and track
record of being able to cover topics that are controversial, not clearly
technical, and where there's no one right answer. They are experienced at
talking shop where these very different points of views can meet and come
together, so it might be effective. But I'm inclined to agree with you that
it's not necessarily required to do something outside of the IETF.

Warren: I actually really like the idea of an IAB workshop, largely for the
reasons Ben said. It's something we've often done for things that are difficult
and not purely technical type discussions. When I say "we" I mean I guess the
IAB. I think it also reinforces that this is not binding; it's ways you can
behave that are less bad. I worded that poorly.

Mirja: This is my personal point of view but I'm not sure I agree here. The IAB
doesn't have to listen to community consensus; usually things are driven in the
IAB because IAB members think they're important. We try to get input from the
community and listen to the community, and especially about things related to
the RFC Editor we've been very community driven, but that's not our usual mode
of operations. I also want to mention that I think the scope is getting widened
a little bit with these changes. Initially this was only about a list of words
you might want to avoid, but talking about having terminology which is clear
and helpful and so on is much more than that.

Lars: This was never about a list of words. I don't understand why this is
still not clear. The charter specifically says that the document the WG is
supposed to work on is, the old word was recommendations and the new word is
guidance, on why it's in the interest of IETF contributors to use language that
makes their ideas more accessible to all. That's the point. The charter says
there are resources like from inclusive naming and others that people can refer
to for detailed suggestions of terminology to maybe pick as alternatives, but
the WG will not create this for the IETF.

Mirja: Initially this discussion was about providing a list of words.

Lars: Initially it started with that but it changed quite a bit. Reading some
of the feedback, a lot of it was very good but some of it clearly hadn't looked
at the charter in a while.

Ben: I think the initial discussion of draft-knodel kind of poisoned the well
in many peoples' minds.

Warren: I re-read many of these documents which could be starting points and I
do think they set very different tones. Things like the Gondwana document sets
a very different tone to the Knodel documents. Having something along these
lines, these are the sorts of starting points, would help realign the
discussion in the right way.

Francesca: That was the recommendation of GENDISPATCH, that draft-gondwana
would be the starting point. I made this comment last time and added it to my
ballot here just so it doesn't get lost.

Lars: Thanks for the reminder. There are three documents that have been written
in this space. The prospective chairs have read them and they suggest that
Bron's document does seem to have the largest fraction of useful text, but the
other two documents might make points that should be lifted into Bron's
document. My hesitation for putting it in is that I don't want GENDISPATCH, a
different WG, to do a consensus call for TERM. I think the chairs, if and when
TERM is chartered, want to start with reaffirming that earlier consensus in
GENDISPATCH in TERM. I'd be surprised if it was different. The plan would be to
have a merger of text of sorts, but the basic structure and approach would come
from Bron's draft. That's what the current suggestion would be. But I think
we've eaten quite a chunk of time on this. Ben, leave the block there. I'll run
an update by you and the community and then we'll see where we are from there.

Amy: So the TERM charter is not approved and we'll wait for instructions from
you, Lars.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o CBOR Object Signing and Encryption (cose)

Amy: This charter has no blocking comments, so unless there's an objection now
it looks like this rechartering is approved.

Ben: I guess I should probably make the typo fix that was suggested. I should
be able to do that right after the call ends, so go ahead and do your normal
processing and if I don't get [the typo fix] in in time, we'll just live with
it.

Amy: Okay, we'll probably send the announcement tomorrow, so you've got a bit
of time.

5. IAB news we can use

Martin V: Let me check a few notes. By the way, Ben Campbell did a nice thing
in his liaison role at the IAB and he sent an email. I'll try to do the same;
rather than doing this orally, having it written down seems like a very good
idea. IAB is converging on the definition of a liaison coordinator role to
replace the existing liaison shepherd role. Also something I wrote down is that
IAB is currently looking at organizing a workshop on network quality, and I
think this one is going to be really interesting if it goes forward. Mirja,
anything to comment on that?

Mirja: This was a proposal from people from Apple about having better
measurements of network quality for users to understand. It's still under
discussion but there's definitely interest on the IAB.

Martin V: I do have one question on that. How does that relate to discussions
linked to APN, if any?

Mirja: I wouldn't see a strong relation here because it's really not about
mechanisms in the network to change network quality or anything, it's really
just about measurements and how to provide this information in an
understandable way to the user.  And we also have now sessions which are more
focused on technical discussions only, where we don't have the boring admin
stuff, and we have a discussion next week on DOS detection and attack
protection mechanism that Jared is preparing, if that's of any interest for you
guys.

Martin V: Thanks.

6. Management issues

6.1 [IANA #1193081] Additional designated experts for RFC 8949 (IANA)

Amy: This action item has been assigned to Francesca.

Francesca: Christian Amsuss has agreed to do it.

Amy: Is there any objection to naming Christian as an additional expert for
this registry? I'm hearing no objection, so we will send official note to IANA.

6.2 Update "Last Call Guidance to the Community" (Lars Eggert)

Lars: This is one of the two things we talked about earlier in action items.
The other one is the update to the IETF discussion list charter. If people like
I can take the action item of just changing that IESG statement, and we can
basically just override it on the webpage.

Amy: It's been a long time since we've done a statement but I believe you have
to put out a new statement with a new date attached.

Lars: That's what I meant. Yes. But we would call it the same and the text
would mostly be the same except for that one change. Really the only change is
in that first paragraph, where it says ietf@ietf.org, and that would change to
last-call@ietf.org. But I'll basically copy this thing in a Google doc and let
you know when it's done.

6.3 Draft IESG Conflict of Interest Policy (Lars Eggert)

Lars: I've been busy with other things but we should finalize this. Brad has
commented on it, so I think the action for everybody is to give this a read and
see if we want to formally adopt it or if there's something else that needs to
be done.

Warren: I think it looks good and we should just do it.

Alvaro: I put some comments in the document because I'm concerned about a
couple of points that Brad added, one at the end which Barry and Mirja agreed
with me, what to do in case of violations. Taking community action is already
something the community can do, and we don't necessarily need to put it in
here. The other one, towards the top on page 2, where the text suggested says
that we should normally recuse whenever there's an actual or apparent conflict
of interest. I get the feeling that's very strong language, because 'should'
has the implication that unless there's really good cause, I should do that. I
haven't seen anyone else say anything about that, so maybe it's only me.

Warren: Apologies, I was probably looking at an old version. That does sound
concerning to me. I'll take a look.

Lars: So let's let people read this, it's only a page or two long, and try to
approve it next time assuming everyone has read it and we clarify the few items
that are still open. I don't think we need to go back to Brad, I think we can
just decide what to do. Alvaro's made some suggestions here. We can just decide
what we want to do and take it into effect.

6.4 Session Requests for IETF 111 (Liz Flynn)

Liz: It's mostly for all of you to discuss. So far from the feedback people
sent [on the list], it seems exactly split between prioritizing everyone
getting at least one session and minimizing conflicts. So I'm not sure what to
do there. The one thing I did want to mention is that I would caution against
adding a third time slot length option. Based on past experience, it can make
scheduling a lot more challenging because if only a handful of groups choose a
90 minute slot and they all conflict with each other, we're kind of stuck.
Banking on the appropriate number and variety of groups to request a particular
time slot length is probably not the best way to set ourselves up for success.
I'd recommend if we want the most flexibility possible, we should stick with
only two options. Other than that, I think you probably need to talk more about
what the priorities should be.

Lars: I think the first question to ask is whether it's worth going back to
eight tracks or whether nine was doable. We did that once now, and while it was
good, it slightly did increase the spread in the community.

Liz: If we go back to eight tracks, we're going to have to limit requests more
than just every group getting one session, because every group getting only one
session is still probably too many to fit in eight tracks.

Martin D: Yeah, I don't think we have any option to go back to eight. I don't
want to be kicking WGs out of the meeting, which is what it would take. That
seems too extreme.

Alvaro: I guess none of us want to extend the day, right?

[Several voices: No!]

Mirja: I guess it's not really a problem to have nine tracks or more, because
we're not fixed to rooms. It's only about conflicts.

Warren: I'll just note that I'd actually be perfectly fine if we extend a day
or even two if it means we get through more things. The majority of IETF
participants only show up for some set of sessions and if they happen to do it
on a couple of extra days, instead of having to pack more stuff into one day,
that might be okay with many of them as long as they understand this is a
virtual type way of laying things out and not a physical meeting change.

Ben: Are you proposing more than five days or more than six hours per day?

Warren: I'm proposing either one. I would be fine with five days and two on the
next week, say Monday - Friday and then Monday - Tuesday, or just come in more
than six hours. A lot of people show up in whatever sessions they're interested
in and the rest of the time they can nap or whatever.

Francesca: I've heard the opposite feedback, that people don't want more hours
and they don't want more days.

Martin D: So Liz, if we restricted each WG to one slot, how many slots would we
need to add to go back to eight tracks?

Liz: This is obviously based on the requests from the last meeting. We got 123
discrete session requests and the eight track schedule has space for 112. For
everyone who requested two, if we only accepted one, we'd still be missing a
few sessions and many hours.

Martin D: I said this on the list but the only compromise I can think of is to
make the plenary day a full day and then tack on the plenary, since the plenary
is kind of a minority sport. And actually it might increase the tension to
shorten the plenary, which might not be the worst thing in the world. So if we
as leaders have to suffer through a long day on Wednesday, that might be the
right trade to make.

Lars: I'm not sure if that gives us enough time. With regards to Warren's
suggestion, I think adding days is problematic. It's still some time out until
July, but people might have already scheduled things on the adjacent weeks, and
if we want to just overflow we'd have to communicate that with even more lead
time. Extending the days, we don't necessarily need to do that, but they are
already kind of long. My suggestion would be to try to actively manage the
incoming requests a little more than we usually do as ADs and try to actively
probe chairs, to ask, hey do you need all that time, do you need to meet at
all, is an interim an alternative? And see what we end up with, and then figure
out what to do.

Ben: There's always some split between those sessions where people are actually
using the time productively to make progress on open issues, vs. the slots
where people are just reading from slides and presenting a report. If we can
identify in advance the latter category and have them not do that, that's
beneficial.

Francesca: I see [on the email thread] there are people having different
opinions between conflict resolution and having enough time. I just wanted to
point out that for areas with more WGs, like Security and ART, there will be a
problem if there are a lot of conflicts. We were able to follow all the WGs
last meeting because there were three ADs rotating, and there were still enough
conflicts that Murray was supposed to clone himself and be in two places at
once. I would say that conflicts is a big problem and I would be okay with
being more active in asking the WGs if they really need all the time they are
requesting, for those that are asking 2 x 2 hours, it might be something we
already want to bring to the WG so if they feel they want to schedule an
interim they can do that already now.

Martin D: I'd be a little uncomfortable with pushing groups to interims in lieu
of any sort of meeting [at 111]. I think we tried that with 107 and I don't
think that was great, to have a really thin meeting. I'm not saying we'd get
there, but I think it's not a great direction. But in my WGs I will enforce the
idea that if you want two sessions, you should have one at 111 and one as an
interim, and work the agenda so the in the weeds stuff is in the interim and
the tourist friendly stuff is in the main IETF meeting. I think that's a policy
we can agree on if we want and I'd be comfortable with it. Rather than just
saying, do you really need to meet at all?

Francesca: I agree with you, Martin.

Lars: So it sounds like we're keeping the days and the structure of the days as
they were, and try to otherwise manage the session request load, and if we need
more than eight tracks we will do that and not feel too bad about it.

Martin D: Do we want to have an informal policy of one session per WG?

Francesca: We don't need to make it a policy, but I think it's enough if as
responsible ADs we see it coming, that we double check with the WG and make
sure it makes sense.

Eric V: Also to send a clear message to the WG chairs. They're not stupid
people, they know the constraints as well.

Alvaro: We can even tell them that the second session may not be scheduled in
the end, if we can't allot everything.

Ben: So Alvaro is volunteering to send mail to the WG chairs list?

Martin D: The reason I used the words 'informal policy' is I didn't want to be
the one sucker who refuses all the second session requests when all the other
ADs don't. I'm not saying we need to put out an IESG statement or anything, but
if we have general agreement that we'll try very hard to hold our groups to one
session, I'm happy to fit in with that consensus.

Rob: We have a policy of not scheduling interims the week before or after; do
we still want to keep to that or if we're pushing sessions out does it make
sense to relax that and allow interims in the week after IETF?

Amy: You already allow interims the week after IETF, you don't allow them the
week before or the week of.

Rob: Oh, that's fine then.

Francesca: We shouldn't be pushing groups out as you named it, we should be
asking them if it's absolutely necessary to have two sessions of two hours.

Ben: Going back to having a unified position across the IESG, do we have a
sense for which groups or sorts of groups we think would end up needing two
sessions? QUIC? SPRING?

Warren: DNSOP has always had two sessions and has always completely filled
them. I think they'd be okay with a second slot but they could also probably
make do with an interim. What I was going to say was I think we might have
discussed this before, but can we also please try to stop scheduling interims
during the telechat? I think there's one happening now, which presumably the AD
cannot go to because it's the telechat.

John: If it's the one I'm thinking of, it's technically not an interim but a
design team meeting, but you're still right.

Francesca: No, there's also an ACE meeting.

John: Oh, so there are two things.

Francesca: I don't know how to do this, but it would be good to remind the
chairs to actually think of conflicts. A lot of chairs just take the list from
the last meeting and it's not necessarily updated.

Warren: In the past we'd discussed making it harder for people to just blindly
copy and paste from one meeting to another. I can't remember what the craziness
was, but we talked about it.

Alvaro: I thought it was whether it's pre-filled or cut and paste.

Warren: I have a horrible feeling it was me who suggested we fiddle with the
CSS so the text is not copy-able.

Mirja: I think there's still a button to copy over from last time. But I think
you should reach out to the chairs because not all of them might be aware that
we are in this situation and not all of them might be aware that we have more
requests than we have hours.

Liz: One other thing to keep in mind is that we can change the tool to allow
them to only request one session, and then they could explain in the notes if
they want to have a second session and for how long. That might be enough for
some people to say they really only need one. So that might be one option, if
you want.

Martin D: I would also like to propose an amendment to my proposed conspiracy
and say to restrict it to two hours. I've often encouraged some of my chairs to
say they would take two 1-hour sessions to make scheduling easier. So that
should be fine. But the principle should be that we hold them to two hours.

Eric V: That can be decided once we have all the requests, right?

Martin D: I've encouraged chairs to say that they need two hours but they're
happy to split that into two one-hours if needed. That's a good prosocial thing
to do because it makes Liz's job easier, and I don't want people to say that's
not okay because it's two slots. That's just what I was saying.

Warren: If the person says in the comments that two one-hour slots are fine, I
would hope that we don't dock people for being nice. They shouldn't be
automatically excluded. But I would note that if we all agree to the informal
policy and none of us do it except for you, the rest of us will all have better
sessions.

Francesca: What if we warn the chairs to please think about it, and you're
welcome to request sessions if you need, but if there are too many conflicts [a
second slot] might end up not being scheduled.

Alvaro: I like that. We probably need to tell them that the second one may not
be scheduled.

Francesca: At that point we'd have to make a choice if it makes sense to
schedule it with conflicts or not schedule it.

Martin V: Chairs could also try to plan for their session before requesting
their slot, so they have a clearer idea of how much time they need.

Lars: We always try and it never really happens, but we could put a nugget in
the email that says if we need to reject slot requests for second sessions,
we'd decide this based on the published agendas or something so there's
motivation for chairs to put the agenda in before the last second. I guess the
question is, who is the stuckee to draft text to the WG chairs?

Martin D: I'll offer to write something today. I can create a Google doc
expressing what's going on and some prosocial things people can do. Maybe you,
Lars, can send it out to the whole WG Chairs list on behalf of the IESG when
it's ready.

Lars: I can do it, or maybe the Secretariat.

Martin D: I can write something and circulate it for discussion.

Lars: Thank you.

Amy: Anything else to discuss about session requests? Thank you.

6.5 [IANA #1194832] Designated experts for RFC 9018 (IANA)

Amy: Warren, this was assigned to you but you indicated you had a name to put
forward.

Warren: I do indeed. Onrej Sury says he is happy to do it. He's already a
designated expert for various other things.

Amy: Any objection? Hearing no objection to this, so this is approved.

6.7  Additional designated experts for RFC 8855 (Murray Kucherawy)

Murray: I have an action item from way back in the beginning for 8855. One of
the authors, Tom Kristensen, has volunteered to be a secondary. That satisfies
the management item.

Amy: Is there any objection to approving Tom Kristensen as the secondary
expert? Hearing no objection, so we'll send note to IANA.

7. Any Other Business (WG News, New Proposals, etc.)

Alvaro: We've been talking about the errata update to the statement and I think
we're settled on what it is. The question I asked on email was: do we need to
send this out for community review before or not? I think we don't because it's
mostly instructions to ourselves. If anything, maybe WG chairs, but I'm happy
to just post the statement. Anyone have any thoughts? [silence] I'll take no
thoughts as 'go publish the statement.' Thanks.

Lars: I have something else on the discussion of whether we want to try to use
Slack with the IAB. Jason has okayed the use of the paid Slack instance that
the Secretariat and LLC is using for the IESG and IAB. They are reconfiguring
some access and message retention policies and then I will just invite you to
two channels, one for the IESG and one joint for IESG and IAB, on that slack.
Hopefully soon.

6.6 Executive Session: April 1 Drafts