Narrative Minutes interim-2023-iesg-02 2023-01-19 15:00
narrative-minutes-interim-2023-iesg-02-202301191500-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2023-01-19 15:00 | |
Title | Narrative Minutes interim-2023-iesg-02 2023-01-19 15:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2023-iesg-02-202301191500-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2023-01-19 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 Jay Daley / IETF Executive Director Roman Danyliw (CERT/SEI) / Security Area 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 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 Murray Kucherawy (Facebook) / Applications and Real-Time Area OBSERVERS --------------------------------- Greg Wood 1.2 Bash the agenda Amy: Does anyone want to add anything new to today's agenda? We have a new item about retreat planning; anything else new? Any other changes? 1.3 Approval of the minutes of past telechats Amy: Is there any objection to approving the minutes of the January 5 teleconference? I'm hearing no objection. I also saw final narrative minutes; any objection to approving those? I'm hearing no objection there either. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Francesca Palombini to find designated experts for RFC 8141 (Formal URN Namespaces, Informal URN Namespaces) [IANA #1263515] Amy: Francesca, this is a new item for you. I think they suggested someone. Francesca: Yes, I was trying to find the mail and I couldn't find it. Amy: We'll see if we can dig up an email address for you, or maybe IANA can. Sabrina: I can send it to you, Francesca. * 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 March 2023. - On hold o Lars Eggert, Warren Kumari, Éric Vyncke, and Rob Wilton to discuss whether to reconstruct the document approval announcements to be more meaningful. Warren: In progress. o Murray Kucherawy and Warren Kumari to coordinate with Barry Leiba and IANA about possibly updating text regarding IANA registries and expert review process detailed in RFC 8216. Warren: This is in progress. I chatted with Barry yesterday and he's planning on doing an update to BCP 26 anyway. We're thinking of something like "first come first served but with documentation very strongly suggested" or something like that. That's in progress and Barry is handling most of it. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-opsawg-sap-14 - IETF stream A YANG Network Model for Service Attachment Points (SAPs) (Proposed Standard) Token: Robert Wilton Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this document is approved. Rob: I think so. I'd like to thank everyone for their reviews. I haven't checked the last couple of comments that came in today so I think I'll just check those first. I did see there was an updated version yesterday. Amy: So it sounds like this will be Approved, Announcement to be Sent, AD Followup? Rob: Yes, thank you. o draft-ietf-acme-subdomains-06 - IETF stream Automated Certificate Management Environment (ACME) for Subdomains (Proposed Standard) Token: Roman Danyliw Amy: I have a Discuss in the tracker; do we need to discuss that today? Roman: No we don't. We'll let the authors provide a response. Thank you to everyone for their reviews, both for the Discuss and the comments. It'll need a Revised I-D for sure. Amy: This will stay in IESG Evaluation with a Revised I-D Needed. o draft-ietf-tcpm-rfc8312bis-14 - IETF stream CUBIC for Fast and Long-Distance Networks (Proposed Standard) Token: Martin Duke Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this document is approved. Martin: It looks pretty clean to me, just a couple of nits. I'm sure we can get those done without having to go through all the substates. Approved, Announcement to be Sent, please. Lars: There are two PRs coming, so this will need a revision. Martin: Okay. Can we still make it Approved, Announcement to be Sent since there are no substantive concerns? Roman: It's my understanding that in the Datatracker if you make the status Announcement to be Sent it will release the document to the RFC Editor. If there are PRs waiting on the document, don't we want to get those in before? Martin: Okay, Revised I-D Needed then and I can push the button when it's done. 2.1.2 Returning items o draft-ietf-ohai-ohttp-06 - IETF stream Oblivious HTTP (Proposed Standard) Token: Francesca Palombini Amy: I have a couple of Discusses here; do we need to discuss any of those today? Francesca: I've seen answers for most of them. Éric, do you want to talk about your Discuss about the charter? Éric V: I read your email and replied a few minutes ago. It was pretty clear and I remember discussion when we created the WG a couple of years ago that it was not going through any web server but only modified web servers. Right? Francesca: Right. Éric V: And now with the combination of the relay and the gateway, basically any web server can be reached and used through this. Which brings interesting security properties, and it violates the charter, I'm sorry. Francesca: The way I read it, and why I didn't have a problem with it, is that I see this relay resource and gateway resource as logical entity. They can be part of the server itself, so the gateway resource can be hosted on the server. If you look at the example as well, there is one proxy that holds the relay resource and then the actual server holds both the gateway resources and the target resource. I didn't read this as this has to be different intermediaries. Éric V: But it's nowhere in the document, and that's my problem. The consequence with this, the protocol is there so someone can put the gateway entity in any box over the internet, and then we can basically act as an open relay to everything. If you have any kind of attack going from the client to the relay, which is one party, to the gateway which is another party, to the server which is a third party, you can run whatever you want like a DOS attack. Francesca: Okay. Maybe we need to add more consideration about that. Éric V: It's really really important. That's one security aspect. The other one is that it really doesn't fit the charter, I'm sorry. Warren: The more I think about that, the more I think I agree with Éric. It seems like it needs a lot more discussion. As for the charter bit, I don't really know because I didn't check. Francesca: I hope the applicability statement in section 2.1 covered it. If it doesn't, then we probably need to add something about this. Éric V: The thing is that if we split, and I understand for writing a document and for writing software, they split the target server and the gateway resource in two when it should have been one, but it also means everyone now has the keys to do whatever they want which is the part I don't like. Francesca: I understand. Martin: What's the threat model here, that there's an under-secured relay? Éric V: A compromised client run through the relay and the gateway, which are different parties, going to the target server. Target server, the only thing it can do is run the IP address of the gateway. Martin: There's language in there about the two relays policing this, right? From clients? Éric V: Policing is one thing, but if it's a single attack…policing is only handling the DOS. A volume attack. What if it's a couple of low level attacks? Warren: Also, yes there's language in there, but is it helpful to me if I'm the person being attacked? If I'm running a web server and I keep getting annoying requests from one IP address, I can block that user. If I'm now getting a bunch of requests through a bunch of proxies, blocking the proxy presumably isn't going to end well for me because that's not targeted to the abuser. Martin: I see. Francesca: I hope that this has been written this way for simplification of the protocol, but that we can add text that will make it clear these are entities that are supposed to be together. I see you shaking your head, Éric. Éric V: Again, during the charter discussion, it has been very clear that this technique cannot be used on any normal web servers. It only works for a very dedicated one, and in this use case of the telemetry from Apple devices was started when Chris was still at Apple. But it's no more the case in this document. Erik K: Don't you need the DNS information for the target server? You need to know how to encrypt a message to the target server? Francesca: That's done by this gateway resource. Again, when I read this I read it as this is all still at the server and this is one additional layer that you have at the server. That's what you need for the server to support this HTTP protocol. Erik K: This seems exactly as I imagined from the charter. Warren: I think Éric was right, it was supposed to be used more for privacy preserving and reporting and data collection. Francesca: That should be hopefully clear in the applicability. Éric V: The thing is that indeed, the technique and the draft can be used for this very narrow use, but can be used for [something] much broader. That's where my problem is coming from. Warren: Saying something like here's a gun, don't use it for anything bad, doesn't actually stop people from using guns for bad things. Here we're handing people a potentially…we could solve almost all of the security issues on the internet by saying "don't do anything bad." Éric V: If I may, you want to put a limited domain on the application. Warren: I kind of agree with that. Francesca: Okay. I guess we can continue this by mail. I do hope there's a way we can fix the document in order to make it clear how it should work. Erik K: It's not clear to me that this does violate the charter. It seems to be the intended purpose. Éric V: They say one in the charter. The overall purpose is there; one intermediary. Here we have two of them. Francesca: These resources are not the same as full on intermediary or proxy. That's what I was trying to say in my email. Zahed: On the intermediary, I had a comment. It's not clear to me what the intermediaries are. There was some text in the charter about it. In my understanding this resource is a logical entity, not an intermediary that per se we understand. This is not clear from the text and I'm listening to Éric read it. It's not clear from the text they are a logical entity. Francesca: That we can make clearer in the text. Éric V: This is one part. The other part, if you look at the charter, you have broad applicability, which is important, limited domain. It's "limited by multiple factors, including the need for explicit server support of the protocol." which is no more the case. Francesca: If you consider that the target resource is what was originally the unmodified server, that by itself will not work if you don't have the equivalent of the gateway resource on the server. Zahed: You need to have the target, um, hosting the target resource, saying a particular URL or whatever it is that defines the resource criteria. if you don't have it, It's not there. You cannot, you're listening for it to get any kind of request. I'm split here. I understand what you are coming from Éric. I think I have my mental map here that I might have missed. Reading it again, I think that there should be a clear indication about your concerns. I think you have a valid concern about the actual clarification part, but if it is violating the charter, I'm not really sure, but obviously you need to work on it to clarify this, francesca. Francesca: I understand. Thank you everybody for the reviews. It's good that we can have a conversation. This will need a Revised I-D anyway. We'll continue this offline. Paul: One second. Another issue that came up in this document is pretty minor. The linkfest issue that every word is a link, and every link looks like an external link to outside the RFC document. And there is an author that says they will probably not fix it. Is this something that should be a concern to the IESG in general? Do we want all of our documents to come in like this in the future where every time people use "server" or "client" it links to a section in the RFC? I'd really hate for this document to set a precedent. Francesca: No, I definitely think it should be fixed. It's not easy to read as it is with all those links. For the record, as I said, I don't think this is a Discuss point but I think it needs to be fixed before publication. Warren: One of the criteria for a Discuss point is about the quality and readability of it. Some of it is also just the tone of the response of "No." Mirja: Warren, I think you're over-interpreting this. He said he wouldn't fix the tooling now, which I think is a reasonable response. What to do with this document is a different question. Warren: I didn't read it as 'wow, you've got a good point, I should make the tooling better,' I read it as 'no, go away, I know best.' I guess the tone is something I can just deal with. Mirja: I think you're really over-interpreting it. He just said he wouldn't fix it now. Paul: No, he said something like 'I anticipate making no changes.' so he definitely wants to push this through. Lars: I'd suggest the AD checks with them. Francesca: I will. Lars: Finally, hopefully, there's one last thing about the downref to 9180. I think that's the one Paul mentioned earlier that might be referenced by a bunch of stuff so we should add that to the downref registry. Francesca: Thank you for catching that. Lars: It's a script, it's not me. Francesca: Any objection to adding that to the downref registry? Amy: If you want to add something to that, we'll need to know that at approval. If the Datatracker didn't catch it, you'll have to call that out specifically at approval. Paul: There are two other documents in the queue with the same downref, so it'll be a race. Amy: Do you know if it was caught by the Datatracker in the other two documents? Because a one-off is one thing, but if this downref wasn't caught by three documents, that's something the Tools Team should know about. Paul: It's an IRTF document, so maybe that's why it wasn't caught. 9180. Warren: If the tooling isn't perfect now, maybe it's not worth too much time now, because weren't we talking about changing the downref process? Lars: That's been a longstanding issue. We're going to simplify downrefs [eventually]. In the meantime, the review I have runs a different set of code which finds some stuff the Datatracker doesn't. Even if we miss it this time, my script will flag it next time. We don't need to spend more time on this. Amy: Whichever document gets through first can call it out and then it will go on that registry, so it may be a moot issue by the time this document comes around to be approved. This document is going to stay in IESG Evaluation, Revised I-D Needed. 2.2 Individual submissions 2.2.1 New items o draft-gont-numeric-ids-sec-considerations-10 - IETF stream Security Considerations for Transient Numeric Identifiers Employed in Network Protocols (Best Current Practice) Token: Paul Wouters Amy: I have a couple of Discusses here; do we need to discuss any of those today? Paul: Yes, briefly. People are right, there was less consensus than I realized. I think most of this will be fixed if we change the document to Informational and also change the text so it doesn't look like everyone must do this before publishing an RFC. Would that fix most problems? Lars: I'm fine with the proposed text changes. Mirja is the person who knows updates best, can an informational document update a BCP? Mirja: There's nothing written down about it. I think there's an example for every kind of update out there. Alvaro: So if it updates 35whatever, what is the update? One of the problems I have with this document is that the update seems to be that now we would include considerations about identifiers in the security considerations. Paul: I think the update goes away if we make this informational. Then it's just saying you should do this stuff, it's good, but it doesn't really update 3521. Alvaro: Correct. In my case it would help, but I don't think it would solve my problems. I still think the document does not tell you much. It says sure, go ahead and do something, but it doesn't really tell you what. I'm Discussing mostly because if it's going to be a BCP, it needs to be very clear. If it's Informational I wouldn't care so much and I'd probably abstain or something. Paul: I think that this document is a little light on content is partially because this document was split into three after earlier discussions. So all the context from the larger document is missing from this document. I think you do have to see it in the sense of that cluster of three. Alvaro: And that's fine, but if the references to the other documents aren't clear enough, it's not clear if that's the example we should follow. But if it's Informational, my biggest concern, which is that it's not specific enough to be a BCP, goes away. Paul: I'll go back to the authors and see if we can fix this. Please put this in Revised I-D Needed. 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-opsec-indicators-of-compromise-03 - IETF stream Indicators of Compromise (IoCs) and Their Role in Attack Defence (Informational) Token: Warren Kumari Amy: I have a Discuss in the tracker; do we need to discuss that today? Warren: Quickly, while Éric is still on the call. I think he and the authors have something figured out. Once they address it with some IPv4/IPv6 stats, I think it was, he's happy. Just to confirm that? Éric V: Absolutely, where there are simply the statistics about the IPv4, the IPv6 are also available. That's all I want and it's so easy to do. Revised I-D and I'll put a Yes. Warren: Excellent. Thank you, everyone, for reading it in the way this was intended. Roman: Warren, I'd ask if you could have the authors take a look at some of the comments I had. I think the way they're framing things is a little bit subjective. That's fine, if it's citable or more explained. I think I was pretty detailed in pointing that out. Warren: I'll ask them to have a look and I think they'll be happy to do so. Amy: We'll put this in Revised I-D Needed and move on. 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-irtf-nwcrg-tetrys-00 IETF conflict review for draft-irtf-nwcrg-tetrys draft-irtf-nwcrg-tetrys-04 Tetrys, an On-the-Fly Network Coding Protocol (IRTF: Experimental) Token: Erik Kline Amy: There are no Discusses in the tracker, so it looks like this response is approved to go back to the IRSG. Erik K: Zahed asked me to add another WG to the list, can I just edit that right now? Will that cause everybody to have to re-vote? Amy: No, you can go ahead and do that now. Lars: The backstory here is that Tetrys is this network coding scheme that is supposed to be IPR-free. I think IPR holders in the space disagree but it is actually unencumbered. Erik: I think that should be changed. Amy: I see that we have added a WG. With the note that's currently in the tracker, we'll send this back to the IRSG. 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o Secure Asset Transfer Protocol (satp) Amy: This was a BOF in the Security area and is now moving to ART and I think Paul will be handing this off to Murray. I have no blocking comments for this charter so unless there's an objection now, this can go for external review. Paul: Wes did ping me a few minutes ago with some minor updates to make it more readable, that aren't in yet. I don't know if that changes our process right now or if that can go out later. Amy: Do you want to make the changes? Since external review is approved, you can either hold it until the changes are in the Datatracker and then we can send the external review message after that, or it can go for external review as-is and those changes can be made during the process. It's up to you. Paul: Let's send it out then, we'll do it the second way you said. Amy: Okay. Generally these get sent on Fridays, so this will go out tomorrow. If you have the changes in by then, that's great, and if not, you can do it later. 4.1.2 Proposed for approval o Post-Quantum Use In Protocols (pquip) Amy: I have no blocking comments, so unless there's an objection now it looks like PQUIP is approved as a new WG. Martin: I have a question. Are there circumstances where we would send a document to PQUIP for review? Like, if we have new crypto we're baking, would we want to do a post-con review, or is that not in scope? Roman: That's a great question, and we talked about it. The easy answer is if you have new crypto, we don't do crypto in the IETF. That's an IRTF crypto panel matter. if you have an engineering conversation about crypto that already got vetted by someone else, in a one-off fashion, yes. This WG is going to have the aggregation of that expertise and especially if there's a lesson learned or a pattern that would be great to have that discussion. But it's not going to operate as a directorate. I asked that question when we did a side meeting on it at 115, do we think we want that function. The consensus was we're not ready for that. Amy: Okay, PQUIP is approved and we'll get that sent tomorrow. Roman: Thanks everyone for the review. We're ready to go with the charter, we have chairs and a mailing list, and we're ready to go. 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: There was no IAB meeting yesterday; however, I believe the IAB has the IESG slate from the NomCom so they will do whatever the IAB does and then pass it back to the NomCom. That's the main IAB news. Also just a reminder about the BOF discussions. 6. Management issues 6.1 [IANA #1263515] Designated experts for RFC 8141 (Uniform Resource Names (URNs)) (IANA) Amy: This is the action item we assigned to Francesca at the top of the call. 6.2 IESG Confirmation of NomCom selections for Trust and LLC (Lars Eggert) Amy: This is just here to minute that you have confirmed the NomCom selections for the IETF Trust and the LLC. Those are now public because the NomCom did not wait. 6.3 Approval of updated IESG statement "Guidance on Face-to-Face and Virtual Interim Meetings " (Lars Eggert) Lars: I'm not quite ready to approve this, but if you scroll down the top part is all fine. There's a bullet list where there's still some discussion. There are also some wording changes I'll make afterwards. Zahed, you added that the meetings shouldn't eliminate the need for in person meetings at an IETF. I agree to some degree, in the sense that specifically in person interims shouldn't replace meeting at the IETF, but in terms of virtual meetings I think we want to give groups more leeway if that works for them. We should probably say something that they should still try to occasionally meet at the IETF. Zahed: I have been chair and also AD of TAPS WG, which has been making good progress with interims and online meetings and now and then I have to jump in and remind them that they should come to IETF week. Then some other groups like TRILL, when they have a meeting during IETF they found it interesting that people join even if they're first timers or newcomers, and they also get new contributors and eyes on the documents. I don't think we should have some statement saying if it's a virtual thing just do it whenever you like. We should say something here that virtual meetings have practical benefits but don't forget there's also benefit to the IETF week. I don't know how to do that in a good way. Alvaro: I made the comment that maybe this should be changed to say the meeting should not be held for the purpose of avoiding the IETF week. Zahed: You're not allowed to have virtual interim meetings during IETF week so they all avoid it. Alvaro: What I meant is that if you're having an interim meeting a couple of weeks before the IETF, for example, that's fine. But for the intent of that meeting to not have a meeting during IETF week. I'm starting to doubt myself now. We want the WGs to make progress. How they make progress, I don't care. Some WGs work better in a virtual way. Some people aren't ever going to show up at IETF. Others will only make progress when they're there. For us to say don't meet because we really want you to be at the IETF may result in limiting progress. Even though I was suggesting to say you shouldn't meet for the express objective of avoiding meeting at the IETF week, I think we should take this out and let them meet whenever. If we have problems with any WGs the ADs can address that. Zahed: Then I actually miss calling it virtual interim meetings if we don't care about having them come to IETF weeks. Then basically we're saying interims are like regular IETF meetings that just happen to be another week. Why we're making the distinction between a virtual interim and onsite interim is not clear to me. Martin: I think it has to be different for onsite because people have to choose carefully about how many trips they're going to go on. It's one thing if you need six meetings per year, but if you need three meetings per year and you choose to do interims instead of IETFs, you're forcing many participants to choose between going to interims and going to IETF. That seems like a real tax on the community. Virtuals are obviously quite different; it's time, but costs are not as large. Zahed: I agree with that and that's where I'm coming from too. For onsite meetings people are bounded by practical things. Perhaps we don't need to worry about regulating that. For virtual, if we don't say anything and just let them schedule whatever virtual interims they want, they might not end up having a slot in any onsite IETF weeks. To be honest I think for virtual we should understand the motive of it more. I have one WG chair who doesn't like traveling and coming to IETF meetings. They just wanted to have everything virtual meetings and it's very hard to convince them why they should come to meetings. If we're going to have this statement we should cover those kinds of things. Or we can just decide we don't care if they come to IETF week. Warren: I have a number of chairs as well who are unable or unwilling to attend a meeting. The meeting can still happen during the week and they can chair remotely. A risk of having WGs only do virtual meetings or interims is that we miss out on one of the big benefits of in person meetings, which is cross-area and cross-WG pollination. SIDROPS never having physical meetings ends up with a lot of siloing and people working without knowing what's going on in the rest of the ecosystem. I support what Alvaro was saying; you shouldn't be using interims to avoid actually meeting at an IETF, otherwise we're just a loose collaboration of WGs. Mirja: I wanted to slightly disagree with a few points that were made. First of all I think it's great to have more virtual interims since the pandemic because we can make more progress on some things. And meeting at an IETF week, if we end up in a way that we can productively do our work without an IETF meeting (which I doubt) then why have the meeting? If the WGs don't see a benefit of meeting [in person] I'm not sure we need to push against it. What I did hear though is that there have been a few cases where there's a preference from a chair that's not interested in engaging in the rest of the IETF or traveling and this preference from the chair enforces how the Wgs operate rather than trying to figure out what the participants need. That's a chair management problem. One more point; I think we should think about more actively discouraging in-person meetings and doing virtual meetings. That means just more travel. There's something different about needing additional meetings that might be in person like QUIC. there might also be a point about whether we need to have this in person or virtual. But what you want to say is rather than traveling to 3 places a year just for this WG, it's better to travel three places a year for the whole plenary meeting because that's less travel. I think this is the real concern when you replace the plenary meeting with an in person [interim] and then people just have additional travel. That should be discouraged. Zahed: I personally agree with discouraging traveling. If we can write something about that it would be great. But I also don't think everything should be happening virtually. If the WG wants and they have good intentions, they can discuss with their ADs and then we know what's happening and why. The WG needs to decide whether having everything virtually in interims is more beneficial than meeting during IETF weeks. My mode of operation was that I let them run everything in the interim but I'd like you to meet now and then, even if it's virtually, during the IETF week. I'd like to enforce that somehow, not control but some kind of awareness. Mirja: I see the benefit of having this cross area review, but in a case like TAPS which has been around for many years and has already had input from a lot of people, encouraging them to use an agenda slot they don't really need doesn't make sense. Zahed: It makes sense to me, because when I forced them to do that, the feedback was that it was great. I'm not here to force anyone but I want something in this text to encourage them to meet during IETF week even if everything is done virtually. Rather than every AD having their own view, if we can agree on some kind of text to encourage them somehow meeting in IETF, that's fine. Lars: I think this is really a case by case decision that each WG and their AD needs to take. We can't say anything in there other than something handwavy, and in that case we might as well not do it. Whether you have a mixture of interims that are in person or virtual, and/or happening at the IETF, it's up to a WG and their AD to decide. Either we need to say a lot more than one bullet point or I think we should cut this. Zahed: We can cut it but I want to discuss it. I don't think there's benefit to giving WGs the leeway to do everything virtually. I don't see the point. The highlighted text there doesn't enforce anything. Lars: If you have a WG that you think needs to meet, you can do what you did and tell them to do it differently. Rob: What if we just reword this sentence to just remind people of the benefits of meeting in person? Warren: this is a lowercase should not, it's general advice. Would it make people happy if we tacked something on to the end about helping with cross area collaboration if we want some justification? Maybe we have different sets of views, but I think it would not be in the IETF's best interest if we only had WGs meeting by themselves and doing interims, virtual or in person. A large amount of the value of IETF is that people get together. The reason we all meet together is there is value in that. Having WGs go off and do their own thing without collaborating means that we don't end up with protocols that interoperate well. Zahed: You have a point. I know maybe one or two WGs doing this. But in the future maybe a lot of them will and it will undermine the IETF meetings. Warren: There are some WGs that don't really need to interoperate much with each other because they're building their own little building block. If they don't, it's not the end of the world. We don't have any force of law behind this, it's a suggestion. Martin: I'd be fine with striking it but I'm also comfortable with Rob's suggestion that WGs should consider the advantages of meeting at IETF week, blah blah. Lars: I put a suggestion up at the top above the bullet list. Cut the stuff before this and instead put the thing in red, possibly with Rob's addition. Let's leave the special case of Covid out of this because it's general. Zahed: I see the introduction of this. If you're comfortable with these lines, why not put them in bullets? A lot of people will only read the bullets. Lars: The bullets are specifically guidelines for interim meetings. This is a guideline against interim meetings, kind of. I don't think it goes in the bullets. Mirja: I would find it useful to say something like you should not have an in person interim instead of going to the ETIF meeting because that adds additional travel. Lars: Okay. I'll wordsmith something and send a message to IESG when I think I have a document that's ready to go out. Warren: I think most of us assumed that WGs who had in person interims had so much work to do they couldn't possibly get it done only at the 3 IETF meetings, or they had something like a design team where they specifically wanted a small set of interested parties to get together and chat. Zahed: Lars, I think I buy your argument. That's fine. Lars: Don't forget we're also in a situation where we're always low on agenda slots. So maybe encouraging more people to come in person is the opposite of what we want to do. But that's not for this document. I'll send around a link when I've made some updates. 6.4 [IANA #1262465] renewing early allocation for draft-ietf-pce-local-protection-enforcement (IANA) John: This document is in pubreq, I just haven't gotten to it yet. We should renew this, please. Amy: Is there any objection to renewing this early allocation? I'm hearing no objection, so it looks like this is approved to continue. 6.5 2023 Retreat Planning (Lars Eggert) Lars: I sent around a poll with a lot of date options. There are some before 116 and some after, because we don't know yet how much churn there is going to be on the IESG. Basically we're looking for three days. I forwarded this to the IAB to suggest that if they want to we can collocate. Mirja and I will then figure out what we have. I talked to Martin earlier and he said if we do it in Seattle there's a good chance he can attend in person, at least mostly. I haven't had a chance yet to talk to Francesca; Francesca, where are you in terms of travel? Francesca: I wanted to mention that I decided last week I'll have to be remote for 116. I went back and forth but it's not possible. I filled in the poll and there are some days I can do on a best-effort basis. Also starting in April, I'll be on parental leave again until the end of summer. After that, depending on NomCom decisions. Lars: I guess even if we did it in Stockholm you wouldn't attend, right? Francesca: Right. Lars: That at least solves the problem of Stockholm vs. Seattle. If we can find a week that works for Martin in Seattle that would be good; unless someone else has travel issues I don't know about. Martin: The next few months are a bit up in the air. Yokohama is probably not going to happen but there's a chance I could buy a last minute ticket and show up. If we do it here, it's just a question of getting people to drive the kids around which I'm pretty confident I could do. I'm quite optimistic I could attend almost all of it if it's in Seattle; if it's elsewhere, I would have to do it remotely. Later in the year it's likely things will improve. Warren: NANOG 88 is in Seattle from June 12-14, so if anyone wanted to combine those that could be interesting. Lars: Oh, that overlaps with ICANN [in Washington DC]. I have to be at ICANN. Does anyone have any issues with Seattle or any other travel issues? Rob: I'll have an operation that may stop me flying for about six weeks so February [might be tough]. Lars: Okay, so fill out the poll and we'll see what happens. Next week also we'll find out if there will be AD churn. 7. Any Other Business (WG News, New Proposals, etc.) Lars: It will be announced soon but the social event in Yokohama will be on Thursday, not Tuesday as usual. Basically it's going to be at a special venue that's not open on Tuesdays and they won't open it for us. As soon as WIDE has confirmed it we'll announce it to the community. I'm mentioning it to you because you're probably already planning dinners and such. Amy: A reminder that the BOF coordination call is set for February 1. Lars: Looking at the BOF requests, there are two for DBOUND. Do we know which is the real one? We don't need to talk about it now but maybe the ART ADs can figure out what's going on there.