INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2024-08-22 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Jenny Bui, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Jenny Bui (AMS) / IETF Secretariat Deb Cooley (Department of Homeland Security, Cybersecurity and Infrastructure Security Agency) / Security Area Jay Daley / IETF Executive Director Roman Danyliw (CERT/SEI) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat Sandy Ginoza (AMS) / RFC Editor Liaison Jim Guichard (Futurewei Technologies) / Routing Area Mahesh Jethanandani (Arrcus) / Operations and Management Area Erik Kline (Aalyria Technologies) / Internet Area Murray Kucherawy (Meta) / Applications and Real-Time Area Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Web and Internet Transport Area Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area John Scudder (Juniper) / Routing Area Orie Steele (Transmute) / Applications and Real-Time Area Sabrina Tanamal (ICANN) / IANA Liaison Gunter Van de Velde (Nokia) / Routing Area Éric Vyncke (Cisco) / Internet Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Tommy Pauly (Apple) / IAB Chair David Schinazi (Google) / IAB Liaison OBSERVERS --------------------------------- Adrian Farrel Patrick Meenan Laura Nugent Behcet Sarikaya Kent Watsen Greg Wood 1.2 Bash the agenda Liz: Does anyone want to add anything new to today's agenda? Roman: I would like to bash the agenda for an executive session so we can talk about some of the things I've been trading relating to the IETF 125 survey. Liz: Great. We can add an executive session at the end. Any other changes to the agenda? 1.3 Approval of the minutes of past telechats Liz: Does anyone have any objections to the August 8 minutes being approved? Hearing no objections so we'll get those posted in the archives. Does anyone have an objection to the narrative minutes from the August 8 teleconference being approved? Not hearing any objections there either, so those are also approved and we will get those posted. 1.4 List of remaining action items from last telechat OUTSTANDING TASKS Last updated: August 19, 2024 * DESIGNATED EXPERTS NEEDED o Francesca Palombini to find designated experts for RFC 9595 (YANG Schema Item iDentifier (YANG SID)) [IANA #1369452]. Francesca: Got it, thanks. There's an email to answer to the IESG from the RFC editor, so just to say i've seen it. o Paul Wouters to find designated experts for RFC 9580 (OpenPGP) [IANA #1369457]. Paul: In progress. o Orie Steele to find designated experts for RFC 9581 (CBOR) [IANA #1372387] Liz: We'll make sure that Orie has that on his list. * OPEN ACTION ITEMS o Roman Danyliw and Warren Kumari to 1) draft a revision of RFC 4858, 2) draft a revised IESG Statement on Document Shepherds (original statement October 2010), and 3) update the WG Chairs wiki to point to the new IESG Statement. Roman: We need to talk, Warren. This was a large thing now, we should talk about whether we can really close this and if this still makes sense or whether its OBE cause it's been awhile. Warren: Can we declare it OBE because I don't think anyone's clamoring for it. Roman: Yeah. I would like to go that way. Let's pull it off and say, we thought it was a good idea, let's stick to the status quo. Warren: I think we should mark it as completed so that we can at least pretend we did something. Eric: OBE stands for overtaken by events, right? Roman: Yes. We said we would do it a year ago, we didn't do anything with for the first six months and I didn't do anything with it in the next six months. It's clearly not pressing the way we though it was a year ago, unless someone wants to take it from us. Francesca: Is there a list of items that were overtaken by events? Warren: This is basically, we thought we wanted to work on it at the time, a lot of people seemed excited but nobody really cares anymore. Francesca: I understand but sometimes things come up again so it might be good for history reasons to have such a list of things the IESG wanted to do but didn't get to or they didn't happen and that's why. Liz: We could definitely start a list like that in the wiki, but usually we would just remove it from the list of any progress items whether it's completed or not completed. Ok, we'll take this one off the list. o Paul Wouters to write a proposal for handling IANA review mailing lists. Paul: I'll put it back for the informal for next week. o All IESG to review Non-WG List Review spreadsheet and note which lists may be ready for closure and any needed AD Actions. Roman: My question to the IESG is, have you felt like you've had enough time to kind of work through that and do want to batch close whatever has been marked as close and stop tracking that because we've been working on this since April. Has everyone felt like they've had a chomp at this? Warren: I think so, yes. I mean i'm sure we could do a more thorough one but i think it's good enough for that that we could just batch close the ones that we haven't. I know we have also closed a bunch of them ourselves already. Roman: Then I will go into the spreadsheet you had indicated that you wanted to close and we were going to batch up in one request to say like we would now like kind of them closed. I'll take that action and we'll say from there that the review has kind of happened in the non working group list we want to keep open, we'll keep open. Paul: Can you share that link again? So I know that the groups I think the lists that I need to close are on your list. Roman: If i'm not mistaken, the magic is in the IESG only Slack channel. if you look at the pinned non working group list, you can see those that are marked with that status. I'll send a pointer. Mahesh: I think I told the Secretariat to close the list, maybe I didn't update the list. Warren: I've also gone through and closed a number of mine. Roman: That's my fault. I thought in certain cases folks went direct and closed and I think in certain cases we were holding things for a batch. If I misunderstood, I'll go in there and take a look if there's any questions, i'll follow up with all of you. Thanks for taking the time to look through all of that. It wasn't easy. Liz: It seems like this particular action item is done so we'll take this off the list as well. o Orie Steele, Francesca Palombini, Murray Kucherawy, Mahesh Jethanandani, Warren Kumari to write draft of IESG statement addressing issue of credit in documents & the importance of capturing and addressing all comments as a necessary part of the consensus process, mostly pointing at existing advice. Warren: That's actually really in progress. Orie has a good start on it. I know that we had meant to go back and complete it, but I think we got sidetracked. Orie, if you wouldn't mind pasting it again or sending the link again. Orie: Will do. o Murray Kucherawy and Éric Vyncke to create a draft IESG statement about using 2119 language. Eric: In progress. o Murray Kucherawy to draft an IESG statement on use of Internet-Drafts to meet "specification required" in IANA registries. Liz: We'll mark this in progress. o Roman Danyliw to reach out Systers about the value of writing recommendation letters to employers. o Roman Danyliw to reach out to Dhruv Dhody to better track outreach initiatives. Roman: So the next two are marked for me, if i'm reading the dates right they came out from the Vancouver meeting, right? Jenny: Yes, they came out of the IESG only meeting in Vancouver. Roman: I vaguely recollect the first one in the thread. I've been talking to Dhruv about the second one. Do the meeting minutes have further details? Because I don't remember saying that was an action for me because i'm not sure what we're supposed to better track because Dhruv and I were talking and he was saying 'do you know what I should be doing more of?' I don't know what i'm supposed to tell you. Jenny: I can review the meeting minutes. Roman: Does anyone remember this? Mahesh: Roman, I know that the IAB is conducting a bunch of workshops and as part of that, they're also trying to do an outreach into the operator community, going to events such as NANOG so I don't know if this discussion came up in that context. Warren: I think you might already have done this. I'm gong to NANOG, and i'm having discussions with some of the IAB folks, including Dhruv on presentations there. I think that you had this discussion on the IAB meeting two or three days ago. Roman: I'm going to declare that done and full credit to Dhruv, he's the only one doing all the work. He is organizing all of us in a great way. It's better with the community coordinator now. Let's call that one done, and let's leave the first one about recommendation letters. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-netconf-http-client-server-23 - IETF stream YANG Groupings for HTTP Clients and HTTP Servers (Proposed Standard) Token: Mahesh Jethanandani Liz: We have a discuss. Do we want to discuss this now? Francesca: First, I want to thank the authors and Mark for engaging. I sorted the HTTP DIR review sort of late, and Mark was kind to provide one very quick. I just want to remind everyone that anyone can ask for HTTP DIR review. We probably should have had this conversation a bit before the telechat. I've looked at the back and forth, and I just wanted to bring up Mark's concerns and the use of or configuration for HTTP client, I think it's the one thing that stands out. I looked at Kent's reply, and I see you're on the call. The main issue I see, Kent was saying that working group members said it should be possible to configure a client to use only specific HTTP versions and that's why it was added to the document. I guess I do not understand why this needs to be stated in the document, and that's from me not having netconf experience or knowing the background of this. Assuming it is that you actually have, I don't understand how this configuration maps to the HTP implementations and make sure that this configuration does not add requirements HTP that sound not exist because of the way HTTP works. If there are some text that we can add to clarify that, that would be a compromise, it's just not clear to me. I also reached out to Mark offline to see if he can also provide more information about that. Mahesh: I think part of it is really Kent trying and me trying to understand really where the concern is coming from Mark. As you said, really it comes down to that one issue of the client trying to specify a version of HTTP that it wants to use. But I'll let Kent talk or give a little more background than I have on it, and essentially explain why it's needed. Kent: It's not so much that netconf needs it. This particular YANG module is useful for protocols beyond netconf working groups, any HTP protocol could possible use it, but the question at hand is, is it desirable to allow an HPD client to want to restrict the versions of HPD it's willing to use and certainly when using a browser or a human in the loop, and you can type in an URL, it's understood that, the browser will negotiate. But here we're talking about configured, it's configuration, you're configuring a device to act like an HTTP client and so in that sense, it's not really first contact. It's like second contact. The first contact is being configured and the second contact is acting on the configuration so why would it not be OK to say, I only want to use HTTP3 for instance. I don't want to use HTTP2 or HTTP1.1, and that's the issue at hand. It's unclear why this would be a problem to allow for a client to specify which version. Mahesh: I think maybe part of the thing which I'm not sure entirely with that Francesca brought up is, would specifying a version, e.g., impact I don't even want to say the internet, right? I think the point that you were also mentioning is that if the worst case that can happen is the client will never find a version that it can negotiate and fail. Kent: Possibly. Absolutely. So if the client says it only wants to do HTTP3, but it connects to a server, it says it can only do HTTP2 then it should fail and that's perfect. That's exactly what we'd want, and then the client would then move on to another server, presumably it's a configured to be able to connect to more than one serve. Also, I just want touch on something that Francesca said, no way is the configuration model intended to impact the protocol. The protocols, they are what they are, we're simply trying to enable them to be configured. It's not implying any restraints or restrictions on protocol development going forward. Francesca: Because of the way HTTP works, and the way the versioning is negotiated also at runtime, you are impacting the protocol if you say you're only allowing a certain version and you're not allowing this negotiation to be done the way it's done. Kent: True. I mean in terms of a standardization process, we're not restricting. HTTP3 and even HTTP2, using TLS 1.3 and it has APLN application level protocol negotiation, and so built into TLS is the ability to negotiate what protocol you're using. It says that the client specifies a list of protocols that they're willing to run and the server responds with what it's going to use. It's how to configure the client as to which protocols it will advertise in the APLN header in the TLS negotiation. Francesca: That's on par of what I meant when I said how this maps to the actual HTTP implementation or client implementation. I think that we can continue maybe this discussion with Mark also on the list, and hopefully we can get some clarification text or some actionable thing that can be done. I appreciate you working with us Kent, on this. Zahed: During our conversation, I also realized this is something related to what you guys have been discussing so far, HTTP and TLS 1.3, have a very close relation and the way we'll fine it for HTTP2, you have TCP and TLS and all this thing. We might need to think if we might need to do for the same for HTTP3. I think we just need to think a bit more about how you do that. I think you have some really good alternative versions but now i mean, as you mentioned, none of them perhaps the perfect one. I also wrote in my mail, this all depends on what you want to do. You want to configure something or get the configuration out of the device, then that's a different case like if client wants to connect to a serve because the server by default supports a variety of clients and variety of versions of HTTP so you have negotiation and all these things. But if it's just configuration, you might actually get to skip a lot of things and more details, like this is the certificates I want, this is the port I want, this is the version I want, and all these things. Let's have the discussion but don't forget the QUIC, TLS, and HTTP part because that will need some discussion. I'll encourage you can also involve QUIC experts. I'll also ping the QUIC working group chairs too to see how they can help here. Kent: That'd be great. But Zahed, the conversation you and I have been having just recently has been on the HTTP server side or how to configure the HTTP server. Mark's discussed this with regards to how to configure the HTTP client. But slightly different, but, I agree, actually he probably should had the discuss on the HTTP server. Zahed: I was actually thinking of putting a discuss on this one, but as I said, if it's not discussed even but as it is now, there already Mahesh knows about this one I think, please handle it as a discuss otherwise I will change the ballot, if that helps. But it doesn't matter like now we have an issue that needs to be solved whether it's a discuss or comment, it doesn't really matter or at least for me. Kent: The what we're discussing right now is, not fundamental, it's not like architecture, like what should be done, it's just how it should be done with Mark, it's more the architecture it's like what should be done? Like, should it be possible to configure a client? So it's a much higher level question and that's the one that we're trying to resolve right now. Happy to take it offline Francesca, if that helps. Zahed: If it helps, I can elevate my comment to a discuss, but I trust you guys to handle it and just ping me when it's done. Mahesh: If you want to, but otherwise I will when the document comes up for review track to make sure that the comments are addressed. Liz: So this document is staying in IESG Evaluation for now, and i'm guessing maybe revised ID needed? Kent: Yes. Liz: Ok. Great. This will be IESG Evaluation with a substate of revised ID needed. o draft-ietf-bess-evpn-fast-df-recovery-10 - IETF stream Fast Recovery for EVPN Designated Forwarder Election (Proposed Standard) Token: Gunter Van de Velde Liz: We have a discuss, do we want to discuss this one today? Gunter: I think it is being discussed between author and John, so progress is on the way. Liz: This one will also stay in IESG Evaluation, will it also need a revised ID? Gunter: Probably. Liz: This one will be in IESG Evaluation, revised ID needed. o draft-ietf-nfsv4-delstid-05 - IETF stream Extending the Opening of Files in NFSv4.2 (Proposed Standard) Token: Zaheduzzaman Sarker Liz: There are no discusses in the Tracker so unless there's a objection now, it looks like this one is approved. Ok. This one is approved. Is this ready to go as is, Zahed? Zahed: No, I think Gunter has some really good comments. I think it needs a revised ID. Thanks everyone for your review, I think this will help the document. Gunter, do you want to say something? This is approved, but I think i'll ask the authors. Gunter: No, I'm not a NFS person, just some comments. Zahed: I think most of the comments are editorial and clarification so then that should be done before it gets to publication, so this is approved, revised ID needed. Liz: This one is approved announcement to be sent; revised ID needed. o draft-ietf-dnsop-rfc8109bis-06 - IETF stream Initializing a DNS Resolver with Priming Queries (Best Current Practice) Token: Warren Kumari Liz: There are no discusses in the Tracker so unless there's a objection now, it looks like this one is approved. Paul: Warren, do you think we can get the DNS cookies? Warren: We can probably mention something that the client could ask for cookies or something. Paul: I think we should write it because right now it talks about you should use source port randomization. Warren: The reason for that part and not originally mentioning cookies is that this is supposed to be from the client standpoint and the servers would need to be supporting cookies in order for it to actually be useful and it didn't want to be putting it on the server. But I just chatted with Paul Hoffman and we could probably just put in something saying: should ask, should do randomization, and use cookies if they're available or something which is hitching bets. Paul: That's fine, as long as it puts him in the right direction. Warren: Approved announcement to be sent; revised ID needed, please. Liz: Ok. That's approved announcement to be sent; revised ID needed, and you can let us know when it's ready. o draft-ietf-httpbis-compression-dictionary-14 - IETF stream Compression Dictionary Transport (Proposed Standard) Token: Francesca Palombini Liz: We have a discuss, do we want to discuss this now? Francesca: I think so. First of all thank you all for the reviews, and thanks to the authors and I see Patrick is one the call, thanks for joining for a very quick reaction and I believe Patrick has addressed all the comments. There is this discuss from Roman that we should talk about, but there have been a lot of messages, and i'm not sure that I have caught up with all of them. I would appreciate for some summary if someone has followed the whole discussion, and we can it from there about the references to living specification. Patrick: So on the discuss specifically, as far as I understand, this is the best practice for referencing the living standards. There are get snapshots available for all of the what WG standards, but they don't allow you to link to them for implementing standards. They require you to link to the heads. What I did do though is the fetch standard is huge. So the parts of the fetch standard that this actually requires, I added anchor based links and references to, so they should be more stable over time and it'll bring people to the specific part of the standard they need. For the URL pattern standard, it's a much more concise thing and the whole URL pattern applies for the document. So I left the reference to the main URL pattern spec. Francesca: Thanks Patrick. Roman, did you want to? Roman: First, I want to say, Patrick thanks for the quick response and also on the edits for my comment. I had a clarifying kind of question. I'm certainly aware that on the living standards because I try to find the github links in the commit messages that if you try to do the deep link, there is a clear kind of warning that says don't do that. So my confusion on the presentation here is that if living standards from this organization or this gu github repo our living standards, there is no sense of timing or dates, it's just whatever is at the URL. I'm trying to understand, why, like, e.g., what does it mean to say fetch living standard June 2024, right? There is no such thing as June 2024. You would never want to reference June 2024, let alone June 24 at 1005. There is only one kind of URL. So is the pattern of citation, just the URL plus the date or was the date just added to, can you just tell me why there's a date? Francesca: I can answer to this, I don't have a final answer to this, but I I've asked the authors to format the reference, this way just because of precedence. I saw it was done in previous documents that way and I thought this is the way we do it and let's do it the same, but i'm against removing the date if you think it makes more sense to not have the date. And now we also have the anchors that Patrick has added in the reference as well, so hopefully that. Roman: Here's my personal feeling is that it is in every other place where we reference a github kind of repo, we never reference head we go on the deep commit and we previously kind of ballotted kind of on that. I appreciate that this is different and the pitch is being made that it's different. The thing that I don't understand, kind of here is I thought in the past precedent it was cited without dates, so what I don't know how to handle is that if I go to that URL but I'm told only to use the June 20 2024, I don't know how to get there and I'm being kind of told I shouldn't do that. So I don't love it, but the positions to me a deep link to github repo then in fact, you can deliver this, a data kind of snapshot or it's the other end of the extreme to say there's no such thing as kind of deep linking, there is only a URL kind of without the date. I think what we've done here is like something weird in between that's violating both the both the premise of the what working group of actually providing kind of a date, but not satisfying the IETF of actually providing a reference to the deep link. Warren: So I think that some of it is the sort of templating part for putting a reference has a date and we generally stick to a date, so I think it's kind of like we usually do this. It doesn't make much sense to me in this particular case. I think that it would be better if we were to just deep link to the commit. And yes, I understand that that's not official. In the same way we say draft should only be referenced as a work in progress. I think it would be not unreasonable to say when we said fetch.spec.what wg.org, this is the one we actually meant. On a separate note though, I was a little unsure how well this whole thing worked, so I actually had a chat with Patrick and it turns out like this actually works way better than I was thinking, like the whole document, not the or the whole method, not the specific discussion on the, on the reference. Orie: For consideration, I had a chat with some folks who were more experienced with what working group and I asked them, is it appropriate to include a date when you cite a living standard and their position was that it wasn't and then it would confuse people and that they would then attempt to find a commit and then they would see the warning. Don't use this commit. So if it's possible I would remove the date in references to what working group living specifications. It's the, the appropriate way to cite them is top of the treehead. When you use a what working group specification is a normative reference, your intention is to commit to the change control policy to what working group has, and I think their preferences don't include a date, just use the URL and with that comes, a dependency on their change control process and their organizational structure, kind of how they handle living documents. Francesca: I think that this is my fault for for requesting this this specific formatting and the author just complied with, my request when I asked for this fix, or what I thought was the fix and I don't think Patrick for the authors or the working group would have any problem updating the reference that way. Patrick: No, and I looked quickly at the HTTP working group directory and there's a mix, like half of the RFCs have a date, half of them don't. Francesca: I happen to have looked at the wrong one then, but we should definitely be consistent and from now on let's try to remember this discussion and I will make sure to follow up if this comes up again. So I guess the resolution is to remove the date. Warren: I mean, in this particular case, I think referencing it as, as they would like makes sense because it's largely the living standard is going to be probably always the same. But I think in the future, there might be cases where we are speaking about a specific detail within things and so possibly in the future, we might need to actually reference specific commits. So I don't know if this is a hard and fast rule, but it does seem like. Roman: Practically Patrick, I know this is a big can of kind of words here. We're talking about it in lots of different channels. If you're ok with it, I would prefer if you would drop the date from those two and just for just cite the bearer URL with the anchor. You've already have kind of the anchor I'll clear the discuss on that. Thanks for the other changes in the dashboard. Paul: Jay actually made a good suggestion in Slack that you could add a retrieved date somehow in a reference, so you're not pointing to a specific version, you're just saying like when we looked at it wasn't this date. Warren: And speaking of good suggestions, we have Sandy from the RPC here. I don't know if she's got anything she wants to add. Roman: I would love to hear from Sandy. Sandy: My personal preference without knowing that the what Working Group doesn't want you to link to specific portions, my personal preference would be to use the deep link so that it refers to the specific version that's available. But understanding that there is a disclaimer about that, I think it's fine to include it without it point to the living standard, and, we don't typically include access dates, but I could see it being relevant for this one. We actually have someone on our team now who is doing the research on on ways to reference different documents, different types of documents, and to help us formulate our style, right? Like what is the proper way to reference these different types of materials. I would really like to have him take a look at this and make a recommendation for the general case. Francesca: Sounds good, but hopefully we don't need to block this document, hopefully we can do this when it's at the RFC editor if there is anything that needs to be changed. Sandy: I'm going to take note of the discussion that's happening here so that we know what we're agreeing to. What the IESG has agreed to basically is what I'm hearing is no date right now. And if something comes up where the citation specialist is like, 'Oh I really, really recommend against that.' I'll let you know, but I I don't really expect that to happen. Roman: And what I'd also like to get an opinion on the retrieve date situation as well. I don't know whether that's in between. Warren: Isn't that the same thing as what we currently have? I mean, if we've got in July 2024, I thought that was fairly clear. That's what we meant. Francesca: That's what I thought too. Warren: We could reword it to retrieve, but what I thought was June 2024 means what WG at that point. Roman: I'd love an official question kind of from Sandy for like the long term kind of guidance, so I don't want to block here. I think the ecosystem has been explained to me. Folks continue talking, but from my perspective, Patrick, when you drop the date, i'll clear the discuss. Thank you for your responsiveness and your kind of education for me. Deb: When you say retrieve and you say access, that's the same thing, right? Roman: I think it's the same thing. Sandy: I think they're the same thing. Deb: Is there a reason you use access and we're using retrieve? I mean I know nothing here. Roman: I said retrieve because I thought that's what Paul said. Deb: Patrick said. Roman: Jay made a comment about something. Deb: That's just the format of the date, right? Roman: There's nothing special to me, I don't know who said it. There's nothing special to me about the words retrieved, if access is the right word, I'm fine. Whatever I mean, Sandy in the RPC knows better stylistically here. Sandy: The other thing is I had seen that some of the discussion happening in the IESG-IAB chat room, are you OK with me sharing some of that thinking or concerns that were listed there with the citation specialist? Roman: You can certainly extract anything I said. Francesca: Yes. Warren: And sort of as a more general thing I think whenever we're running into these sorts of like what's the best way to cite stuff or things, it would be really useful if the RPC, if they've got views can just jump in and tell us instead of us. Francesca: I'm sure they do already. Warren: Kind of. Sandy felt that she wasn't necessarily supposed to chime in until I was like, Jay mentioned we should ask Sandy and then she was like yes, I've got views. It's also not very clear because we say people are generally observers unless called on. Sandy: I appreciate that. We'll speak up next time. Francesca: Revised ID needed for this one for the same change, and I think everything else is addressed, is that correct, Patrick? Patrick: As far as I know, the main sticking point that's sort of still out there is the shared broadly, files format stream format is a long ago expired draft that has never pushed forward and how we feel about that versus going back to the team and making them go through the steps of publishing it as a informative RFC or something along those lines. Roman: I was going to call that out exactly, Patrick. You're going to sit in misref now because of that. Warren: Does this need to be a normative reference? Roman: It sure does, in my opinion. Warren: It does feel a little worrying that we potentially end up with useful documents stuck on things that are never gonna move forward. Like, it's unclear to me that SHARED-BROTLI would ever actually finish being published so normative reference to draft or something. Murray: We have done that before. I'm trying to remember there like you can you can include a reference to something that's still a draft and the references will mark it as a work in progress, maybe not for normative references though. Is Sandy here? Am I talking crazy here? Sandy: For informative references it's totally fine to reference a draft that's as a work in progress, but that's for normative references we would wait because it means there's a dependency. Like you need to understand that document. Murray: That's right. Roman: And I think we're definitely in this situation where you need to understand that. Warren: What do we do if we don't think SHARED-BROTLI isn't going to move forward? Francesca: Is there so is there any way we can extract the part of that document that are normative to this one and and move that reference back to informative as a if you want to read more, please see this document. That's what I would do. Warren: That sounds like a reasonable option. I did I had thought that we had also in the past normatively referenced a specific version of a draft. I'm trying to remember where, but I thought we'd had a normative reference to, as stated in, you know, version draft-fu-bar. Roman: Francesca, feel free to tell us you're gonna take it offline as well. We I don't know if we need to engineer your solution for you here. Francesca: If anyone else has opinions otherwise yes, we can continue this discussion online. It's faster to do it, sorry, offline. It's faster to do it online. Warren: How much text is there in SHARED-BROTLI that we would need to? Patrick: I imagine quite a bit of it, at least all of the file format, stream format, tokenizing, and that kind of stuff and how the dictionaries are referenced. Cause if you have to know how to build a SHARED-BROTLI stream to use the bR-D content encoding, that's kind of all of the draft. Eric: And then it's too much and we would need to redo the process, right? From IETF LC. Deb: You could put it in an appendix, right? Paul: Other documents will live on and change and now things get really confusing when it breaks in the future because people are implementing different things. Warren: SHARED-BROTLI was a individual submission and it was started in 2018, abandoned in 2021, popped up again in 2022 and is abandoned again or expired. It's unclear to me that. Eric: AD sponsor then? Warren: Yeah potentially. What is interesting is I had forgotten this, I just had a look. It has six authors, all of whom are Google folks, so maybe Patrick could go and find them and ask him, ask them nicely to please. Patrick: I've already asked, I've been working with the team a lot on this stuff. I think it's just more of a priority thing and kicking them and finding the right working group and process to go through to push it over the goal. Francesca: Maybe we need to continue this discussion offline. Liz: This document will stay in IESG Evaluation; revised ID needed. Francesca, just a heads up for you, this one does have a down ref, so by the time it gets approved, we'll be asking whether or not to add 8878 to the downref registry. Francesca: I just realized that now it has one more down ref because, the BROTLI, which is individual is also informational, so, we haven't Last Call that because it wasn't a normative reference before Roman's comment. Checking with the IESG that if we move forward, that's OK. Otherwise, I'm not really sure how we're gonna fix this, but, for a process point of view, objections to having this down ref? None? Ok. Thanks. 2.1.2 Returning items o draft-ietf-ntp-interleaved-modes-07 - IETF stream NTP Interleaved Modes (Proposed Standard) Token: Erik Kline Liz: We have a discuss here, do we want to discuss this now? Erik: We can if people want. I see that has been responding to people although I just got logged out of my email, so, he did reply to Roman. I haven't had a chance to really catch up on all this stuff. It's definitely a revised ID you needed though. Roman: I likewise have not had a chance to look at the response. Erik: We can take it on email. Do people have nothing in particular they want to get at today? Liz: This will stay in IESG Evaluation; revised ID needed. 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-pce-pcep-extension-native-ip-34 - IETF stream Path Computation Element Communication Protocol (PCEP) Extensions for Native IP Networks (Experimental) Token: John Scudder Liz: We have a discuss, do we want to discuss this now? John: Just for a hot second, so Roman looks like the authors have pushed version 35 that takes in the fix that we discussed, so whenever it's convenient for you, I think that you're probably clear to clear as it were. Roman: Ok. Let me take a quick look. I did not see the new version. John: It just was like an hour ago or something. Assuming that Roman goes ahead and clears, please put it in AD follow up because I want to take a last look just to make sure. Zahed: I do have a comment. I think I'd like to get an answer to that one. I didn't want to discuss but I think it would be good to have the author's view on it before we move on. John: I don't remember what your comment was. We could talk about it now or if you're just saying, please don't advance it until we've had a conversation about it. Duty noticed. Zahed: I'm just saying, please ping me before you approve it. John: Ok. Deb: So I looked at this one this morning, they've made a bunch of changes and most of the comments that were made by the SECDIR review and Mallory Knodel and a bunch of other things have been fixed. So look at the diff it's per easy. I think they've made a bunch of changes. Roman: John, I was juggling a lot of documents, I actually did look at the diff here. So my response is, thanks for addressing the kind of the the making the edit with the addition of the reference to deal with: 'Do you have the ability to register based on the registration kind of policy.' My concern is that they introduce new text into the document, which I think is problematic. The text initially said IANA something something should register lowercase, should, these fields, but somehow that should became a normative should, that these fields should be the one registered, which is confusing because that would suggest that it's possible to register without those fields. So does someone understand why we are now putting normative should about fields? John: I sure don't. I mean I just looked at the diff this morning too and I it looked almost like somebody did a search and replace of lower should for upper should, which is, you know, if that's what happened, that's obviously a bad idea so I will look into that and get them to revert it perhaps if it doesn't seem to be appropriate. Roman: Please do because it begs the usual question as we have with the NTP document before and it was we often kind of have, so what happens if I don't follow that should, like how do you do that registration? That just feels, that feels like the original text was more accurate. John: I mean I'm I'm a little less personally when I'm reviewing these things I'm a little less upset about, not having complete clarity on should in an experimental document because in my view the experimental document just has to be good enough to put something in the field to try it out. However, like if if we're, like you said dropping, 2119 keywords into IANA sections, that's just crazy. Liz: So this is staying in IESG Evaluation for now with a substate of AD follow up, so John can check into all those things. o draft-ietf-extra-imap-messagelimit-10 - IETF stream IMAP MESSAGELIMIT Extension (Experimental) Token: Murray Kucherawy Liz: There are no discusses so unless there's an objection now, it looks like this one is approved. Murray: If that's the case, then please AD follow up. Announcement to be sent, AD follow up. Liz: Ok. Great. This one is approved announcement to be sent; AD follow up, and Murray, you can let us know when it's ready. o draft-ietf-teas-applicability-actn-slicing-09 - IETF stream Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing (Informational) Token: Jim Guichard Liz: There are no discusses so unless there's an objection now, this is also approved. Paul: Two small comments. One was I suggested putting IETF in the title before network slicing just to make sure that we're talking about that one thing and it seemed that the authors were OK with that, but they were a little nervous because it's been juggled around for a bit previously on this term, so I just want to make sure that IESG actually agrees to that. Is anyone objecting? Jim: I think Paul just judging by Adrian's responses to all the different comments, it looks like that's not gonna be an issue. Paul: I just wanted to make sure that the IESG doesn't think it's an issue because that's what they were afraid of because we kind of forced the name before. And then the other thing which I think might be normal or not is that I see that there's a bunch of email addresses in the contributor contributing section at the bottom that has like email addresses with work, email addresses. So it looks a bit like advertising like and we're already sort of concerned if that like, when people sort of used that for the author name, but are we objecting to having like, such-and-so@Cisco.com contributed to this thing at the bottom of an RFC? Or are we reserving that for authors? I understood that probably there were too many authors here and that's why the section was created but I just wanted to raise it like, I just want to make sure that, you know, this doesn't become a habit all over the IETF. John: Not only do I not have a problem with it, I actually don't understand what the problem would be with it. Paul: Paul, as I pointed out that there's precedence for this anyway. I mean I can point to some FRCs where we've done that and certainly from our area. It's typical if there's too many authors on the front page, which is a big percentage of the documents, I might say we move the ones that have done the least or object the least into a contributed section and typically we would leave the email addresses there and as I say, there are other RFCs out there that you can look at where we've done that. I gave you one yesterday 9491 for example. My perspective is, it's fine, it's not the same as acknowledgement, but obviously i'm only one member of the IESG. Paul: And that's fine with me. I just wanted to raise it to see if this, if this happens all the time then I will just shut up, it's fine. Eric: Basically, I agree with Jim on this one. Jim: I think it's gonna require a revised ID. There are some changes that need to be made made by based on the comments and Adrian seems to be dealing with that. So, if you could put it in revised ID needed. Liz: This one will be approved announcement to be sent; revised ID needed. o draft-ietf-httpbis-zstd-window-size-02 - IETF stream Window Sizing for Zstandard Content Encoding (Informational) Token: Francesca Palombini Liz: There are no discusses so unless there's an objection now, this is approved. Francesca: Thanks everyone for the reviews, and AD follow up. Zahed: I think Murray and me have been discussing with the authors about one comment that this is an informational document updating another informational document and it is so small that you just changed couple of words basically from recommendation to must must not. The comment I made was this got so much deployment and so much users that people are thinking is worth updating, then it might be the case that we consider if information is the right status. You remember like AKA, the document they were doing it and we turned the information to the standard tracks and this is my question here. I will not like put a discuss on it just to stop it, but I definitely would like to see like if it is out considering changing the category of this document from informational to something more standard track. Francesca: Okay, thanks. I didn't see those emails so it's so good that you brought it up, from process point of view, that will require quite a bit of work. (crosstalk) Zahed: Like is this like available everywhere people are using it because they I mean this question bite me because the the update is so simple and it has almost like, I don't know like if you want to post this to any implementation, then you can do that. If it is a small set of implementations on some like a really small set. You can't just do that. You don't need this, don't need this document. But as we're doing it, must and must not, it's kind of reinforcing the implementation to actually do something so that there is a standard way of doing things. It screams to me like, the information is not the right thing to do. Francesca: Warren, did you want to say something? Warren: I mean, to me it seems like if anything, this document should be pushed as is informational, but if people are using Z standard and application C standard enough, that should be moved to standard. Murray: That was my point, is Z standard is seeing enough widespread use then moving it up after this because if we move Z standard up before this, then this has to become proposed standard as well. So like that was my thought is finish this, but then we should consider moving Z standard up the standards try it, if people think it has that kind of maturity, then that's where it deserves to be. Probably should get someone else to do that because I was an author on Z standard and I don't or an editor on Z standard and I probably shouldn't be seen to promote my own stuff, but I think that that's the right thing to do. Zahed: That's fine with me, but let's move on with this one but reconsider like change the whole whole thing as a standard track. That's fine. But I mean as I said like this, this brought me up to this question like is it like that much deployed like you actually do these two lines of you due to the whole boilerplate of document object to just to say one thing. I mean, what exactly we achieved by doing this object? (crosstalk) Zahed: So the window side changes a must, right? That's the only thing it does, right? It changes the recommendation to a must and and there is a must note also. That's the update, so why are doing this update if this is not that important? Why you do that? Warren: For interoperability, right? We published an informational document, we discovered that people weren't all doing things the same way and that hurt interoperability, and so this document clarifies something in the other document. To me this seems perfect. Zahed: So this, this is, this is informational, actually getting deployed and used and people has problem? Why shouldn't the standard then be a standard? Warren: I think we have different views on what informational is. It's something that people use to publish a document still for interoperability, right? Zahed: For education and interoperability, definitely. I mean you you do certain things on a certain way and you would like to tell people about it and you do it informational. But if people start to use that one and that becomes like a de facto thing perhaps or that really gets deployed in the internet. Warren: I think there's a huge number of informational documents that people are using and are widely deployed. So I don't think I agree with you once something starts to get deployed, it moves from informational to standards track. Zahed: What do we do with those kinds of things? Do we keep doing informational? Warren: Yes. Zahed: We didn't do that more and for for the AKA document that was actually informational and then we actually make it a standard track because we thought that's like getting deployed and getting useful. Francesca: What I would do in this case is I would continue publishing this as information on this updating and information and I would go ahead with a different action which is the status change that takes the last call and nd I would do that for the original, which is 8878 I believe. Let me just double check. Then we can discuss if that status change should also update the status of this one, but I would not block. This one it doesn't make sense to move it to proposed standards before that one is also moved to proposed standard. Zahed: That's fine. I think let's let's build up the consensus and the working group see like if you actually want to move to the standard to from informational based standard right but yeah I think that's a really good way forward. Liz: This one will be approved announcement to be sent; AD follow up. 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-li-arch-sat-00 IETF conflict review for draft-li-arch-sat draft-li-arch-sat-07 A Routing Architecture for Satellite Networks (ISE: Informational) Token: Jim Guichard Liz: There are no discusses in the Tracker, so unless there's an objection now it looks like this conflict review is ready to send. This is one approved. Jim, is this ready to go? Do you want to give it any final checks? Jim: This is ready to go. Liz: This conflict will be sent. 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 o Routing In Fat Trees (rift) Liz: There's a block, do we want to discuss this now? Jim: I'm not sure, Gunter and I have been talking about it and there is some response from the chairs that one of them is currently traveling, but they kind of agreed with the comments because it's an internal review, I've kind of let it, go at the high level and we need to really drill down now before it goes any further. So we're gonna work with the chairs to do that. I think we can resolve the block pretty easily. Do you have any comments? Gunter: No, I think you covered it all. I think it's gonna be easy to look it's not gonna be difficult to resolve the block at all. It's like putting a better framework around it and closing it down a little bit on deliverables. Liz: So do you want us to put this back on the agenda for next time or do you want to just take it and work on it and let us know when it's ready to go to the next. Jim: Let's put it back on the agenda because I think it's gonna be pretty quick to go through the comments and the and the block. They're very responsive to chairs, know we'll get some, some closure on this next week. Let's go ahead and do that. 4.2.2 Proposed for approval NONE 5. IAB news we can use Liz: John, is there any IAB news we can use? John: It took like a few short notes which I meant to send but didn't. Yeah, so the only thing that I noted, was that there was some talk about the end to end encryption workshop that I think Tim Pull kind of brought up on Slack. But sort of the end of that discussion was to say this is, you know, will take a while to actually discuss it properly. So let's defer it to later. Tommy did say that there's currently no intention to have that workshop, but, maybe glad to discuss whether about whether the IAB can help by saying, here's the statement we published before about why the things you want won't work, other than that was it for me. I don't know if Roman has anything to add or Tommy. Roman: I would just add that the IAB is working on some key appointments right now as well. 6. Management issuess 6.1 [IANA #1367916] renewing early allocations for draft-ietf-idr-sr-policy-safi (IANA) Liz: John, do you have any comments to make for this early allocation? John: It's in my public queue. It is not gonna be with the RFC editor before the end of the month considering that's just a few days off. I think this is pretty much a no brainer too. Liz: Any objections to renewing this early allocation? I'm hearing no objections and we'll send that official note to IANA. 6.2 [IANA #1372387] Designated experts for RFC 9581 (Concise Binary Object Representation (CBOR) Tags for Time, Duration, and Period) (IANA) Liz: Orie, make sure you got this one on your list. Orie: Acknowledged. 6.3 [IANA #1366742] renewing early allocation for draft-ietf-idr-wide-bgp-communities (IANA) Liz: This is another one of John's. John: So this one was slightly more painful because it's been getting renewed and renewed and renewed since 2017, as you can see. I checked in with the chairs and authors and they said, no, no really, we're getting back to work on this and we're gonna progress it. And furthermore, there are other drafts that depend on this spec and some of them have code in the field. So yeah, it seems like we should, we should renew it. Liz: Any objections to renewing this early allocation? So we'll go ahead and send that official note to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Eric: Maybe just a warning you have seen that I opened a ballot for the next formal telechat about Warren's draft to move OWEE to IEEE. It's AD sponsored, four weeks Last Call and it's kind of a hurry to be pushed IEEE because they need it so I pushed on the telechat on Thursday in two weeks, and the Last Call finished on Wednesday but it's only 3-4 pages. And the Last Call until now is perfectly fine. So feel free to hit the defer if you don't like it, and if there's any comments on the Last Call, i'll hit the defer. Francesca: If there's a comment, you don't need to defer, you can just remove it. 6.4. Executive Session An executive session was held.