INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2023-05-04 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Jenny Bui (AMS) / IETF Secretariat Roman Danyliw (CERT/SEI) / Security Area Martin Duke (Google) / Transport Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Jim Guichard (Futurewei Technologies) / Routing Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Dhruv Dhody (Huawei) / IAB Liaison Lars Eggert (NetApp) / IETF Chair, General Area Francesca Palombini (Ericsson) / Applications and Real-Time Area OBSERVERS --------------------------------- Ooonduke Greg Wood 1.2 Bash the agenda Amy: Does anyone want to add anything new to today's agenda? We added a new management item this morning to talk briefly about the SWOT/PEST. Andrew: There was something I sent to support to add to the agenda but I forgot what it was now. Amy: That's already on the agenda. 1.3 Approval of the minutes of past telechats Amy: The last minutes have only been out for a week, so we'll come back to this at the next formal telechat. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Roman Danyliw to find designated experts for RFC 9347, ESP AGGFRAG_PAYLOAD registry [IANA #1265971] Roman: In progress. o Murray Kucherawy to find designated experts for RFC 7462 (URNs for the Alert-Info Header Field of the Session Initiation Protocol [SIP])[IANA #1266696]. o Murray Kucherawy to find designated experts for RFC-ietf-jmap- blob-18 (JMAP Blob management extension) [IANA #1267309]. o Murray Kucherawy to find designated experts for Structured Syntax Suffixes (RFC 6838) IANA #1270651] Murray: These are all in progress. I'm waiting for replies from people. * 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. - On hold o Éric Vyncke to follow-up with the tools team on auto-populating the approval announcement text in the "ballot text" section (document abstract, responsible AD, document shepherd). Éric V: I just checked and this is working fine now, so you can remove this now. The question now is whether to add the IESG Note to the announcement. Which may be another topic, have you seen the discussion on email about what's the IESG Note we can write into the ballot proposal? Should it be put into the announcement as well? I think no. John: Or alternately, should we just take that out of the template completely? You can still type anything you want, as it's still a free form text field. But maybe if nobody knows what it means, we should stop prompting people to put it in there. Éric V: I'm fully with you, John. Can we change this action item to a new one, removing this IESG Note from the template? Jim: I found that note confusing as well. I just did my first one and there were a couple of comments I wanted to make on the document and thankfully John and Andrew prevented me from doing it in the IESG Note section, which might have been embarrassing. Warren: I did recently use that note section to fairly good effect. I don't know of an easy way other than the IESG Note spot to provide interesting background information for people who are going to look at the document. Jim: That's what I was looking for, where do I put something that's helpful for reviewers in the IESG but isn't going to go out publicly. I thought it was the IESG Note but John told me that's not what it's for. John: If you don't want it published, use slack or email; that's pretty much it. Anything in the Datatracker is public record. Warren: In my case I wanted it to be public. It seems like it's useful sometimes to add an annotation to a document so that everyone who looks at it understands its purpose. The reason I used it fairly recently is because with a status change document, nobody ever understands what they are, so I wanted to say go look at this other document and here's what a status change is. Maybe rename it from IESG Note? Éric V: Public IESG Note? Warren: IESG Helpful Annotations? Additional Note? Éric V: I think "public" is important. I'll open an issue on this later today. You can close this action item and open another one about renaming the IESG Note. o Warren Kumari to follow up on a bis document for RFC 8126 regarding designated experts. Warren: We spoke about this a little bit on the last call and I think Murray and I are supposed to be working on this together, but I think it's actually Barry. I'll follow up with both Barry and Murray. In progress. o Rob Wilton to draft a proposal to the tools team for what the requested information regarding mail statistics should look like. Rob: This is in progress. o Lars Eggert to send email to the LLC about Letters of Invitation for Interim Meetings and Retreats - On hold until after 2023 retreat 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-sfc-ioam-nsh-11 - IETF stream Network Service Header (NSH) Encapsulation for In-situ OAM (IOAM) Data (Proposed Standard) Token: Andrew Alston Amy: I have a number of Discusses; do we need to discuss those today? Andrew: I don't think there's anything I need to talk about on the Discusses themselves but I do have a question for the IESG about this document. There's one more document that's in Last Call for SFC and then we were going to close SFC. I've been warned by the shepherd that I may never get responses to these Discusses and that would leave this document open. What do I do in the case of a WG that was going to close when I have a document with Discusses that the authors may never respond to? Roman: I've encountered this situation to do one of two things. You work with the chairs to ask if the WG still cares about this document and wants to add more authors, or you flush it and close the WG. In the end, the document is the product of the WG, not the authors. If the authors aren't doing it, there needs to be someone else in the WG to close it. Warren: You can close the WG with live documents still if you want to. If you think the document is moving along and the WG doesn't need to remain open, or if it's not moving along and you don't think the WG needs to remain open, you could just close it and hold the document. John: The only reason you'd need the WG is if you need to return the document to the WG, and at that point you do what the others said. Zahed: the other reason you might need a WG is for auth-48, if you find something that needs some sort of consensus call in the WG. For RMCAT I waited until the auth-48 was done on the last document before I closed it. Roman: I'm with Zahed. You're going to be AD sponsoring that document if you close the WG. Andrew: One of the things the chairs suggested to me was that if the other document that's in Last Call at the moment goes through the IESG and they haven't responded, then I always have the option of kicking the document back to the WG and when stuff moves to RTGWG for maintenance they can fix it there and it just goes through the process again. So that's another option. I just wanted to hear some other thoughts on this. Rob: How difficult are the Discusses on here? I think people wanted clarifications but I don't remember how many changes people were asking for. Andrew: I don't think there is anything massive in here, but the authors still have to respond to those Discusses. Éric V: Frank is a colleague and he's still at Cisco. I think he will react. Andrew: Okay. I was just warned by the shepherd and the WG chairs that he might be slow to react. Other than that, I'm working on these Discusses and I've chased the shepherd. This will definitely need a Revised I-D. Amy: Okay, this will stay in IESG Evaluation, Revised I-D Needed. 2.1.2 Returning items NONE 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 NONE 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 NONE 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 NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval o Multiplexed Application Substrate over QUIC Encryption (masque) Amy: I have no blocks for this recharter, so unless there's an objection this recharter is approved. Éric V: I would still suggest that my comment is addressed, though. Martin: I'll make sure. Amy: Is this good to go or is it waiting for anything? Martin: No, it's not waiting for anything. Amy: Excellent, then we'll send our recharter announcement. 5. IAB news we can use Roman: I had a dayjob conflict so I don't have any. Mirja: Yesterday we had a technical discussion about fragmentation. We decided to announce it on the arch-discuss list for the first time and there was a lot of interest and a bunch of observers joined. So let's see what will happen there. Martin: Packet fragmentation or Internet fragmentation? Mirja: That was the initial question on the mailing list. No, it's not packet fragmentation. Roman: This was news to me, for example, that the IAB was doing this and it was being shared for the first time. It looked like the community was responding like what's this new thing, why aren't you including us, while this has beet he usual business of the IAB for quite some time now so there was a mismatch of expectations and not an understanding that this was something that had been happening in the IAB for quite some time. Mirja: Exactly. We did announce this a couple of times in IAB-Open but it didn't make the news. Our calls are always public, we just didn't send out an announcement before. We just did it for the technical discussion because people said that would be interesting but they weren't aware of it. Two things came together, one was the unawareness of the community about this and one was also this topic which people have opinions on. 6. Management issues 6.1 [IANA #1271795] Alert URN Identifier registration request (IANA) Amy: This is a registration request that there is no expert for, so they're looking to the IESG to approve or not. Sabrina: It sounds like they are still working on finding experts for this registry and we checked in about this request since it's been pending since February 17. This is a low volume registry so we were hoping the IESG could approve this while we're still waiting for experts to be designated, if that's appropriate. Éric V: It's not my patch but I don't see why not. Andrew: I don't have a problem with it but it's not my patch at all. Roman: I don't see an issue with it either. Amy: Okay, I'm hearing no objection to going forward and approving this request while we wait for designated experts. Okay, we'll send an official note to IANA stating that. Éric V: The only thing is that I see 3GPP on the last line; should we check with 3GPP whether there's a conflict? Andrew: Didn't this request come from 3GPP? Look at the top of the request. Sabrina: Yes, this was submitted by 3GPP. Éric V: Oh, okay. That's fine then. Thank you. 6.2 Normative changes to documents in RFCEDIT state with RFC Editor (Andrew Alston) Andrew: I've asked the RFC Editor to hold this document pending the outcome here. Basically there's a document, RFC 7752bis, and it has certain restrictions in the document. The guys in LSVR suddenly realized they couldn't do what they were doing because of these restrictions. They asked for a change to 7752bis which is in RFC Editor state at the moment. It's a normative change, because effectively the document says you should ignore certain things. But you can't ignore them and have LSVR still work. I can tell them to write a one page document which would sort this out or I can ask IDR to approve this, and if I get unanimous agreement, we can make the change while it's still in the editor state. I'm not quite sure what to do here so I wanted to ask for some advice. Rob: I think it depends on the size of the changes. It's really just a judgment call whether the IETF consensus would have changed on the balance of that change. If they think it might have done, you need to push it back to the WG. If the change is relatively small and sensible, either just ask the WG, give them a week to consider the changes, and as long as nobody objects then go forward. If you think the change is sensible. Éric V: Is it a change from informative to normative or normative to informative? Andrew: In this case it changes something pretty specific in the document. It's a really short change but the document explicitly says that you need to ignore certain SAFIs, and this would change that. Because it actually brings processing the SAFI into it. Jim: From the LSVR perspective, the issue that was caught was that I've been reviewing some documents and this immediately stood out to me. I spoke to one of the chairs and that's where the objection came from. Essentially in BGPLS they use an attribute that there's a one line in the RFC that says this attribute should not be used by any other address family. Which is problematic because LSVR is a different SAFI, but it's closely related to BGPLS because it's all about link state. When that line in the RFC was put into place, there was no other address family that was related with BGPLS in terms of link state. Now there is, and there's a specific line in the RFC that says we can't do what we want to do. Hence the issue. Andrew: I just pasted the text into the chat. Warren: This seems very similar to what happened recently with the ESNI and [crosstalk] where we said this is already in the RFC Editor queue, we want to make this change, dear WG does anybody strongly object? Then I did a fairly short IETF Last Call saying we found this issue, this is what we're going to do to fix it. Yes, it did add three weeks of time, but it wasn't a major faffle. Andrew: That's what I wanted to check, Warren. Is it simply a case of me asking the WG or do I need to issue another Last Call? Warren: I think the way I did it, we actually had an IETF Last Call but I don't think it was needed. Éric V: In this specific case, ESNI and the same thing in ADD is quite touchy, very sensitive. So we wanted to play by the rules. I'm not sure whether this thing in LSVR is very sensitive. Jim: This particular one, if you look at the text Andrew put into the chat, the second sentence said the attribute should only be included with link state and LRIs. That sentence is okay because LSVR uses the same link state and LRIs as BGPLS. It's the next sentence that's the problem because it says it must be ignored for all other address families. LSVR uses a different sAFI than BGPLS so the change is pretty simple, it should say something like it must be ignored for all other non-link state address families, or something like that. It's a pretty straightforward change. Andrew: I'm reluctant to make that change because at the same time I'm not 100% convinced that the IDR working group is necessarily going to support what they're trying to do in LSVR. That is what kind of worries me. Warren: I think send an email saying this is what we want to change, this is why we want to change it, assuming there are no objections, please let me know in 1 or 2 weeks. If anybody is really uptight about it they've had their opportunity to comment. Maybe this is a covering your ass kind of strategy. Even if you think people aren't likely to object, give them a chance to. Andrew: If they object, do I then take the document and send it back to the WG? Warren: If they object, I think send it back to the WG saying that we already had WGLC, IETF LC, the only bit we're discussing is this, please do not reopen discussions on other things. Andrew: Okay, I can do that. I'll ask for objections in IDR then and Jim, you and I can talk about it after this call. I don't think I'll issue another Last Call; if I get unanimous from IDR I think it's okay. Jim: You should probably copy LSVR as well. Warren: I think you can also make it clear which way you think it goes, and that you're doing this for transparency to make sure everybody gets a chance to see it. The way you frame the question is important. And also reiterate that this has already gone through the process and was already with the RFC Editor so now is not the time to re-open any other discussions. Andrew: That makes sense, thank you for the advice. I was hesitant to make a change that while small, could potentially have impact. Zahed: I think this approach is good, I've done this a few times with QUIC and I delegate the consensus call to the chairs too. Andrew: Thanks very much, I've got what I need. 6.3 SWOT/PEST Analysis (Éric Vyncke) Éric V: We need to combine the results. We have nine answers including myself and Rob, but we're still missing six or seven. Andrew: I thought it said 10 am tomorrow morning UTC? Éric V: 8 am UTC tomorrow we'll meet to compile results so that's the latest. Put aside half an hour and think about your responses. 7. Any Other Business (WG News, New Proposals, etc.) Warren: I finally put in the conflict review for the draft I did; I can't remember if there's anything I need to do other than put in the conflict review text in order to make the next bits happen. Amy: I think you have to open a ballot for it and then it will go on a telechat. Warren: I'm going to click the button to put it in IESG Evaluation and see what happens. Amy: Yes, I see that it has opened a ballot, so it will go on the next telechat. Thanks everyone, a couple of reminders; the BOF coordination call doodle poll is out so please fill it out. Please also send Cindy your unexpected facts about yourself for a retreat activity.