INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2022-07-14 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 Martin Duke (Google) / Transport Area Lars Eggert (NetApp) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Erik Kline (Aalyria Technologies) / Internet 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 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 Qin Wu (Huawei) / IAB Liaison REGRETS --------------------------------- Andrew Alston (Liquid Intelligent Technologies) / Routing Area Jay Daley / IETF Executive Director Roman Danyliw (CERT/SEI) / Security Area OBSERVERS --------------------------------- Andrew Campling Charles Eckel David Lawrence Ben Schwartz Lee-Berkeley Shaw Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything new to add to today's agenda? Lars: I want to add a management item on discussing the WG side meetings that have popped up during 114. There was a slack discussion earlier about some things in the side meeting wiki that looked like WG meetings. If we have time, let's see. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes of the June 30 teleconference being approved? I'm hearing no objection, so those are approved. I saw final narrative minutes earlier this week; is there any objection to approving the narrative minutes from June 30? I'm hearing no objection, so those are also approved. 1.4 List of remaining action items from last telechat o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn) [IANA #1229681]. Amy: Roman is not here today. o Murray Kucherawy to find designated experts for RFC 9248 (Interoperability Profile for Relay User Equipment) [IANA #1232225]. Murray: I have one. Do we do that right now or at the end? Amy: We do that as a management item. If you want to give us the name in Slack we can add it. o Francesca Palombini to find designated experts for RFC 9246 (URI Signing for Content Delivery Network Interconnection (CDNI))[IANA #1232482] Amy: This is on the agenda later as a management item to approve an expert. o Warren Kumari to find designated experts for RFC-ietf-dnsop-svcb- https (Service binding and parameter specification via the DNS) [IANA #1232944]. Amy: This is a brand new action item for Warren. Lars: The ones that are already on the agenda as management items to approve, can we drop them from this list? Those take about thirty seconds. Amy: Sure. That would have been only one of these four because Murray hadn't told us we had one. But sure, we can take those off the list in the future. * OPEN ACTION ITEMS o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to the IESG on the impact of COVID-19 to the IETF in July 2022. Amy: We have a management item on this one. o Lars Eggert to facilitate an update of the document shepherd writeup form. Lars: Done. o Lars Eggert to ask the Tools Team to push the global whitelist out to WG mailing lists again. Lars: That ended up with Cindy. I think it's almost done; there are a few lists that we are waiting to hear if they can be closed. Cindy: The WG lists all have it; it's the non-WG groups that are still in process. This action item was for the WG lists only so it's done. Paul: And based on the emails I sent out this week with my Discusses, it's worked. o Murray Kucherawy to draft text for an IESG statement providing guidance about patch documents. Murray: I owe some replies; this is in progress. Amy: The action item was just for you to draft the text. Murray: Okay, then it's done. o Lars Eggert to follow-up on the management of the IETF non-wg mailing lists. Cindy: This is still open. o Lars Eggert to draft email about RFC8989 Path 1 for NomCom eligibility. Amy: I've seen a lot of email on this. Lars: It's drafted and sent; done. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-uta-rfc7525bis-09 - IETF stream Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) (Best Current Practice) Token: Francesca Palombini Amy: I have a Discuss here; do we need to discuss that today? Francesca: I don't think so. I haven't seen answers from the authors yet to Rob's Discuss but I've seen a lot of back and forth for other ADs' reviews and on the SECDIR review as well. Rob, I don't know if you want to add anything. Rob: One bit of text concerns me which is about saying if a TLS channel is available, you must use that. It seems like you're saying all traffic must be encrypted if there's a TLS channel available. I'm wondering if that was the intention. I can imagine certain cases maybe within a datacenter or something where they choose not to encrypt the traffic. Paul: I interpreted that differently. I interpreted that like if you have star TLS on the SMTP port you must use TLS there, because by now the time is over to do plain text. Rob: I was only reviewing the diff so maybe there's some context about it I missed. It seemed broader than that and said if there's a TLS channel you have to use it. Francesca: Is this point 3 in your Discuss? Rob: Yes. Francesca: I would wait for the authors' reply on this if you're okay with that. Thanks everybody for the review. Rob: Okay. Amy: So it sounds kind of like this is going to need a revision, is that right? Francesca: Most likely. It's not going anywhere for now. Amy: Okay, this will stay in IESG Evaluation, Revised ID Needed. o draft-ietf-ippm-rfc8889bis-02 - IETF stream Multipoint Alternate-Marking Clustered Method (Proposed Standard) Token: Martin Duke Amy: I have a number of Discusses in the tracker; do we need to discuss any of these today? Martin: A lot of this makes sense. Some of the Discusses are pretty simple and some are deeper. Do people think this document is fixable in a finite amount of time or do we need to discuss alternate ideas? John: Does it really need to be PS or can it be informational? It seemed like a bunch of the Discusses hinged on that. Martin: The reason we started on this great journey was because Erik K had a document that normatively referenced 8321 and 8889 which are experimental. So we said, we're going to make this PS and the WG said it was ready. I tried to do that and then the last call list went bananas. Then the wg didn't want it so I AD sponsored it for a while and read it like six times, and I realized there were a lot of problems so I fixed a lot of the problems, and then I forced the wg to take a look at it, and here we are. In retrospect this was way more work and it would have been way easier to just put something in the downref registry, so that's a lesson. If there's a finite amount of work and Giuseppe is willing to do it, that's fine. I think informational would be a little silly given that the original is experimental and worse. If people would feel better about this as experimental and doing the downref, that's fine. If we want to throw this in the ocean of 8889 being the last word, I don't have a huge emotional attachment to this document although I think the original documents were worse and I don't know how they made it through the IESG. But I'm open to that. Giuseppe is pretty responsive and seems to be willing to do the work here but if a few text changes aren't going to cut it we should talk about alternatives. Lars: Both of these docs, this and the other one, feel like they haven't progressed from experimental to proposed standard. They have way too many options and it's unclear what is the actual specification you're supposed to do. They read like a research paper, which isn't surprising because they also cite a lot of research papers. I'd feel more comfortable if they stayed experimental and we did a one time downref because it feels like this stuff is not quite there for proposed standard. Martin: That's fair. Because of the AD sponsoring I've looked at this more than usual. Ultimately there are only so many cycles you can go through that. Alvaro: There are a couple of docs in bier that depend on this. The problem I had with the original docs that were experimental is that explicitly in the shepherd writeup and somewhere else it said this document is not ready for primetime and the bier docs are standards. To me, putting a standard in the downref that explicitly is not ready for anything is not the right thing to do. It's the easy administrative thing, but it's just not the right thing to do if we're going to standardize the use of this in something else. Lars: Is this a mandatory to implement part of bier? Or is it an optional part of bier? Alvaro: For that specification, yes, it was mandatory. This doesn't actually specify a protocol, it specifies a mechanism. In bier they said we can use this mechanism to monitor the bier streams. It was mandatory to implement there for the monitoring of the streams. At the time years ago I asked ippm if they were still not ready and eventually it came through again with Martin. Bier is not my wg anymore but they'll probably come around with that proposal again and I don't think a downref is enough. Unless ippm says this is ready to be deployed which then begs the question why arent we making it a standard. But I guess the argument right now is that it's not ready for anything beyond experimental. Martin: As Alvaro said this is a mechanism. The intent of components and other fellow travelers is to have a gazillion implementations of this for all the various encapsulations. At the heart of it this is a mechanism that I don't think it's poorly designed, but it's not particularly well written. John: It's not poorly designed but as far as I can tell, as an implementer I could not sit down with that and write an implementation. I could have a philosophical discussion between myself and the document about how I feel about implementing it. Which I took to be the essence of Lars's Discuss. Martin: I see where you're coming from. I don't know. I wonder is it best to have half the IESG iterate with Giuseppe to try to clear these issues or do we need to take this back? John: I sort of reviewed them backwards because Erik had been beating the bushes to try and get ballots on the v6 draft, so I went and reviewed that, which is basically an instantiation of 8321. When I started reviewing the 8321 bis I thought okay this is an architecture document that's supposed to be referenced by instantiations that provide all the details. That was the curve I was grading on . I think it's okay in that context as long as the instantiations then provide sufficient detail to implement it without having to have a philosophical discussion. Martin: My question would be to Lars and others who share his assessment. In your review you'd identified a few things that have this ambiguity and when Giuseppe fixes them they'll be fixed, or will it be an endless bring me a rock thing to solve all of these problems where we need to go do some surgery? Lars: It's hard to say without seeing a revision but if this was an academic application I'd say major revision needed. The mechanism might be sound but the way it's described, I think the authors have rewritten the text for so long they can't see the forest for the trees anymore. They would really benefit from rewriting it, just the piece that's actually supposed to be standardized. It's a tall ask. Erik: In the 6man case, there were 3 issues with the 6man document. The 6man document was just a document about here's an option to hold some information and this other RFC tells you what to do with the information. People got kind of uppity about 3 different classifications of things. One was to get an option in the registry you needed to have a PS or something better than experimental, so update 8321; then there was a honking discussion about these things leaking outside of controlled domains; the third thing was that there's not enough information in the document to tell me how to implement it. I thought that was absurd at the time because it's just an option with a bunch of bytes and it points to other documents that tell you how to implement it. From an IPv6 perspective we had enough information to implement it because you just put the bytes there. Martin: I found the leaking thing a little mystifying. Typically this is an encapsulation. I haven't read your document but I assume that's what it is. One question is if that's a safe network you're running on, but if your encapsulation doesn't terminate reliably to a decapsulation you're in a world of hurt. That seems fundamental. Erik: It's not an IP encaptor or something but it was defined to be an IPv6 option. Martin: That has to be done end to end, right? You have to do an encapsulation? Erik K: It had a destination only option mode. John: If I remember right, resolving my Discuss got them to stick some text in there that said you've got to have it in an overlay network with an encapsulation. Or at least it's in there with a SHOULD. I think up until recently it did not say that. Martin: These documents I think it leaves open quic version 3 will have these bits for networks to play with, which was not going to happen, but they leave open the possibility of actually touching the user header. In general I think we think encapsulation is going to be the vehicle for this to happen, whether it's IP or something else. All right. I guess what I'm getting in terms of moving forward is that we should probably work through the Discusses but at the end of the day after a reasonable amount of editorial rounds Lars's Discuss will stand that we need to clean up the ambiguity, and that is the concrete work action where I'm going to have to go back with the authors and do a couple more editorial passes. Does that seem like the right path to people? I'm seeing nods. So this is Revised ID Needed, and so is 8321bis as they're very similar. We can move on to the one after that. o draft-ietf-ippm-rfc8321bis-02 - IETF stream Alternate-Marking Method (Proposed Standard) Token: Martin Duke Marking this Revised ID Needed along with the above 8889bis document. o draft-ietf-add-ddr-08 - IETF stream Discovery of Designated Resolvers (Proposed Standard) Token: Éric Vyncke Amy: I have a couple of Discusses in the tracker; do we need to discuss either of those today? Éric V: Most probably. By the way, I gave the IESG four or five days to review these; thank you for your review and I really appreciate this. The intent is to keep this cluster of three together. On this specific one, Lars, it's okay for the IANA. Paul, we can talk about the DDR and the DNR. As briefly discussed over slack, I understand that you don't like the ADD wg for whatever reason. I'm a little bit concerned that you will be blocking those two i-ds forever. A couple of those points you put into your Discuss are valid. One I should have spotted, so that's my bad. DDR and DNR do not fail in the same way. Why not using a resolver.local rather than a resolver.arpa? That's a good question because it's an issue of the forwarders and the reliance on the arpa zone. Many of these in your Discuss, I really wonder if they are Discuss points. Sorry to be direct. I don't know how to resolve all of this. We have the shepherd in the call too, thank you Andrew. I don't know how to proceed, to be honest. Paul: I'll need to think about some of that as well. It's not that I dislike the ADD wg. I think the reality of people wanting to use the local resolver is a lost cause and it's not happening. People join so many networks that it's not realistic for them to give the DNS queries to the local network anymore. ITs coffee shops or malls or whatever. And people seem to be building more of a trust relationship with a few trustworthy parties like Mozilla or Google DNS or whatever. In that sense I feel this work isn't going anywhere, because that's just not what is in the interest of the end user. But that's fine. That's no reason to block people who want to use this to deploy. There's also no reason for those who do use the local network unencrypted to bump them to DNS encrypted. As long as this is not visible to the user in any way so the user does not make any different decision because they think my DNS packets are encrypted so now it's all safe. It's not, it's still going to a random coffee shop that's local to you. So in that sense I think don't worry too much about the overarching question I put in, I just wanted to share those views. There are some more discuss items that I would like to see resolved just to make the protocol work as the wg intends it to work. Éric V: Okay. A couple of your Discuss points were really valid points and I fully support those. So I suggest maybe that all the text that you say why you don't like the protocol, move it from a discuss into a comment, and keep your Discuss points. That's usually the procedure. Paul: Sure, I can do that. That's fine. Éric V: Thank you. So obviously, Revised ID Needed on this one. o draft-ietf-add-dnr-11 - IETF stream DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR) (Proposed Standard) Token: Éric Vyncke Amy: I have a number of Discusses; do we need to discuss any of those today? Éric V: Just quickly again, thank you for the reviews in four days. Erik, Martin, Rob, I see the author has replied to your concerns but today is Bastille Day in France so Mohammed is not working. Same comment about Paul's; a couple comments I fully support and a few of them I think are not really Discuss level. Maybe that's my mistake to not see which are comments and which are Discusses? Sorry to pick on you, Paul. Revised ID Needed, clearly. Paul: I'll look it over again to see what are comments and what are Discusses. Éric V: I see as well Andrew Campling was the document shepherd for both of these documents. Andrew, if you want to say anything, you can unmute yourself. Andrew Campling: No, I can pick up with the authors as well. As you said, Éric, Revised IDs are needed anyway to resolve the outstanding items. I think the authors have been pretty quick thus far to turn them around so if we maintain that pace everything will catch up easily. Warren: As a quick note, I balloted Discuss on one of the documents and the authors replied almost immediately with a very kind helpful thing and I felt bad because my Discuss was not written as politely as it could have been. Amy: So it sounds like this one will also get a Revised ID and we can move on. o draft-ietf-add-svcb-dns-06 - IETF stream Service Binding Mapping for DNS Servers (Proposed Standard) Token: Éric Vyncke Amy: I have a Discuss; do we need to discuss that? Éric V: Just quickly as a reminder to Warren to fix the SVCB designated expert, because IANA is blocking this based on waiting for an SVCB expert. As I said these three will all be bundled together. Warren: I'll do it. Lars: For my Discusses I'll clear as soon as Sabrina tells me I can. Éric V: Revised ID Needed. By the way the author Ben is on the call, if you want to say anything? Ben Schwartz: I don't have anything specific to add but I'm happy to answer any questions about this. Warren: Ben, would you be willing to be one of the designated experts for this? Ben Schwartz: That would be great. Warren: Great. David Lawrence, would you be willing to be one of the designated experts for this? David Lawrence: I am all about [it]. Warren: Awesome, there we go. I have found you your designated experts. Amy: We will put this as a management item so the entire IESG can approve them. And this document will go into Revised ID 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 o draft-ietf-shmoo-hackathon-07 - IETF stream Running an IETF Hackathon (Informational) Token: Lars Eggert Amy: I have no Discusses, so unless there's an objection it looks like this document is approved. Lars: It's approved but it needs a new revision. I think Charles has some PRs he wants to merge. Right, Charles? Charles Eckel: Yes, I do have several pull requests out there. One question for the group; in some cases, I didn't respond inline to the comments but instead I just submitted a pull request that if you look at the diff, it's pretty clear how I was resolving each of the comments. Then afterwards I thought oh, that may not be appropriate or if it's better to not use github and a pull request that way in order to address feedback which I thought about after the fact. Then I started putting more detailed comments within my feedback in the pull requests. I was just wondering if there is a preference here or does it matter? Lars: I guess it depends on the individual AD. I would say if somebody feels like their comments require an email reply they will probably nag you about it. Do what you think works best for you, and if someone wants you to do something else, they'll tell you. John: If the PR speaks for itself, that's fine. Lars: We haven't figured out how the github-IESG loop works yet. But thanks for that. We're going revised ID needed. Charles: The only thing I did not respond to yet was Murray, I didn't see your review until today and you'd mentioned perhaps this wasn't necessarily dead on as to the shmoo charter. I think that is true and this document had been something that was sitting in the background before the pandemic, and then the pandemic hit and we had to make a lot of changes to the hackathon and even questioned if it's worthwhile to have a hackathon if we're not in person? It was because of that I brought it to shmoo and then I asked the wg that I know it's not specifically in charter but there are aspects of online only meetings that are discussed in the document and changes we had to make because of that so the wg was up for working on it with me. That's the history of how it ended up in shmoo even though it's not really specifically targeting one of the milestones. Mirja: We recently rechartered and there was a point in the previous charter on tooling and I think the discussion was that we could cover it at that point, but we removed that point now. That shouldn't stop this document. Lars: We did remove it because it was already in WGLC. Murray: The reason I raised it was because we obstructed another document in I can't remember which wg because it was clearly not in the charter of that wg. If we were to do it over there we technically should be careful about doing it here too. It seems like this slid through and I'm worried about the optics of us doing it in some places and not in others. That's why I raised the point. The other one has to do with crypto and this is more of a BCP about our own stuff, so I didn't take a stronger position, but I do think we should be careful. Lars: That's a fair point. I shouldn't have rechartered it and dropped that work item while it was still not completely done. My bad. Okay this will be Revised ID Needed. 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 o Transfer dIGital cREdentialS Securely (tigress) Amy: I have no blocks on the charter, so do we approve the tigress wg? Is there any objection? Lars: I think Roman wants to make some of the changes I suggested. I guess we should let him make those changes. Amy: Sure, it can be approved pending edits. I have chairs, and I have an email list, so it looks like it's ready to go otherwise. Lars: The email list will change to the tigress list with the chartering. I asked Roman about it and he said they're not going to keep using the secret list. Do you have that on your radar? Amy: I didn't. Changing an email list in the datatracker is easy. Cindy: You actually have to create the list first, though. Francesca: And I assume we would want to subscribe everyone who's subscribed to secret to the new list as well, right? Amy: We'll need to get all those details worked out with Roman. The wg can be chartered with the old list and then change the list later or it can happen at the same time. It's up to Roman. It seemed like he was real urgent to get this chartered before 114. Lars: I think he'll basically make some minor changes whenever he has time and then decide what he wants to do with the mailing list. I think he still has enough runway to do it before 114. Amy: It looks like this is approved and we will send the announcement after Roman okays the edits he wants to make. 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval NONE 5. IAB news we can use Warren: I missed the call this week. Mirja: There was no call this week. Warren: There was some interesting discussion the week before on the IETF 114 BoFs, including the IAB coverage for a number of the BoFs. The RFI on the IAB response to the OSTP thing on advancing privacy enhancing technologies, which I think everyone has seen, and some interesting discussion on the workshop planning for measuring the in network support for troubleshooting and security which got renamed to something I can no longer remember. There was also a conflict of interest update where Wes Hardaker is going to be appointed as the RSSAC representative to the ICANN board and there will be some overlap with his IAB position which he will handle as one would expect a sane and ethical person to do. Mirja: The workshop was renamed to Management Technologies and Encrypted Networks. I think Lars sent the latest call to the IESG list; the call is out and if you want to participate in the workshop, please send us a contribution. There is a second workshop coming up on sustainability so that probably goes out the week of the IETF meeting or right after. 6. Management issues 6.1 [IANA #1232944] Designated experts for RFC-ietf-dnsop-svcb-https (Service binding and parameter specification via the DNS) (IANA) Amy: This item was for Warren to find these experts, which he has done during the call. Is there any objection to approving Ben Schwartz and David Lawrence as those experts? I'm hearing no objection, so they are approved and we'll send the official note to IANA. Thank you very much. 6.2 [IANA #1232482] Designated experts for RFC 9246 (URI Signing for Content Delivery Network Interconnection (CDNI)) (Francesca Palombini) Amy: Francesca has identified Phil Sorber as the designated expert for these registries. Is there any objection to naming Phil as the expert? I'm hearing no objection, so it looks like this is approved and we'll send the official note to IANA. 6.3 Suggested IETF 114 Sessions for Getting Familiar with New Topics (Greg Wood) Greg: Thanks to everyone who has provided input so far. I've just reviewed the document and made a few more tweaks and accepted all the suggestions that people have made already. More eyeballs on it as a last take to make sure nothing is missing would be great. I'll drop a link to the IESG shortly. Amy: As a note, the preliminary agendas for the WG sessions at 114 were due yesterday and there aren't many in the Datatracker. You might want to lean on your chairs a little bit. I know some of you were waiting for agendas to know if you should put something in the document for Greg. 6.4 [IANA #1233341] renewing early allocations for draft-ietf-idr-segment-routing-te-policy (IANA) Amy: It looks like this early allocation request will expire at the end of August without an extension. Alvaro, this is one of yours; do you want to say anything about it? Alvaro: This document is already in my publication queue so it has already been through WGLC, which means there are implementations, so we should definitely approve the extension. Amy: Thanks Alvaro. Any objection to approving this extension? I'm hearing no objections, so it looks like we have approved this extension of this early allocation and we will send that official note to IANA. 6.5 Impact of COVID 19 on the IETF - IETF Monthly Activity Report (Alvaro Retana, Warren Kumari, Rob Wilton) Alvaro: Thanks Amy. You're doing all the work here. Warren: It is actually somewhat worrying, the results. Mirja: The drafts are back to normal, just mails are down; which I think is a good thing. Alvaro: it looks like the -00 drafts are still kind of low. They're a little higher right before this IETF. We've only had one meeting sort of back, and it wasn't even half in person, so it's probably too early to say that the effect has passed. Or that our theory of everything being down was because we were all online. Ideally this will look better next time. Warren: The bit that's more concerning to me than emails is the -00 drafts. It's noticeably lower over time than before. Yes, covid, but we've had a bunch of covid and one in person and it is still quite a lot lower than previous years, including last year. Rob: The number of bofs that we have has gone up so that's an encouraging sign. People have been potentially waiting to get things started. The other thing I looked at was the figures for the number of people who have signed up for 114, [which] looks like it's still roughly 50/50 between in person and online. Maybe slightly higher in person. It's nothing like back to anything before. I know some key people in some wgs are just staying away at the moment and I'm not sure how long that's going to take to resolve. Mirja: Maybe it would also make sense to dig a little deeper into the numbers. I'd be interested in the ratio of new -00 drafts that actually went into the process and got a wg document -- is that down as well? Or is it just the 'useless' -00 drafts? Not that they're completely useless, but that they don't get adopted? Rob: We can look at that. That would be interesting to know, to split those in terms of where they've gone. I don't know if that changes anything even if we had more data, that data doesn't change the outcome. That's the thing we need to be concerned about, should we be trying to take steps to change this or should we just wait another few meetings and hope it picks up? Mirja: The obvious conclusion from this data is that there is an impact from the pandemic, but I'm not sure if this is the only impact. That's why I asked this question. There might be more reasons there were more drafts at certain points and less drafts at others. Lars: There might also be a reason that we have the shorter days and the same number of tracks, in the sense that wg time is squeezed and wgs typically prioritize chartered work. I think we need to have a discussion of having more time where people can present new work in working groups. Warren: That's a very good point. In addition to that, it feels as though there isn't as much time for people to interact with each other. We had a view that once people are meeting again in person there will be an upswell of new ideas as people bump into each other and chat, and at least for me at the last meeting, it didn't seem as though there were as many people bumping into each other and chatting. It seemed like panicking and running from one wg to another. That might have just been me. Longer cookie breaks or something? Not that designing a solution on the fly ever ends badly. Lars: This is maybe foreshadowing the discussion we're going to have later on side meetings but I think we're going to have to go back to a schedule that's more like a pre-covid schedule with longer days or we're going to have to add another track, for two reasons. I don't think there are any other options. If the wgs are not getting creative and people don't have time to present their ideas in the wg. 6.6 WG Side Meetings at IETF 114 (Lars Eggert) Amy: I think we can segue into this topic if you need to. Lars: Thanks Amy. I think we're seeing that the lingering effects of Covid are not over and one of the ways we are still trying to cater to the remote participants. It's a nice thing but it comes with downsides and this might be one of them. What do we want to do, if anything, about this co-opting of the side meetings by some wgs? Alvaro: It's perfectly fine for a chair to say hey, I booked a room at 5 on Thursday, if anyone wants to continue discussion. As an informal discussion just like bumping into each other in the hall or something, just that we're going to meet in that room. It's not an official meeting; I think that's the part that needs to be clarified. And that because it's not an official meeting it's not going to have Meetecho support and everything else. Mirja: I think we should talk to these two groups because we did say you can't have 2 slots but please have other meetings. I think what we meant is interim meetings later but maybe they misunderstood and thought they should have side meetings instead. We should clarify what happened there. Lars: Are both of these Roman's groups? Francesca: Both are, I think. Martin: I think this is the worst of all possible worlds. With no recordings, no Meetecho support, etc, that's far worse for remote participants than having additional tracks or a longer day with no ability to timeshift via a recording. I would really encourage either forcing them out of IETF week or retconning the whole one-meeting thing. Or something. But this is not good. Rob: To Alvaro's and Martin's points, if they get through half of their agenda in the official meeting and then push the rest to a side meeting, that becomes even worse. Rather than having a separate focus. Alvaro: Right, it depends on how they position it. If it's just a room for people to get together that's okay. If it's to continue the agenda there and make decisions and consensus and that stuff, that's snot good. John: Since they're both Roman's groups, have we talked this part of it to death and he should talk to his chairs to try to sort this out? If I remember the past conversation Roman was the most passionate about being completely consistent and fair if we're going to have just one meeting gper group. I trust him to sort this out. Lars: I'm fine with letting Roman deal with his working groups. I wonder though if we want to have a discussion at the plenary or somewhere else about what we should do going forward. All signals point to longer days. John: I've had several chairs grouse to me in various ways about having to fit themselves into a single slot and I'm sure most of you have too. Francesca: That's what I wanted to say. If we start deciding how many side meetings WGs can have, that's a slippery slope. I understand the point of it being a side meeting and not an interim or official wg meeting but also if people are there and in person and want to take a room and discuss things, we shouldn't be stopping them. That seems like stopping progress. John: To Lars's point, it's a signal from the community and they're voting with their feet. Francesca: We need more slots. That's roughly the outcome of this. Mirja: This discussion was supposed to be in scope for shmoo but it doesn't really happen. And I don't think we have a session anymore, do we? Lars: Shmoo canceled because nobody proposed any topics. Martin: Is shmoo chartered to do hybrid meeting stuff? Lars: I'm talking to the heads of shmoo to close the group because I don't see a lot of activity along with the chartered work items. And not having any requests now is another signal that maybe we ran out of energy there. But this is a decision we shouldnt necessarily leave up to shmoo. We need to talk about this ourselves. Éric V: Longer day or a Friday afternoon, right? Lars: Friday afternoon isn't going to give us enough time. I Think it needs to be longer days or another track. Or both. Mirja: We need some community input on this somehow. Francesca: I would like us to have a common message to our chairs. I, like Roman, have also told my chairs we're not doing more than one session because we don't have enough slots, but you're welcome to request side meetings or do interims. The fact is that interims do not replace IETF week meetings completely because participation is much lower, you get much less people, you don't get the tourists or people who might get interested. It's not the same thing. If now we are also discouraging side meetings, which have the advantage of being in person so might potentially attract those people who might not call into interims, then we're missing out on more. Just so that we have the same message. John: I thought Alvaro's way of framing it was exactly right. Does anybody disagree with that? A side meeting is an opportunity to get in a room together and talk but be aware that it does not form any part of the formal agenda, not minuted, no remote. Francesca: It could be minuted if the chairs want. John: But it's not part of the proceedings. Lars: It's not part of the standards process. That is the key thing. 2026 doesn't talk about side meetings, it talks about bofs and wg sessions and mailing lists. That's where consensus is formed. Alvaro: The other thing I think Éric brought up on the list is that we only have so many slots for side meetings anyway so there are a lot of conflicts. Even if these were real interim meetings, we're too late, because it's already 2 weeks before the IETF and we didn't announce any of these. According to our process that's it -- we ran out of time and didn't announce the meetings on time for them to actually be meetings. Francesca: That sounds good. Having told our chairs you get one session but you can do side meetings or interims and then suddenly say but side meetings don't count… Mirja: The message about moving things to interims is not quite like continuing your session there. It's to figure out what you need to discuss at an in person meeting and where you get benefits there, and figure out what else you can discuss in an interim instead. Probably these items are not the same. Lars: Is anyone interested in writing a draft we could send to wg chairs that would clarify this? What side meetings are, how interims can be used most effectively, and what should go on the agenda? Mirja: There was a draft from Mark Nottingham about scheduling interim meetings, which also talked a little bit about how to use them most efficiently. For shmoo. Lars: We can put a reference to it in an email but I think we should send an email to wg chairs before 114, tomorrow or monday or something like that. So since Roman isn't on the call and he needs to tell something to his chairs anyway, maybe we suggest to him that he makes it general enough it can be an email we send to all wg chairs. I'll send him an email tomorrow. Erik K: Do we have any IESG statements on this? Alvaro: I don't remember if it was a statement but we did send a message 2 or 3 years ago about what the side meetings are. Mirja: I think we have a statement about how the note well applies to side meetings. That's all I remember. Erik: There are several guidelines on interim meetings. Lars: There's a link to one I just put in the slack that seems to say a lot of good things. Erik K: There is one from 2016 and one from 2020. Mirja: It does talk about interims and in person meetings but it doesn't talk about side meetings. Lars: It might have been an email to wg chairs. Éric V: Or simply on the wiki page where you schedule side meetings. Lars: I'll see if I can convince Roman to do this for us. The other thing I wanted to ask is if I should put a question into the plenary slide deck to seed the discussion at the open mic about this? This being more tracks or longer days or neither of the two. Or a combination. Or something else. Alvaro: We've been working on the assumption that because there are still going to be a lot of remote people we have the shorter days to accommodate. Making the decision for a longer day either assumes that it's too bad for the remote people or we hope there are going to be a lot more in person people. Lars: We could do another track but that increases conflicts across the board which people also hate. Mirja: It depends on the venue because usually we can't have more rooms. Lars: Exactly. Going parallel also means the meetings are probably going to be smaller. Sometimes we have some flexibility. I guess if the secretariat knows with enough leeway they can make arrangements. For London, if we told them we wanted to add a track they could probably see if we can make it work. Mirja: I don't think it's that easy because it's part of how we contracted the hotel. Amy: It's also not just the room space, it's the tech. The backup tech stuff, all the Meetecho deployed stuff, I don't know how many extras we have. Lars: So that means longer days is really the only option unless we find out that we have enough for another track. Mirja: We can remove the plenary and have wg sessions instead. Lars: Maybe this is an email to wg chairs or even ietf-announce saying we are considering creating more wg session time, and here are some of the options we see, let us know what you think. Some people will reply by email and others will line up at the microphone. Erik K: Is it really creating more session time or is it restoring to the previous set of session time? That's really what the change is, right Lars: Yes it would be restoring to the pre pandemic schedule. Mirja: This is not only a question for the chairs, but the whole community, right? Lars: Yes. Martin: I don't object to asking for community input but it's going to be mixed. Lars: But we'll get data and then we have to make a decision. Mirja: I'm wondering if there's a better way to get feedback. Maybe a survey? Lars: Should we tell Jay to stick it in the post meeting survey? It seems like with a fresh impression of Philadelphia people might have an opinion. Mirja: We could refine the questions there or we could go for a second survey because I think this is really important. Martin: I think the meeting survey is probably more likely to succeed than a bespoke survey people might miss an email for. I like the idea of grappling on with that. Mirja: The other crazy idea I have is that we could use the opened up shmoo spot and run a bof on that. Lars: There are conflicts. It's too conflicted. Greg, does Jay do the survey or is it you or both of you? Greg: Jay generally takes the lead but I've taken a note to follow up with him on this. Lars: Okay so let's see if we can circle back and add something in there. Martin: The choices would be status quo, longer day, or more tracks? Lars: Or fill in your suggestion here. We would need to explain that the extra track comes with issues that might make it more work than it appears. Like equipment and potentially not being able to do it at the venues we've contracted. Martin: I don't know if we need people to adjudicate that. If we get overwhelming feedback that we should add more tracks and we can't do it, we can't do it, and we do the best we can. The question is, what does the community want to do? I don't think we should muddy it with issues that are orthogonal to the attendee xperience. Lars: Fair point, but people who say they prefer more tracks need to understand there's a certain time delay until we can do it consistently because we've already contracted venues out into the next few years. If those venues can't support that we can't do the extra track. Equipment we can buy or ask for from sponsors but the venues are picked already. I'll put something into the Sunday IESG agenda because Jay is going to be there for that and we can have a discussion in the room. I'll also talk to Roman about mailing the chairs. 6.7 Designated experts for RFC 9248 (Interoperability Profile for Relay User Equipment) [IANA #1232225] (Murray Kucherawy) Amy: Murray has identified Brian Rosen as the designated expert for this registry. Is there any objection to approving Brian? I'm hearing no objection, so we will send that official note to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Lars: I'm using the 5 pm Monday slot for a side meeting on NomCom eligibility. Martin, if you haven't seen that email, you'll probably be interested. This is to find some common ground for the official session on this in gendispatch. There have been some proposals of what they should do and we're probably going to run out of time in gendispatch. Those of you who are interested, come to that.