Narrative Minutes interim-2022-iesg-02 2022-01-20 15:00
narrative-minutes-interim-2022-iesg-02-202201201500-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2022-01-20 15:00 | |
Title | Narrative Minutes interim-2022-iesg-02 2022-01-20 15:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2022-iesg-02-202201201500-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2022-01-20 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 Ben Campbell (Independent Consultant) / IAB Liaison 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 Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Google) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair Warren Kumari (Google) / Operations and Management Area Cindy Morgan (AMS) / IETF Secretariat Francesca Palombini (Ericsson) / Applications and Real-Time Area Alvaro Retana (Futurewei Technologies) / Routing Area Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area John Scudder (Juniper) / Routing Area Sabrina Tanamal (ICANN) / IANA Liaison Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area Éric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Roman Danyliw (CERT/SEI) / Security Area OBSERVERS --------------------------------- Andrew Alston Lee-Berkeley Shaw Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything new to add to today's agenda? Rob: Not sure if it's new, but can I request to bump my document up to the start? I'm going to need to drop out between half past and the hour. That's the ANIMA document. Thanks. Francesca: I have something to report from EMODIR, so we can take that at the end. Warren: I probably need to drop after an hour but that likely won't change anything. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes of the January 6 teleconference being approved? I'm hearing no objection to approving those so we will post those in the public archive. I saw final narrative minutes; any objection to approving the final narrative minutes from January 6? Éric V: I have a minor correction; I was talking about the SAVI WG but it was written as "savvy" in the narrative minutes. Amy: We will make that change, thank you. 1.4 List of remaining action items from last telechat * DESIGNATED EXPERTS NEEDED o Zahed Sarker to find designated experts for multiple Bundle Protocol Registries (bundle) [IANA #1217632]. Amy: We have this on the agenda as a management item to approve these experts, so we'll call this provisionally done. * OPEN ACTION ITEMS o John Scudder, Martin Duke, and Robert Wilton to review the document shepherd templates and propose changes to include updated questions, cross-area checks, and an expanded section on the use of YANG models. Rob: If anyone's got any review comments, please can you do that today and tomorrow? I'll sync up with Martin and John next week to get it into final format and then we'll try to bring it to the next informal. o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs asking them to always confirm author/contributor status. o Alvaro Retana and Martin Vigoureux to draft text to include in the I-D submission tool warning about too many authors. Amy: These two hinge on the first. 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 2022. Amy: This is on hold until a little more time has passed. o Francesca Palombini to draft a proposal for requirements for archiving AUTH48 conversations between the RPC and authors/AD/ working groups. Amy: Is this one done? We talked about this last week and a different action item came out of it, but this particular action seems to be done. Francesca: This one is done. Many thanks to Jean for sending much better requirements than I had drafted. I think with her requirements we can consider this done. o Éric Vyncke to talk to the Tools Team about adding the page counts for documents getting an RFC 5742 conflict review to the telechat page count in the Datatracker. Éric V: I've put in a ticket on this and it has been accepted by Robert, so I think we can remove it from the list here. o Murray Kucherawy to look into updating the guidance in BCP 13 on when to add organizations to the "Standards-related organizations that have registered Media Types in the Standards Tree" list. Murray: There has been no progress on this yet but it's next on my list of things to do. o Francesca Palombini to draft text to the community on archiving conversations between RPC and authors. Francesca: This is in progress but it's not too urgent. o Éric Vyncke to create a tools team ticket to add more guidance for BoF Requests in the datatracker. Éric V: The ticket has been created today but not yet accepted. Let's leave this until next time and once it's accepted we can remove it. Warren: I was supposed to have one to approve the IESG statement? Amy: That's a management item on today's agenda. Warren: You're probably right. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-idr-bgp-open-policy-20 - IETF stream Route Leak Prevention and Detection using Roles in UPDATE and OPEN Messages (Proposed Standard) Token: Alvaro Retana Amy: I have no Discusses in the tracker so unless there's an objection now, it looks like this one is approved. Alvaro: We're going to need a Revised ID for this one, please. Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID Needed. It looks like it also has a downref to RFC 7908; does that need to be added to the downref registry? Alvaro: I would like to see it there, but I don't think it has to [be added]. Several people commented that maybe it shouldn't be a downref. It is because it describes the problem we're trying to solve with this draft, which is why we made it normative. For now I would say let's leave it off the registry and we can come back later to decide that. Amy: So you don't need this to be added to the downref registry once the approval announcement goes out? Alvaro: I don't think so. Amy: Okay, we'll make a note of that. o draft-ietf-httpbis-targeted-cache-control-03 - IETF stream Targeted HTTP Cache Control (Proposed Standard) Token: Francesca Palombini Amy: I have no Discusses in the tracker so unless there's an objection now, it looks like this one is approved. Francesca: Thanks everybody for the reviews. I believe the authors have addressed all the comments and proposed text. This will require a Revised ID. the only thing I wanted to ask is, Ben, I think they have answered your comments and they have some questions for you. Everything else is basically addressed so once that's uploaded, if you don't have any more comments, I'll send it forward. Ben: I plan to reply to the email today. Francesca: Great, thank you so much. It's just if you have any suggestions for how to improve the text, nothing major. Ben: There was one spot where I wanted more text and Rob has caused it to be put into existence already. Francesca: Great. Sounds good. Thank you. Amy: So that sounded like it's Approved, Announcement to be Sent, Revised ID Needed. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items o draft-eastlake-rfc6931bis-xmlsec-uris-22 - IETF stream Additional XML Security Uniform Resource Identifiers (URIs) (Proposed Standard) Token: Roman Danyliw Amy: I have a Discuss in the tracker; do we need to discuss that today? Ben: No, I don't think so. And you saw that Roman sent in some directives in email for how to process this one? Amy: I did not but I could have missed it….ah, Revised ID. Got it. This will go into Revised ID 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-anima-asa-guidelines-05 - IETF stream Guidelines for Autonomic Service Agents (Informational) Token: Robert Wilton Amy: I have a couple of Discusses for this document; do we need to discuss those today? Rob: Only very briefly. I think actually Roman's has already been replied to on email and I think that has resolution. Ben's one, that looks to me like a fairly easy one to resolve in terms of fixing the code so that's being handled. I'd like to thank everyone for their reviews and comments but I think we're okay and don't have anything to discuss, unless Ben or anyone wants to say anything else. Ben: I don't have anything else to say. Rob: Thanks everyone. Amy: So it sounds like it needs a Revised ID? Rob: Almost certainly. Thanks. Amy: Okay, we'll put this in Revised ID Needed. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items NONE 3.2.2 Returning items NONE 3.3 Status changes 3.3.1 New items NONE 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items o conflict-review-zia-route-00 IETF conflict review for draft-zia-route draft-zia-route-04 Real-time Transport Object delivery over Unidirectional Transport (ROUTE) (ISE: Informational) Token: Zaheduzzaman Sarker Amy: I have no Discusses for this conflict review, so unless there's an objection now it looks like this is ready to go back to the ISE. Éric V: Just a quick question, Zahed, no discussion because I don't mind too much, but that conflict review would benefit from adding MOPS in the list of related WGs. Zahed: I replied to that one. I'm fine with adding that, no problem with it. The reason I didn't talk about that was because MOPS does operations and this is really a protocol, nothing related to video. So that's why I didn't include it. But if you think it should be, I can do it, no problem. Éric V: I think it's more realistic if we say it. It's been presented at MOPS so I think it's better to include it. Zahed: One of the things I was taking into account is that in TSV we had discussion on what to do with this document because the ISE asked us if any TSV groups wanted to take it. Then I had input from a number of experts and we presented this in one of our TSV area meetings. The response was this is interesting, but there was not much interest in doing it in the IETF. Otherwise it would have really been a conflict with TSVWG. I have one thing to add to Ben, Ben put up a really good comment about these normative references in this document. I was also thinking, is that a criteria to object? I also found a similar kind of documentation, but I think the normative language is only for the IETF stream. Ben, do you have anything else? Ben: No, I think this is the right conflict review response. The ISE gets to make its own rules about what needs to be a normative reference so I don't think that should change what conflict review response we provide. Zahed: This is the first time I've done this and I've been really trying to read things before I pick the right sentence for this review. This is an area perhaps where we can be more purposeful to the ADs who are doing reviews, in what are the different things we should be looking into. I can write a huge list of comments for this document. Anyway, let's add MOPS here during the call and then we can approve it. Amy: Okay, so it sounds like this is approved to go back to the ISE with a note that's going to be updated shortly. We'll get that sent on Monday. Thank you. 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 Stay Home Meet Only Online (shmoo) Amy: This has a few blocks on it. Do we need to discuss the blocks? Lars: I don't think so, and I don't think this is quite ready for external review yet given the blocks. I'm hoping the chairs, who have basically written the rechartered version, will respond. Mallory at least is active. I'm hoping we'll get a new charter proposal written that addresses the blocks and we can then go forward. I think the issues they raise are reasonable but I must have read it in not enough detail to pick up on them myself, I apologize for that. I think we're going to see new text for this. Martin D: I kind of viewed this as a Discuss block. Lars, do you have an intent forward, or do we need to just talk to the chairs? Lars: At the very least it seems unclear. In the email discussion before Alex started taking it to other things I think we were on point and just need to clarify what we mean here. Martin D: Okay. Amy: Okay, so it sounds like this is going to stay right where it is and we will wait for instruction from you, Lars, regarding SHMOO. 4.2.2 Proposed for approval NONE 5. IAB news we can use Martin V: None specifically, unless Mirja has a different point of view. Mirja: It might be interesting for you to know that we confirmed the Nomcom IESG selections so the process is ongoing now. 6. Management issues 6.1 Confirmation of NomCom selections (IETF Trust and LLC Board) (Lars Eggert) Amy: This is just to minute the decision. Have you come to a decision and is it ready for minuting? Martin D: A bunch of email went by. Was it the LLC Board we did over email? Lars: We did both. We did already confirm and we just need to minute it, so we don't need to have a discussion since we're already done. Amy: Can I minute that the IESG has confirmed the NomCom selections for the IETF Trust and LLC Board? Lars: Yes please. 6.2 [IANA #1217632] Designated experts for multiple Bundle Protocol Registries (bundle) (Zaheduzzaman Sarker) Amy: We have a big bundle here. Does anyone object to naming Marc Blanchet and Keith L Scott for the Bundle Administrative Record Types, and CBHE Node Numbers,CBHE Service Numbers; also approving Ken McKeever and Edward Birrane for BPSec BIB-HMAC-SHA2 Integrity Scope Flags, BPSec BCB-AES-GCM AAD Scope Flags; Brian Sipos and Rick Taylor for Session Extension Types, Transfer Extension Types, XFER_REFUSE Reason Codes, SESS_TERM Reason Codes, MSG_REJECT Reason Codes; Stephen Farrell and Edward Birrane for Bundle Metadata Type Codes, Ciphersuite Numbers, Ciphersuite Flags, Ciphersuite Parameters and Results Type Registry; and Rick Taylor for Bundle Metadata Type Codes. Any objections to any of those people being named as the designated experts for this bundle of registries? I'm hearing no objection so we'll get official notice sent to IANA naming all of those people to all of those registries. Zahed: Thank you. It was fun finding all those names. Some of these registries started in, like, 2011 and some were never used, so it was fun finding the people. Thanks. 6.3 Handling Ballot Positions IESG Statement (Warren Kumari) Amy: There's been some discussion of this. Is it ready for approval today? Warren: I think it is. Francesca just made a suggestion which I incorporated, which is pointing to another thing. Francesca: Thank you, uyes. Warren: I don't really know what the process is. I think it's great, does anybody object? If not, let's approve it. Mirja: I'm not objecting because it's not really my business but this is a very untypical IESG statement because it's very long and written in a different way. I just want to say that this will be published in exactly the same way as a blog post and people might not know the difference. I don't see the value in publishing this twice more or less in the same form. I think a blog post is better than the statement. But I'm not objecting to it. Lars: Warren's done a lot of work on this. I don't quite know why we needed an IESG statement, I think this might have predated me, but I'm fine with publishing it. It's not going to move the world. Mirja: For me as a reader I think the blog post is a good read. Otherwise if it was a statement I would want it to be something really short I could read really quickly to get the information. I don't really see the additional value in this. Francesca: I supported this becoming an IESG statement because there are fewer IESG statements and for me it was easier to find IESG statements. The meaning between a blog post and an IESG statement is different. I really liked having this as an IESG statement. It means something else. If people find it in different ways, that's fine. I don't see it as a problem. Amy: Generally IESG statements are posted to the ietf.org website and we also announce them on ietf-announce. I don't know that we do that typically for blog posts. It's possible that it will get a wider readership, at least in the short term, and be easier to find as a statement. Warren: I think a fair bit of the value is that it's easier to find. A blog post is not exactly temporary, but more ephemeral. I think some of the utility is the fact that it is different to our standard IESG statements which always seem very formal and we do very few of them. That's a completely separate discussion. Ben: I think part of the original motivation for wanting to convert this to an IESG statement is that the statement has some weight to it, that the IESG has made a decision as a whole that this is what we think, whereas a blog has a fuzzier position that may not have any official standing. I volunteered Warren to write the IESG statement version and I'm happy to see it go ahead as an IESG statement. Warren: Does anyone think this is a really bad idea? I fully agree it's not going to change the world but I think having more people read it would be useful, especially since I recently had a thing where some authors said they have no idea what any of this stuff means. Éric V: Regarding the readership, should we include a reference, to whether the blog or statement, into every email sent when an AD ballots a Discuss? Warren: I believe there's already a link to the blog post in one of the sets of emails that authors get, but I can't remember where it is and they often don't see it. Ben: I think we currently have a once removed link, so there's a link to some general information page and that page links to the blog post. Warren: I like Éric's idea that if there's a discuss ballot, having this in it so authors see it-- the primary intent of this is so authors don't overreact and panic. Lars: The link there currently goes to the blog post, handling ballot discussions. That's where people are sent at the moment. Éric V: We may want to replace that with the new one. Warren: Okay, I'll try and get that done. I think I still have the ticket which added it so I can update it and say please use this one instead when it's posted. Awesome, thank you very much everybody. Amy: Okay, I have this as approved and it's in our hands to post on the website. We'll let you know when that's done, Warren. Warren: Greg, it's basically the same as what's been posted before but it would be nice to have a once-over, like how it still says "title." Never mind, I think it's all good and we're fixed. 6.4 EMODIR Update (Francesca Palombini) Francesca: During the last meeting with EMODIR I was asked about updates on possible technical deep dives for this coming IETF. I don't know if I missed something; have we discussed this? Warren: Yes we had discussed it; the plan was that there was going to be a technical deep dive on QUIC and it was going to be presented or run by a couple of people. It's not really organized to some extent because every time I try to convince them to generate content they say it will be better to do it in person. Brian Trammell, Ian Sweat, and Jana. It's not likely to happen this time. Francesca: Not for this IETF. Warren: Yes, that's the summary. Francesca: That's okay, sorry I missed that. So we won't have anything technical. We used to have a technical presentation during the plenary, that will be the technical deep dive, right? Warren: The technical plenary presentations have stopped, I think. The deep dive is a separate thing. Francesca: I'm a bit confused. Ben: Talk to the IAB about the technical plenary. Lars: Right, those are an IAB activity. There's been discussion about whether those should be restarted but it doesn't look likely. Mirja: We decided not to organize technical plenaries at this point. Francesca: Thank you. I can report that to the emodir because if I understand correctly for the deep dive, the emodir is part of organizing that? Or that's what I was told? Lars: There's a difference of opinion about who's in charge. I think Emodir thinks they are in charge and there are other people who organize them who believe Emodir is not necessarily helping that much. That's my understanding. If they happen it would be good if the emodir is at least in the loop so they can be aware of what's happening in the week. Francesca: And advertise it to newcomers and everybody, yeah. Okay. I got what I needed, thank you. Lars: In answer to the IAB on the tech plenary question, some people think they have been replaced by the deep dives. They're kind of similar. Mirja: The deep dives are probably something that the IESG is organizing and mainly Warren at this point, I guess. We should also make sure that if Warren ever disappears, someone will pick it up. Lars: Stick them on the IAB? Mirja: Maybe we should discuss it at another point in time. Warren: While we're chatting about this, the plan was the next one will be Quic and I have the authors committed. We should at some point discuss what other ones would be useful for the future. The community provided some feedback but I'm not sure if it's still valid at this point. At the end of the next one we can ask for yet more suggestions. 7. Any Other Business (WG News, New Proposals, etc.) Martin D: Did we ever do a postmortem on the early plenary experiment and evaluate the criteria? I don't remember doing it. Lars: We didn't formally do it. I think we glanced at the attendee numbers and said this looks pretty good, but I don't think we formally analyzed them. It's good of you to remember because I think we said we would report to the community on that. Martin D: I know Amy, you and I had a bit of back and forth trying to find the blue sheet numbers for some of the European time zone plenaries. Amy: I will look but I don't think I got, was it 109 that was a European time zone? Martin D: Gosh, I don't remember. Amy: There were specific ones we were looking for that we were missing. I'm not sure I actually got the numbers but I will go back into my email and double check that for you. Martin D: Do you have ready access to the criteria we laid out or would it be helpful to email that to you? Amy: I'm not sure I understand the question. Martin D: There were something like five criteria we laid out to evaluate this. If it's possible to do it for the informal, I'd really appreciate your help or somebody in the Secretariat's, collating that information. Amy: Sure, why don't you get me what info you're looking for and we'll see what we can do. Martin D: Great, I'll send you an email. Lars: Can we do an action item to track this so it doesn't fall off? Martin D: Yes. And assuming this isn't hard to gather, the idea is that at the next informal we can just run through it. Lars: I just thought to add it to the list of action items so we have it. Martin D: That's fine. Francesca: I had a question for my fellow ADs. I figured I would ask rather than send an email. I got several requests to set up non-wg mailing lists. I was wondering where I can find information about policies or process and IESG opinion on when it's appropriate to set up a non-wg mailing list? Lars: There's a page in the datatracker. It used to be an ascii form you fill out, I don't know if it's different now. Ben: The policy is that mailing lists are cheap and you should feel free to create them with abandon. There's a page that looks like a form that asks you for some info that you don't really have until the list is created, which is kind of weird, so whenever I send people a link to the page I include a disclaimer that some of what it asks for is nonsense and just fill in what you can. Warren: There is also, or for a while there was a thing where you filled in a form and it would send mail to the group that would do something with it. For a while that link wasn't going anywhere or the mailbox wasn't being monitored. I'd suggest if someone fills out the form and doesn't get a response in a couple of days, to poke someone. Francesca: My question was less about how to do it, because I would ask the Secretariat for that, but more when is it appropriate to create a non-wg mailing list? In this particular case I have people who work with stuff that is related to an ART wg but they don't have a mailing list right now to discuss this so they asked if they can get a list @ietf. Warren: I think the general thing is try and make it so that their list does not end with wg, or people will assume it's a wg. And if people make a mailing list and then they think they might eventually have a wg, it gets very confusing that there's an existing list and a wg and the names are not the same. Francesca: Yes, they are aware this is not for a wg so that shouldn't be an issue. Lars: In general Ben is right, there are very few reasons why you wouldn't give somebody a list. Ben: If there's no connection to the IETF at all, you can reject it. Francesca: There's some connection but it's kind of far. Lars: if it's related to an ART wg, there's a connection. John: There's one potential negative I can think of to just creating mailing lists with abandon. Didn't we run into the problem last year about some mailing lists that don't have a moderator? These non wg mailing lists have an administrator but they don't formally have moderators, which makes them an attractive nuisance or potentially does. Is that something we should fix? Murray: I think they typically start with a list owner who is the person that asked for it or an AD or something. Over time, who keeps those things current is something to consider. If it becomes a big spam trap then tools has to come in and deal with it or find new owners or shut the list down or something like that. John: A spam trap but more problematically a flame trap. Our trolls seem to be in hibernation right now for the most part but next time they crop up it'll be a thing again. Warren: Somebody asked a question off list who I may accidentally expose, what is the note well stuff for IETF mailing lists for non0-wg lists? I don't know. Murray: It's the same. Warren: Okay. So once the new IESG slate is announced, many of the people who are going to be ADs are likely to start showing up. Technically they are observers but should we have it so people who are going to be observing can ask questions without having to have someone ask a question for them? Lars: Once they are announced I think we can basically treat the incoming ADs as ADs for all intents and purposes. They should speak up because it's going to be their game shortly afterwards. I'm pushing Gabriel to get the announcements out so we can have a nice and long overlap period. Murray: One last thing about non-wg mailing lists, I would just make sure that someone's not asking for a non-wg mailing list because they want a venue to talk about their thing where that thing is already covered by an existing wg because they don't like those people. That sort of nonsense is something I would look for. Warren: Another thing related to non -g lists. If it happens to be purely a social activity it would be nice if the list ended in -ag and then we can add it to the affiliates list, which is basically runners or cyclists and that sort of stuff. Just to make it easier for people to find. Alvaro: It's probably good to give everyone a heads up about a new list just in case. Francesca: Okay, so I will send this to IESG. Warren: We've missed something really obvious. Dear Secretariat, is there something stupid we're misisng about mailing lists? Amy: I don't think so. Just send email to support and we can help you in any way you need setting up a list. Francesca: Thank you for all the information, I got what I needed. Lars: Looking at next week, on Wednesday we have a joint workshop with the IAB on bringing new work to the IETF. Since this predates my vacation, I forgot about it. Is the IAB organizing this for us, or who owns the content? I know it came out of a bunch of ideas the IAB had but I don't know who's preparing something. Mirja: That's a good question. We will discuss this on the IAB but I'm not sure. Lars: Okay, so we've identified a need to send some email to some people. The IAB can propose some ideas and there are some on the IESG side too. This is an opportunity for everyone, if you have ideas for starting new work, we have two hours next Wednesday to discuss this. Virtual BOFs is something we could propose and I don't think the IAB has heard directly from us. Francesca: I started a thread talking about virtual bofs and I got some really interesting comments. I still have to reply and incorporate the feedback directly in the document. I think the goal was to discuss it during the BOF call, which was the deadline we had set. Mirja: When we discussed this new work there was some feedback during the last plenary to the IAB that we could be more active in supporting new work and we ended up discussing mostly about how to support people in creating BOFs. There might be another step of how to support people actually getting into the IETF that we can discuss but this is closely related to how to organize BOFs. Francesca: If I need to have some sort of recap of what we discussed by Wednesday, if we plan to discuss it, that would be good to know. In my head it was [going to be] on the BOF coordination call. Mirja: If it's possible for you, I think it would be a good fit. I would think having it there makes more sense. Francesca: Okay, I will try to do it. That's one topic. Lars: We have a few more BOF proposals now in the tracker which is encouraging. I pinged the group of people who approached me earlier about doing a NomCom term limits related BOF and asked them if they were going to send us a proposal or not but I haven't heard back. My latest state before that was they thought somebody else would arrange this BOF and maybe they lost energy or something. I'll let you know if something's happening. Éric V: Speaking of those BOF proposals, I know we have a call next Friday. Should we try to get, among ourselves, a preview of who could be the shepherding ADs? Alvaro: I have to drop off in a second for a call. I am looking at that multicast source routing one. The proponents of the CAN one sent the routing ADs an email this morning about looking at that. In the description they talk about overlap with things like ALTO and some other TSV stuff. I think I sent an email to Martin earlier about looking at that too. It may be routing or transport so we probably need to figure that one out. And the other one I think is you, Éric. Éric V: In that one there's maybe an impact on BGP so it could be routing as well, the source address validation for intra-and inter-domain. I've been approached by Dan Li and others from the Chinese university. I'm fine taking ownership but it also intersects with routing and security as well. So it's a little bit unclear. Alvaro: We would all three be happy to talk to you about the routing stuff. Éric V: I will put myself as the shepherding AD and we can always change it later. Murray: I have one last thing to discuss. We've had a flurry over the last several months in ART of email extension docs that are looking for processing. They don't have a home; we don't have a WG that's able to take them. The active email WGs right now are very tightly chartered to work on just the things they were set up for, and are not very interested in rechartering outside that, at least not until their first work items are done. All of these documents have been going to the ISE and getting individually processed, which is fine and they can do that, but we've had a couple of problems. One is the realization that there are a lot of these, and the ISE is now becoming a mini IETF except nobody works on consensus. The first one through becomes the official one, which is not a great place for us to be. In other cases where we have two competing views, both of them go to the ISE and now who's right? Or one will go to the ISE and one will attempt to get me to sponsor it, because the standards track is stronger. The proposal from the ISE is that we really should have a place in the IETF to deal with this stuff. It's not right that it just all keeps landing on the ISE. It's not his area of expertise. He can ask for reviews of course but when there are actually competing documents and two groups of authors don't see eye to eye and aren't willing to cooperate, how do we break this tie? We could just say neither of you get to publish anything, but then we're doing a disservice to the community that this information is not getting published. The proposal is a standing WG that can deal with the flow of these coming in and it can go dormant from time to time. The problem is past IESGs have said we shouldn't have standing WGs. The one that comes to mind is DNSEXT, which after a while was shut down because it was just more of a problem than it was solving. The ops people here will probably have more history on that than I do. That's just what I remember as the example of why we don't want to do WGs like this. Of course then for a standing WG you'd have to have longevity with chairs, when it goes dormant how do you deal with a dormant WG, when you light it up two years later does it even have chairs? I wanted to test the waters here and see how does this IESG feel about this. Should we proceed trying to start a standing WG and find chairs for it? Is there some other solution here to breaking these ties or this problem we've got that there's a flurry of work with no home and it doesn't seem like there's enough to spin up a WG to deal with them individually. With three or four of them in flight I would have to find eight co-chairs and that seems a little crazy. John: We have at least several maintenance groups that sound to me like a standing WG, so I don't really see how this is any different. Murray: Okay. This is a different IESG than the ones who have shut them down in the past, which is fine, I'm happy to do it if that's the way we want to go. Rob: Another possible choice would be to handle them in the area WGs. Murray: ART doesn't have that anymore. With the merger of RAI and APPS, Apps used to have APPSAWG which was chartered to do it and had an appropriate audience for it. We tried it with Dispatch and the audience has changed to where that was a bit of a disaster we're now cleaning up. The wrong people looked at it at the wrong times in the wrong ways and then it got all the way through to IESG approval and now appeals have been threatened. It just didn't get handled the way we needed it to get handled, so that model does not seem to work for dispatch. So ART doesn't have an area group anymore, so I agree with you it could happen that way but we don't have the benefit that other areas have of that. We could try to spin that up again if there's appetite for it but that seems like a second choice. Rob: And there's a downside to an opsawg, in that I think there are quite a lot of people working on different things in that WG and it's not really clear to me that they're talking much or cross reviewing the different things. It's almost like different work happening in the same place. In the other cases, that's meant to be the maintenance working group for the management protocols but the experts aren't there, the viewers aren't there, and the interest isn't there. So it's also stuck that it's hard to pull in the folks that, if there is anyone who cares about these documents that people should be able to push through the IETF, but getting the interest to do them is hard. It is a problem. Lars: In transport there's tsvwg which is lots of different unrelated work items under one umbrella and it's been struggling for a while now. Email seems like a large enough technical topic that you could have an email focused maintenance wg that would probably attract that audience. When you don't need it anymore you could shut it down. Murray: Yeah. The obvious name that comes to mind is Mailman but that's what the software is called, so we'll have to come up with something else. Okay, I'll put a charter together and see if I can find people who are interested in chairing something like this. It would be a better place to do it. My most recent memory of maintenance WGs was that the IESG was negative on them, but if that's clearly switched, then I'll change my tune and we'll head that way. Thanks for the discussion. Francesca, did I cover that right and is there anything you want to add? Francesca: It was great. The only thing that maybe wasn't very clear is that I would expect the work in this WG to be non-uncontroversial, let's say. That's why going through dispatch or AD sponsored would not make a lot of sense. I think a WG is the best option and we can see how that works. Amy: Anything else? Thanks, see you next week.