INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2024-10-17 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 Deb Cooley (DHS CISA) / Security Area Roman Danyliw (CERT/SEI) / IETF Chair, General Area Liz Flynn (AMS) / IETF Secretariat 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 Jean Mahoney (AMS) / RFC Editor Liaison Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Web and Internet Transport Area Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area David Schinazi (Google) / IAB Liaison John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Éric Vyncke (Cisco) / Internet Area Paul Wouters (Aiven) / Security Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Sandy Ginoza (AMS) / RFC Editor Liaison Jim Guichard (Futurewei Technologies) / Routing Area Tommy Pauly (Apple) / IAB Chair Orie Steele (Transmute) / Applications and Real-Time Area Gunter Van de Velde (Nokia) / Routing Area OBSERVERS --------------------------------- Adoulaye Moses Greg Wood 1.2 Bash the agenda Liz: Does anyone want to add anything new to today's agenda? We have a new management item from Roman on 121 agenda topics; anything else? Any other changes? 1.3 Approval of the minutes of past telechats Liz: Does anyone have an objection to the minutes from the October 3 teleconference being approved? I'm not hearing any, so those will be approved and posted. Does anyone have an objection to the narrative minutes from the October 3 teleconference being approved? I'm not hearing any, so those will be approved and posted. I had also sent around the BOF call minutes; we got a couple of corrections from Eric V. Are we ready to go ahead and approve those now pending those corrections or wait until next week and see a final copy first. Eric V: It was pretty minor, in my case. Liz: I can go back and check the recording; if it's okay with you, I'll go back and double check those and then we can get them posted. Roman: Sounds good. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Deb Cooley to find designated experts for draft-ietf-gnap-core- protocol (GNAP Grant Request Parameters) [IANA #1373603]. Liz: We can mark this one provisionally approved, since we have some names from Deb to approve at the end of the telechat. o Zahed Sarker to find designated experts for RFC 9653 (Zero Checksum for the Stream Control Transmission Protocol) [IANA #1378063]. Zahed: In progress; I should have it by next week. o Deb Cooley to find designated experts for RFC 9635 (Grant Negotiation and Authorization Protocol (GNAP)[IANA #1382992] Liz: This is a new item for Deb but we already have names for it, so this one is also provisionally done. * OPEN ACTION ITEMS 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. Liz: We have this on the agenda today to discuss, so this one is in progress. o Murray Kucherawy and Eric Vyncke to create a draft IESG statement about using 2119 language. Liz: And we also have this one on today's agenda, so this is in progress as well. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-bfd-unaffiliated-echo-12 - IETF stream Unaffiliated Bidirectional Forwarding Detection (BFD) Echo (Proposed Standard) Token: Eric Vyncke Liz: We have a couple of Discusses here; do we want to discuss these now? Eric V: Most probably yes as John and Roman are here, for addressing the charter issue. As you may notice, I'm not normally the BFD AD, I took this over from John. John proposed a resolution of Roman's point by updating the charter after. John: Roman and I have been discussing that offline. I don't know if Roman wants to chime in. Roman: I'm in the process. I just didn't finish writing Jeff back on the response. I think the plan here was for the working group to go quiescent or close after it finished this document. I would have certainly been willing to be flexible if we were just talking about one document, but the challenge here is that if you look at other documents that are in the queue, to include another one that you're doing Eric, it's also not in scope. And then there's another one that's in the working group last call that's not in scope. So it's a bit of a problem that we have multiple documents that are not in scope. I think the answer is we have to step back and say, how did we end up here? And I think the answer to that actually doesn't matter. I think the get well plan is if we have a bunch of things that are adopted in the working group, let's revise the charter to kind of cover that. And if there's some exigent situation that we desperately need to get them out, let's talk. But if this is just that we gotta run the administrative traps, I'm inclined to say we should recharter to make the three documents that are out of scope in scope if that's what the community wants. John: That's already in flight. Personally, I wouldn't hold a Discuss under those circumstances, but it's certainly your privilege to do so and either way we'll get it cleared. Roman: Okay. Mahesh: There are three more of those BFD documents that are coming as a cluster behind these three. John: Okay, so, yeah, we'll, we'll scrub the whole list and try to make sure that we have every one of them in scope for the next version. Thanks. Eric V: And the other point, Zahed and a few others, it's about I think the misunderstanding of what BFD is doing in this case. Because, and correct me John, and I'm not sure whether there are authors on the call here. Basically, one node is sending a packet to the IP address of itself, so it will be routed back by the next layer tree up. I tried to convince the author to add this thing and the address selection in the document during my AD review and to be honest, and sorry if they are in the call, they declined. And I think it should come back in the text to make this clearer Zahed, I think it will be clearing your Discuss point here because basically you send a new EDP packet and the next stop will send it back to you. So it's not really going very far away, or maybe I misunderstood you. Zahed: No, I think that there are a couple of things. Brian pointed out that he misunderstood. This could be forwarded to anybody and that's true for any IP packet forwarder you just tell to forward to something. That's kind of not the case here. I think the Discuss point I'm making is that this is explicitly saying this is a one hop thing and we don't need congestion control for this one. And I have a problem with that one because in the UDP uses guideline you should have congestion control and in cases we must have congestion control if we are actually using UDP. In 5880 it says that congestion control is not only a traffic phenomenon, it's also a competitional phenomenon. So this router that you are looping back will be congested due to lack of resources and it may not do the thing that it's supposed to do. And then it also says like even if it's for one hop, you should consider congestion control, and now in this specification we're scrapping all those things. So I have an issue with that. So this is a different thing than what Brian and others are talking about. And then also I think I see some sort of inconsistency in this specification, it says like device A sending a packet to device B with the loopback IP coming back to device A, right? That's the thing. Now device B sometimes says hey, this doesn't need to understand or implement BFD. Sometimes it says ok, it's a BFD session or not a BFD session. Sometimes it says ok, if you need authentication, you need to do authentication sections according to the BFD. Now my question is like, what is this device? It is very confusing. I didn't put a Discuss on it because I think this is a kind of editorial thing we can fix, but we need some very specific text. If we say we don't need congestion control for this UDP, we need to be very specifically explaining why we think so. That explanation is not there. I think we can remove it, that should be also fine but then we just refer to 5880 saying all the operational things are there. Eric V: Just to be clear, do you think that the congestion control should be sent at the sending nodes or the router A when it's sending the probe? Because then it is SSAM control, but the router B which is simply looping back, it's layer three. Zahed: Exactly, the sending notes. And this is also a confusion for me when I'm reading this specification. This specification is specifically for device A, not device B, because device B could be anything. Eric V: Okay, so I see a path to resolution with the authors, I mean, we see how they react to this.. So if nobody else has had a point and they are the two Discusses I think we have a path. Mahesh: I just wanted to point out that to your question of the actual methodology, I did have a related question, which was why is it a single hop only? And I was asking for some clarification in the document and Jeff actually provided two links. He said, first of all, you should read it in the context of 5880 and 5881 and he gave me two links. So if they add those two references in the document, I think you have a better description of how the packet is getting echoed back. Eric V: Okay, thank you. Obviously revised I-D needed, right? Liz: Great, so this one is staying in IESG evaluation with a substate of revised I-D needed. Eric V: Thank you Liz, and thank you everyone for reading it. o draft-ietf-jmap-calendars-20 - IETF stream JMAP for Calendars (Proposed Standard) Token: Murray Kucherawy Liz: There is a Discuss here; do we want to discuss this now? Murray: Nope, not necessary. I'm going to wait for the authors to get back. The question is clear. Liz: So this one will stay in IESG Evaluation; will there be a revised I-D needed? Murray: Put it in AD Followup and I'll switch it to Revised I-D Needed if that's the outcome. o draft-ietf-mpls-rfc6374-sr-16 - IETF stream Performance Measurement for Segment Routing Networks with MPLS Data Plane (Proposed Standard) Token: Jim Guichard Liz: There are no Discusses in the tracker, so unless there's an objection now this one is ready to go. Since Jim isn't here today, we'll put this in AD Followup in case there was anything else he wanted to do with it. o draft-ietf-extra-6855bis-03 - IETF stream IMAP Support for UTF-8 (Proposed Standard) Token: Murray Kucherawy Liz: There are no Discusses in the tracker, so unless there's an objection now this one is approved. Murray, is this ready to go or do you want to do anything else to it? Murray: Approved::AD Followup please, I'll check with them once more. o draft-ietf-avtcore-rtp-payload-registry-04 - IETF stream Closing the RTP Payload Format Media Types IANA Registry (Proposed Standard) Token: Zaheduzzaman Sarker Liz: There is a Discuss here; do we want to discuss this now? Zahed: Not really. I think this will be updated, so with that update my hope is that it addresses Gunter's Discuss. The general question was why is this standards track, and there has been discussion of this. The authors thought it had the highest kind of status at the document level so that in future it doesn't have trouble and we know how the registry was created. I think we're fine here. Is Gunter on the call today? Liz: No, he's not here today. Zahed: Okay. I think I'm waiting for a response. Liz: Okay, so this document will stay in IESG Evaluation::Revised I-D Needed. And just as a warning, Zahed, this document does have a downref, so we will need to know if 8088 should be added to the downref registry. Zahed: Okay. This was called out in Last Call, right? I'll let you know when we clear this. 2.1.2 Returning items o draft-ietf-sidrops-rrdp-desynchronization-04 - IETF stream Detecting RRDP Session Desynchronization (Proposed Standard) Token: Warren Kumari Liz: There are no Discusses, so unless there's an objection now, this is approved. Warren: As a quick reminder, this document has already been through before, everyone said it should come back as PS, and it's now done that. I believe it's ready to go. Approved, Announcement to be sent. 2.2 Individual submissions 2.2.1 New items NONE 2.2.2 Returning items NONE 2.3 Status changes 2.3.1 New items NONE 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items NONE 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items NONE 3.4.2 Returning items NONE 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o Update to IANA Considerations (ianabis) Liz: I don't see any blocking comments, so I think this is ready for external review. Murray: I need like an hour to just look at the feedback Gunter gave and see if I want to use any of it. I'll give you the go-ahead later this morning. Liz: Okay, so we will wait to hear from you and send this for external review. 4.1.2 Proposed for approval o Standard Communication with Network Elements (scone) Liz: I don't see any blocking comments, so this one is approved. Does anyone want to discuss it now? Zahed: I think I have a simple update that I need to add two more words in the charter, which I'll do and let you know. Mahesh, are you happy with the resolution we're ending on now? Mahesh: Yes, Martin and I came to agreement last night about the last edits so once those are updated I think we're good. Zahed: Okay, so I just have those two words to add. Liz: Great; Zahed, we'll wait for you and when you're ready it will be approved. 4.2 WG rechartering 4.2.1 Under evaluation for IETF review NONE 4.2.2 Proposed for approval o Messaging Layer Security (mls) Liz: There are no blocking comments here so unless there's an objection now, this recharter is approved. Paul: The chair just added a few milestones to please Eric. Liz: Paul, is this ready to go? Paul: I just want to check the comments; I'll let you know later today or tomorrow. 5. IAB news we can use John: The things I noted down were: there's a limited domains document coming from them and Suresh at some point and the IAB was talking about whether it's time to try to engage the community at large considering that it's targeted toward BCP. And there was a discussion about whether they should advertise it during the IAB plenary report and the feeling was to publish the document first and then start advertising it. So I think they're not going to do that. The other thing is they were looking for anybody with contacts at Tesla to try to get the Tesla people to talk about this TTPOE thing, so if any of you have them, they're looking. Then [Ryan Polk, ISOC liaison] mentioned that Monday is Global Encryption Day, so if you didn't know that now you know. They also suggested nemops for the joint meeting agenda, and I don't know what they want to talk about, but there it is. And finally, they're having a policy round table breakfast and are hoping to get at least some IESG representation. Those are all my notes. Any questions? 6. Management issues 6.1 [IANA #1376075] IESG approval for application/toml (IANA) Liz: This is returning from last time; has anyone had a chance to look into this further? Roman: I have and Murray, thank you for talking to Alexey to give us a better explanation of the deeper history of those kinds of media types. That's a lot of archaic things that I didn't understand, so this is I guess exactly why we have Alexey in that seat. So this looks good to me. Thanks for the extra time. Murray: Same. Liz: Okay, great. Any objections to approving this? (pause) Fantastic, so we'll call that approved and we will get that official note sent to IANA. 6.2 [IANA #1375267] IESG approval for protocol number (homa) (IANA) Liz: This item is also returning; has anyone looked into this? Eric V: I contacted the requester late, to be honest, just this weekend. He appears to be a professor at Stanford. I sent him an email asking him if he considered making the specification of this homa protocol public, and if he considered running it over UDP because if you want to do datagram only. No reply yet. I suggest we wait until the next telechat and then de facto we approve it, because we are not running out of IP numbers. As a side note, the code is currently using the experimental protocol 254 and it works on v6, so I cannot refuse anything. The last part is a joke, of course. So we defer to the next telechat hoping to get a reply from John, and if not, I suggest we approve it anyway. Liz: Any objections to that path forward? Okay, so we'll bring this back one more time to our next telechat. 6.3 [IANA #1373603] Designated experts for draft-ietf-gnap-core-protocol (GNAP Grant Request Parameters) (Deb Cooley) Liz: Deb has identified Justin Richer, Joe Salowey, and Sudesha Shetty as the designated experts for this registry. Any objection to approving these three? I'm not hearing any, so they are approved and we will get that official note sent to IANA. 6.4 Approval of IESG Statement on Use of BCP 14 Key Words (Murray Kucherawy) Murray: I circulated the link again after the last informal. I think it's ready to rock. Roman: I think I dropped a lot of different commentary on there. I'm uncomfortable with the text as is. As we're pulling it up, one meta question I have here is, what is the force with which we're publishing this statement? So we have a published RFC, and we have a BCP on using those keywords and in this document, we are refining BCP 14 and not sure what noun to use, claims, we're setting guidance. We're doing something. So I guess the brass tacks for me would be if I violate this statement, is that a Discuss? Warren: No. Roman: If I'm consistent with BCP 14, but not with this statement, what does that mean? Warren: It means that you're doing what the RFC says, but you're choosing to ignore some friendly advice which this has, right? This is a narrative or interpretation of what's actually said in the RFC to make it easier for people to follow along. It's an IESG statement saying we think blah blah, blah, but if you don't follow it…I mean it also can't be directly followed or not, it's more background narrative. Murray: The use of 14 stuff has changed over the years, even in the time that I've been on the IESG there's been little adjustments to it. So some of this is that the community needs some understanding of how we apply this stuff and also incoming area directors, there's some background knowledge here that they should probably have. I was surprised, for example, that security uses of these keywords have nothing to do with interoperability. They're just really strong security advice. But BCP 14 if you read it plainly, doesn't say that's what that's supposed to be used for. And also like the operations of requirements around mandatory logging and that kind of stuff, also not something that is in there at all. In my early days on the IESG I was asking questions like, wait, is this proper use or not? And it has come to be proper, can be considered proper or acceptable use. So, that was some of the purpose of writing this stuff, but also we see bad habits, like you shouldn't be using these words in IANA considerations, or in an abstract, and this is that sort of collective wisdom. Now, the stronger way to do this is to rewrite 14 again to include all of this stuff as that, that makes it absolutely clear, there's community consensus on all this. This statement has IESG consensus, it doesn't have community agreement necessarily. So I'm fine with it if we wanna try to turn this into an update of the BCP effort, great. But this is not meant to be that strong. But to answer your original question, I would Discuss it. Once this goes up, yes, I would Discuss on something that goes against these guidelines. Warren: To me, this seems like the quick start guide when you buy a product, right? You have the big thick instruction manual which nobody reads. This is the quick start guide that gives you an overview. Roman: But I just heard us say two different things. When I said, would we Discuss on this, Warren said no, it's conformance to the RFC, this is friendly advice. And Murray, I just heard you said you would Discuss on this. So we're suggesting that this carries different weight. Warren: I think that anything you could Discuss on this is stuff you would be able to Discuss on BCP 14 as well, right? This is a thing which summarizes it. So if it's wrong in here, it's by definition wrong in 14 as well. So the Discuss isn't you're Discussing on the stuff in the statement, you're Discussing on the 14 stuff. Francesca: Strong agreement, Warren, and by the way, I already Discuss BCP 14 words based on what's written in the statement. So it's already the case; to me this just clarifies the thought process behind it. John: Kust to take one example from this, I can't remember where it is in the statement, but there's something that says, Look people, 2119 keywords are not the only way to be normative. I think that's just bloody obvious and I'm pretty sure it's there in the plain text of 2119, but there's like some kind of assumption that authors who haven't actually read 2119 have come up with that things have to be in capital letters because capital letters. So I think it's helpful to restate these things even though they're supposed to be known. Roman: So if we think that's the case, and I'm gonna set aside whether I agree with that, I would strongly recommend we include a sentence to the effect of not changing what BCP 14 says, this is just… This is the place where I don't want to define it here on the fly, but something, right? So the letter of the law is still BCP 14, we haven't invented anything new. Murray: Right, sure we can say that. Roman: But I want to talk about whether we've invented something new here. Like my comment, I think it's my third one down on the screen. I think I said that bullet point is literally the definition of how I understand SHOULD. Murray: Oh, here it is. I see the distinction. Sometimes when you're writing a doc, when I've seen this case, they want to stipulate that you have to do a thing, but they're afraid of being that strong because if I am that strong and I prescribe any other behavior, people aren't going to implement this. And so they back off of MUST and go to SHOULD just for that reason, and that's not a good reason to go to SHOULD. So we could find another way to say this. Roman: I understand that. That's certainly not how I read it. Murray: Okay. We can clarify that. To your larger point, none of this is changing any behavior at all, and we can say that explicitly. A lot of this is writing down how the IESG has come to use this BCP 14 stuff over the years and it's more like drawing a line in the sand and saying this is how we interpret it today. This is how it gets used. Sometimes you can get Discusses in ways you might not expect. This is why. This is a distillation of my experience with BCP 14 over the last five years is another way to look at it. Roman: I welcome having texts like this, I maybe should have opened with that. I absolutely welcome this and I think it'll be very helpful to the community. I just don't want to create confusion in the community that we have somehow extended BCP 14 without revving the document. Just making that crystal clear. Murray: Okay. Deb: I think you might be able to do that by subtly changing the title of the document. Murray: Okay, I can look at that too. Deb: Because then it's up front. So the trick is you've got it in the second paragraph, and you haven't buried the lede exactly, but if you put it in the title like this is clarifications or guidance or some weasel words like that, then it's right in the title. Eric V: I like clarification in the title indeed. Murray: Okay. Roman: I'm not married to the title, but I think Deb, you're exactly onto something. The words that trip me in the second paragraph is providing guidance "supplementary" to BCP 14. The way I read it is you have BCP 14, and now there's this extra stuff that's supplementary, not that you're providing the interpretation of BCP 14. Deb: I think things like clarifying guidance as opposed to just guidance, taking out things like "supplementary" too, which sort of points to it like it's meant to be a change, but you haven't made the change. I can take a look at this, probably not till tomorrow. Murray: That's fine, and feel free to make some suggestions in the doc for how I can change the title and where should I make that, should the second paragraph go up to the top or something like that. Can we just repeat this action item in a week? Is that enough time? Roman in particular, is this correctable in that period of time, do you think? Roman: Yeah, absolutely. Do we have an informal next Thursday? Murray: No, we have a formal. Liz: That's our last telechat before Dublin, we have a back to back formal next week. Roman: I forgot that we're doing back to back. Let's put this on the agenda. 6.5 IESG Statement Addressing Comments and Crediting Contributions (Orie, Francesca, Murray, Mahesh, and Warren) Liz: This one looks like it's also not ready to go based on the Google document. Do we want to discuss this now? Francesca: Orie's not here, but I think we should discuss your comments, Roman. I haven't had time to go through it. Roman: My top line feedback is very similar to what Deb said in one of her comments; I think there are distinct ideas being introduced here. Maybe if we made section headers it would better organize it. Right now it's a flow I don't understand. We're losing the point, we're repeating ourselves. I understand sometimes we need to use the same supporting references to make a different point but the message is getting lost in that flow. The easiest suggestion might be to add some section headers with some top line statements about what the guidance is after the section header. Francesca: That sounds good; we can give it a try. Deb: It just sort of looked like it was hopping all over the map. I've unfortunately had a fair bit of experience trying to explain things to people who don't have enough cycles. In my book, shorter is better and you've gotta hit them in the face with it. Section headers help them to organize it, I think. Francesca: There are different kinds of statements, that's not the right word, but there are different things being said and I feel like not everything is covered. Maybe that will help. I'm going to remove the "ship it" names and we'll give it another try. Let's put it on the agenda for next week as well and hopefully we can approve it by then. I guess Orie and I will send an email to slack or the mailing list when we have done our homework. Warren: I'll be at NANOG next week, but I'm fine with whatever people want to do with either of these documents. Zahed: Same as Warren; next week I'll be completely unavailable for any IETF work but I trust you all to do the right thing. Liz: Okay, so we will bring back both of these draft statements next week. 6.6 [IANA #1382992] Designated experts for RFC 9635 (Grant Negotiation and Authorization Protocol (GNAP)) (IANA) Liz: Deb has identified the same three names as for the last one, Justin, Joe, and Sudesha. Any objection to approving them? Eric V: I just want to say maybe Joe's email address is not correct? It should be spelled the same as his last name. Liz: Good catch. We can double check the spelling of his email address and whichever one is correct, we will send that to IANA in the official note for both of them. So they are approved here as well. 6.7 IESG Agenda for IETF 121 (Roman Danyliw) Roman: Just quickly, please put any agenda topics you have on the wiki and remember, we have two buckets we need to fill, things we want to talk about with the IAB, things we wanna talk about ourselves, and hypothetically if we want to bring someone else in, either have a longer conversation with IANA, legal counsel or whatnot, I'm sure we could accommodate that if we can just provide enough advanced notice. So please fill that out so folks can start planning their meeting week. 7. Any Other Business (WG News, New Proposals, etc.) Warren: We will be trying some new stuff on the IETF network in Dublin. Specifically, we're going to be using the big shiny Juniper firewalls instead of the routers. We think everything should be fine, but just a heads up, if you notice anything weird or funky please let me/the NOC know. Especially with nat64.