INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2023-08-10 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Amy Vezza, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Jenny Bui (AMS) / IETF Secretariat Jay Daley / IETF Executive Director Dhruv Dhody (Huawei) / IAB Liaison Martin Duke (Google) / Transport Area Lars Eggert (NetApp) / IETF Chair, General Area Sandy Ginoza (AMS) / RFC Editor Liaison Jim Guichard (Futurewei Technologies) / Routing Area Erik Kline (Aalyria Technologies) / Internet Area Mirja Kuehlewind (Ericsson) / IAB Chair Murray Kucherawy (Meta) / Applications and Real-Time Area Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat ƒric Vyncke (Cisco) / Internet Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Roman Danyliw (CERT/SEI) / Security Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Francesca Palombini (Ericsson) / Applications and Real-Time Area John Scudder (Juniper) / Routing Area Robert Wilton (Cisco Systems) / Operations and Management Area OBSERVERS --------------------------------- Lee-Berkeley Shaw Greg Wood 1.2 Bash the agenda 1.3 Approval of the minutes of past telechats 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Rob Wilton to find designated experts for RFC 9390 (Diameter Group Signaling) [IANA #1275381]. Amy: Rob is not here today, so we will keep this in progress. o Murray Kucherawy to find designated experts for RFC 9122 on IANA Registry for Sieve Actions IANA #1275603]. Amy: This is on as a MI to approve the experts Murray found. o Roman Danyliw to find designated experts for RFC 9393 on Concise Software Identification Tags [IANA #1275658]. Amy: Roman is not here today, so we will keep this in progress. o Paul Wouters to find designated experts for RFC 9420 on Messaging Layer Security (MLS) [IANA #1276814] Paul: In progress. o Murray Kucherawy to find designated experts for RFC 9457 on Problem Details for HTTP APIs [IANA #1277796] Murray: In progress o Murray Kucherawy to find designated experts for RFC 3326 on The Reason Header Field for the Session Initiation Protocol (SIP) Amy: It looks like the expert wants to step down and has suggested a replacement. We'll look at this in Management Items and possibly mark this DONE. * OPEN ACTION ITEMS o Robert Wilton and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in July 2023. Amy: In San Francisco you indicated you wanted to mark this item DONE. ƒric: On the other side I know a bunch of people got COVID in San Francisco. Andrew: The latest news about new variants is worrying. Lars: Let's not discuss that on this call. This is about mailing list activity decline due to COVID lockdowns and online meetings. ƒric: We may want to keep the report around. Amy: Right this is just the mailing list statistics. And I know the tools team is working on getting some statistics into the datatracker for more than just mailing list activity. Warren: We can bring it back if we need to. Amy: Yes, we can pull this back out if needed, but this on hold action item you said should be marked complete. Mirja: Maybe look at it once a year, before the March IETF? Not just these statistics but others as well. Andrew: We want to keep an eye on the statistics, but I agree we don't need to hold the action item open. Mirja: So look at it for the Sunday agenda before the March IETF. A general understanding of how things are, and looking at this would be helpful. Amy: So the action item for Rob and Warren is done and we'll mark it as such. o Warren Kumari to follow up on a bis document for RFC 8126 regarding designated experts. Warren: This is in progress. o Lars Eggert to send email to the LLC about Letters of Invitation for Interim Meetings and Retreats Lars: This is done. o Lars Eggert and Martin Duke to rewrite IESG statement to give more guidance about issuing LOIs for interim meetings. Lars: We have text we're going to look at later. This is also done. o One AD from each area to diagram their Area topology and send it to Martin Duke for collation. Martin: This is done. o Roman Danyliw to open a Datatracker issue suggesting a feature to better signal individual contributions Amy: Roman is not here today, we will keep this in progress for him. o Lars Eggert to ask the LLC to come up with a proposal on how we can support a pre-configured remote participation option inside meeting rooms. Amy: The Secretariat set up in-room Webex sessions for each side meeting room, but we were not sure what it was going to look like or if it would work until the Saturday of the meeting. We will see what we can do to improve user experience in Prague. I don't know if we've gotten any feedback on it, but I know people were using it. Lars: They told me it went well. The intent is this would continue. Amy: I believe that is right. We've now done it once and worked out some of the bugs, we'll try to improve for next time. Mirja: People didn't know about it. The laptop only used the Webex interface over the browser and if someone closed the browser how to get it back. So if you could install the Webex app. Amy: I am sure we have some things to improve. We didn't know how it would work or if it would work when we got onsite in San Francisco. So it was a lot of experimenting with the in-room audio. o Lars Eggert to write an update to the Support Documents in IETF Working Groups statement. Lars: This is in progress. I'll circulate the statement and we'll bring it back for discussion. o Murray Kucherawy to respond to the email "RFC 1952: Any plan for a new extra field registry." Murray: Yeah, I responded to this, so done. o John Scudder to collect AD qualifications for NomCom. Amy: John sent email that this was sent to the NomCom Chair so we'll mark this as done for him. o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John Scudder, and Jim Guichard to draft text regarding document authorship/editorship with regards to the number of authors listed. Andrew: There has been no progress yet here. I'll start an email thread, this is in progress. ƒric: I saw the upcoming TEAS document has seven authors listed and I do not mind that since there is a good reason. Andrew: I agree. There are exceptions. o Lars Eggert to facilitate a community discussion on priorities for IESG processes. Lars: We're starting the discussion today. This is in progress. 2 . Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-bess-evpn-pref-df-11 (Preference-based EVPN DF Election) Intended status: Proposed Standard Token: Andrew Alston Amy: A couple of discusses. Andrew: Nothing in particular to discuss. Amy: Moves to substate Revised ID Needed. Thank you. o draft-ietf-nvo3-bfd-geneve-12 (BFD for Geneve) Intended status: Proposed Standard Token: Andrew Alston Andrew: This needs a revised ID. I want to see what the late discuss contains, but John's should be fairly straightforward. I'll follow up with the authors. o draft-ietf-idr-long-lived-gr-06 (Support for Long-lived BGP Graceful Restart) Intended status: Proposed Standard Token: Andrew Alston Amy: No objections, looks like this is approved. Andrew: Nothing else required. Amy: Approved, announcement to be sent. It will be sent on Monday as usual. o draft-ietf-uta-rfc6125bis-14 (Service Identity in TLS) Intended status: Proposed Standard Token: Paul Wouters Amy: Has a discuss. Paul: No need to discuss. Amy: Okay, so we'll add a substate of Revised ID Needed and move on. o draft-ietf-bess-pbb-evpn-isid-cmacflush-08 (PBB-EVPN ISID-based C-MAC-Flush) Intended status: Proposed Standard Token: Andrew Alston Amy: No discusses here. Andrew: I want a revised I-D for the comments. Amy: So approved, announcement to be sent, revised I-D needed. o draft-ietf-dnssd-update-lease-08 (An EDNS(0) option to negotiate Leases on DNS Updates) Intended status: Proposed Standard Token: ƒric Vyncke Amy: No discusses. ƒric: We need a revised I-D. Amy: Approved, announcement to be sent, revised I-D needed. o draft-ietf-dnssd-srp-23 (Service Registration Protocol for DNS-Based Service Discovery) Intended status: Proposed Standard Token: ƒric Vyncke Amy: This one has discusses, but one of the discuss holders is not here. Do you need to discuss with the other? ƒric: I see the author has replied, do you need to discuss it? Paul: I only just got the reply. I think we're mostly in agreement, but I want to read it more carefully, because it feels like a hand wave, I'm right kind of response. ƒric: But the dialog is started. So we can say revised I-D needed. o draft-ietf-lamps-caa-issuemail-06 (Certification Authority Authorization (CAA) Processing for Email Addresses) Intended status: Proposed Standard Token: Roman Danyliw Amy: The discuss was cleared, so this will go into approved, announcement to be sent, and since Roman is not here today we'll add the substate of AD Follow-up so he can make sure anything outstanding is addressed before we send the announcement. 3 . Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-teas-rfc3272bis-26 (Overview and Principles of Internet Traffic Engineering) Intended status: Informational Token: John Scudder Amy: There are no more discusses on this document so it will go into approved. John also couldn't be here today so we're going to add the AD Follow-up so he can do final checks. o draft-ietf-teas-ietf-network-slices-22 (A Framework for IETF Network Slices) Intended status: Informational Token: John Scudder Amy: This has discusses. John isn't here to discuss it. Paul: This is pretty straightforward. I just want to see if everyone was okay with the document calling it an "IETF network slice." I guess it is to distinguish it from a vendor network slice. Are we okay with something being termed an "IETF" something? It's sort of weird. I'm a little concerned here, but we're also very late in the process, I'm not sure. Warren: I'm also fairly concerned about it. I don't think it's just saying we don't mean other people's network slices. It might seem like we're pushing to supporting this. Paul: There is also a VPN document that is a draft that says we mean slices but we'll call it network slice in the document so it sort of odd. Andrew: I think the wording may be wrong, but the sentiment is not. We saw it with the QUIC stuff where you started to see the Google version vs. the X version, and it needed to be differentiated between the two. So I see your point, but I also think we need to distinguish between them. Warren: For QUIC, Google version of the protocol was first and Google brought it to the IETF and said "go take this over and do whatever." And we worked on it, there were a bunch of proponents who came along and pushed really hard for it, too. For Network Slicing, I think this had four or five side meetings, and their scope was incredibly broad. They may have had a BoF or even two where there was a strong push for a WG, so there is a lot of sensitivity here. Andrew: There is a need to differentiate so people know what they are talking about. I think it needs a wording update, I'm just not sure. Erik: I don't agree. This is a network slice, and it's definition is basically looking at only IETF-related technologies. The document is just saying these are our technologies and we think that constitutes us to define it for the IETF. Mirja: In the QUIC example, it doesn't differentiate between IETF QUIC and Google QUIC in the document. Lars: Thinking about this now, I think there is a way forward for it to give a definition of network slices and when other documents was to refer to the IETF definition they just cite it. Erik: Others may have a different definition of a network slice. Lars: Yes, but they would refer to their own definition and not the IETF one. Paul: I'm also concerned that there are different IETF technologies that could be considered a network slice because we have so many different ways of doing things. Zahed: QUIC we didn't use Google QUIC or IETF QUIC, so I'm not sure this is a good analogy. For network slices everyone has their own definition. Other SDOs have their own definitions, so calling it an IETF Network Slice makes sense to me. So Lars' suggestion to give a definition and refer to it makes sense to me. Warren: I am also surprised to see this here. Does this fall within the charter for TEAS? It feels like it just popped up here, and maybe that is fine. It just made me blink. Andrew: I feel like we should discuss this when John is here. And maybe the chairs. ƒric: We can defer it two weeks to make sure it is on the agenda. Warren: The term IETF Network Slice shows up something like 326 times in the document. Paul: It would be so much shorter if we remove 325 words. Warren: They are defining what an IETF network slice is. ƒric: I think both the authors and chairs should be there. Amy: I will put in revised I-D needed. ƒric: Can you hit the defer? Amy: One of you can, sure. But it seems weird to defer it after all of this discussion. I can just move it to the next agenda for John so it will come back as a returning item. Andrew: I think moving it and having it come back as a returning item is the more sane option. Amy: Okay, this will come back on August 24. Hopefully John will be okay with the move. He could remove it from the telechat at anytime. 3.2 Individual submissions via AD 3.2.1 New items o draft-gutmann-testkeys-04 (Standard PKC Test Keys) Intended status: Informational Token: Paul Wouters Amy: No discusses, and I hear no objections, so this one is approved. Paul: Please put it in AD Follow-up. I want to make sure there are no minor changes needed. Lars: After the document, we got a vulnerability report because someone found an RFC that had private keys in it as test cases. So I wonder if some text is needed to state this is an example only. Warren: Many of those are automated alert things. Paul: Okay, I'll look at that. Amy: Okay, approved announcement to be sent, AD follow-up. 3.4 IRTF and Independent Submission stream documents 3.4.1 New items o conflict-review-irtf-icnrg-icntraceroute-00 (IETF conflict review for draft-irtf-icnrg-icntraceroute) draft-irtf-icnrg-icntraceroute-10 (ICN Traceroute Protocol Specification) Intended status: Experimental Token: Roman Danyliw Amy: Roman did the RFC 5742 review for this document but I have a discuss. Lars: Martin seems to want to synchronize the responses. Martin: Right, the two ICNRG documents were reviewed by two different people. The documents are so similar, I think the review response should be the same. I prefer ƒric's review naming the IPPM and INTAREA. Zahed: I think I also prefer ƒric's review. Lars: I can change Roman's review. I can also just take the conflict review and change it that way. I don't think Roman will mind. Amy: Okay, so with the cleared discuss, this is approved for the no problem message to go back to the IRSG. 3.4.2 Returning items o conflict-review-irtf-icnrg-icnping-00 (IETF conflict review for draft-irtf-icnrg-icnping) draft-irtf-icnrg-icnping-10 (ICN Ping Protocol Specification) Intended status: Experimental Token: ƒric Vyncke Amy: And for this one, it is also approved and the no problem message can go back to the IRSG. We'll move on. 4 . Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review (1 of 1) o WG name: Key Transparency (KEYTRANS) Charter: charter-ietf-keytrans-(00-11) Area: SEC (Roman Danyliw) Amy: I have a block in the tracker that seems like it is for some editorial nits? ƒric: Right. It's for the work items and what status they will be, that's it. Amy: We will wait for instructions from Roman for KEYTRANS. 5 . IAB news we can use Amy: Any news? Mirja: We talked about two IAB statements really just very new so not much to report. We discussed the two proposed programs, Identity Management and the Impact programs in case you are interested. And one important news, we got accepted to the session for the IGF. Lars: Anyone from the IESG going to be there? Warren: What are we going to say there? Lars: Its an overview of the IETF, since no one there knows what we do. Mirja: I got feedback that we need to make it more fancy than just a bland overview so maybe with a technical topic to draw people in and introduce the IETF and our process. A couple from IAB, Colin will be there. Maybe Andrew can join remotely. So a general panel discussion and then a Q&A at the end. Warren: They are used to a formal system, that the IETF sounds loosey goosey. Having people take away that the IETF process has worked for forty years. Mirja: That is exactly the message we want to bring there. Not that rough consensus is difficult, but that we do have processes we follow. Lars: We need to see draft slides to review on an informal call. Here is how it works, here is how it works, and here is the work we've done for a long time. I don't think it needs a technical topic. Mirja: We want something more than let's introduce you to the IETF. Warren: We want to have something to respond when people ask why we keep encrypting everything which breaks their national security. Mirja: We want to align on what we say. Warren: Yes. I think the whole point is to get the messaging very carefully worked out. Lars: Do you know if Vint is going? Warren: Yes, he will be there. Lars: If he were on the panel he would draw a crowd. Mirja: Yes, Mallory has reached out to him already. Lars: We'll put it on an informal to look at the slide deck. Mirja: Andrew we reached out to participate, right? Andrew: Yes. Lars: I don't know if we mentioned this is the Statement Mallory and Paul are crafting, it's going to be circulated with the IESG before it goes out? Mirja: It needs a lot more work. We'll bring it to the IESG if it needs to be a joint statement. 6 . Management issues 6.1 [IANA #1276814] Designated experts for RFC 9420 (Messaging Layer Security (MLS)) (IANA) Amy: We've assigned this action item for Paul, a whole bunch of registries for the one document. 6.2 [IANA #1275603] Designated experts for RFC 9122 on IANA Registry for Sieve Actions (Murray Kucherawy) Amy: Murray has identified two people - Alexey Melnikov and Ken Murchison to be the designated experts for IANA. I hear no objections. Approved. 6.3 management item for DTN registry statement (Erik Kline and Zahed Sarker) Zahed: We don't need to discuss today. We're still discussing this on the DTN mailing list. Maybe next time when the document is on the agenda. Amy: We'll keep this on for next time, August 24. 6.4 Starting a Community Discussion on Priorities for IESG Processes (Lars Eggert) Lars: This is a follow up to the discussion that happened in GENDISPATCH. Two different discussions, one on Rich's and Adrian's document for making less work for the IESG and Mark had a draft on taking our IESG Statement on discuss criteria and making that an I-D. They're sort of similar in that they indicate the community wants to express more concretely what the IESG should be doing internally. I'm not planning to take any of these documents forward, and I'm not planning to charter a WG for it yet either. But I think a discussion on what they actually expect area directors to prioritize would be helpful. We may find the community wants us to prioritize document review over anything else, or that we should do something else other than working with management or what have you. My expectation is they will realize they don't have any consensus on what we should be doing. I think for the moment we have a very few people who have not overlapping ideas of what the IESG should be doing and I don't think we've heard from the vast majority of the community. Some may even think we're doing a good job. So I'm trying to figure out a forum to have the discussion. I think it would be a good non-WG forming BoF, but getting the right person to craft the bulk of the proposal that is acceptable to us is a big hurdle. Anny feedback is welcome. Mirja: Did you just say you wanted to start a BoF proposal? Lars: No, I'm not going to draft the proposal, it should come from someone else. Andrew: I like the idea of telling them to propose a non-WG BoF, because it means if they want to have the discussion, they need to do the work. Lars: I briefly talked to Jari and he wouldn't be opposed to being one of the facilitators of that BoF. He has long experience on the IESG but is no longer on a leadership body. But someone else would have to write this description. None of the three presenters have talked to me about this, but if they talked to any of you, please let me know. My fear is that we're going to get some last minute thing we can't get into shape and then it will get rejected and people will yell at us for it. Andrew: I talked to Adrian quite a bit so I can can have a chat with him and see where he is here. Lars: That would be good. Do some thinking abd come up with a proposal. It'll be a pain to schedule, but that's a given. Long document queues seems to be an Adrian aspect, Rich is more like we don't have enough candidates for AD positions and that is because it is so much work. There are all sorts of differeing opinions on what the problem is. Andrew: Recently Adrian said something strange to me that we are spending too much time on the small issues. If we're reading a document and get two pages in and it is garbage we should send it back to the working group and move on. Do more exercising the right to return thn making them sit with us trying to resolve the issues. Amy: Please note that the BoF submission deadline is September 8th, so one month. I know it seems very early, but we have one or two fewer weeks between 117 and 118 than we usually get. We have only just opened session requests. 6.5 Appeal Discussion and updated Statement (Martin Duke and Lars Eggert) Lars: This updated statement basically came out of a discussion with Ted and Alan about their appeal while we were in San Francisco. They consider their appeal addressed. I propose we approve this, and Greg puts it up on the Web site and we announce it and I will send a reply to the appeal saying that this addresses the appeal. [Discussion of document points, and small edits to the text were made] Amy: So it sounds as if the IESG has approved this revised Statement and it will be posted and announced. 6.6 Friday Afternoon Sessions for IETF 118 (IESG) Amy: This began as a discussion at 117. Lars: I think the proposal was we'd use the Friday afternoon session for groups that want more than two sessions? Amy: The discussion centered on using the Friday afternoon as a regular session for anybody. Lars: We will get the backlash that no one wants Friday afternoon. I thought we wanted to do an experiment with overflow time. Warren: I don't see giving a Friday afternoon slot to someone who requested one session. I think the experiment can be for those who request more than one. Lars: Do we know how many groups ask for three sessions or more? Amy: Liz would know, but she is on PTO this week. Lars: Lets give ourselves an action item to figure out what the experiment is, and we will use Friday afternoon for the experiment. Whether it is open scheduling or if we want to restrict it in some way. Warren: We can try to front load with all the sessions that want more than two and if we have to put others there we can. Mirja: I think the point is we can add a third session to Friday afternoon but it should try to deconflict if possible. Warren: We should let the community know as soon as possible. So they don't make early flights. ƒric: We can put a warning on the Web page as well. Jay: We can tell people when we open registration which will be any day now. ƒric: Yes. Andrew: We need to clarify if we're going to tell people we've got meetings on a Friday afternoon. Also will the post review happen Saturday morning? Lars: No after sessions Friday at 5. Amy: One of the things you discussed was having the Friday IAB/IESG wrap-up during the 90 minute lunch break, before the last sessions. You seemed to be leaning in that direction the last time this was discussed, so I don't know if that is still on the table or if you definitely want to do it after sessions would end. ƒric: We'd miss reviewing half the day. Amy: So it sounds like the discussion for this is ongoing. We don't know what the time will look like but it sounds like Friday afternoon sessions are a go, so we'll make sure Liz and the NOC know this. We'll make sure it gets into the messages about 118 as well. I think we're on track to open registration the week of the 14th, so next week. 6.7 [IANA #1277796] Designated experts for RFC 9457 on Problem Details for HTTP APIs (IANA) Amy: This was just assigning this action item to Murray to find experts for IANA. 6.8 Downref in the Extra Last Call for draft-ietf-ohai-ohttp (Murray Kucherawy) Amy: When the document came back from the RFC Editor and went into another, extra Last Call, it went out with a brand new normative downref. I believe the downref it to an IRTF document. Murray: Ther eis no contention of the issue that pulled this back from the RFC Editor, but we have to process the downref to say whether it should be added to the registry. I think it should be added. Amy: So when this document goes back to the RFC Editor, we will add RFC 9180 to the downref registry. Paul: I think there is an MLS document that has a downref to that as well. 6.9 [IANA #1278422] Designated expert for RFC 3326 (The Reason Header Field for the Session Initiation Protocol (SIP)) (IANA) Amy: So it looks like IANA and Gonzalo have done all the work for Murray here. Gonzalo would like to step down, and Christer is willing to step up, and all it needs is an okay from you, Murray, and no objection from the IESG. Any objection to replacing the current expert with the suggested expert? [no objections] Okay, we'll let IANA know, and mark that action item as done for you, Murray. 7 . Any Other Business (WG News, New Proposals, etc.) Amy: Another reminder the BoF deadline is September 8. Also anyone on the interview team for the RSWG chair, if you have not already please fill out the strawpoll so we can get these scheduled. Warren: Something Wes and I are planning on doing the DNSSEC list of what algorithms are recommended are in an RFC, and we're going to write a document to move that to an IANA registry. So the canonical place for something should be in a registry instead of an RFC. I am mentioning it as an idea. Paul: I tried to put it there initially, but people were against it in the DNS community. But we do it in TLS and do it IPSEC, we should do it in DNS. Warren: We'll work on a draft. Mirja: The support document statement, should go on the next informal? Lars: I think the next formal to minute approval. I mean, it's short. It's also not super critical. Amy: Thanks all! Have a good rest of your day.