Narrative Minutes interim-2021-iesg-09 2021-04-22 14:00
narrative-minutes-interim-2021-iesg-09-202104221400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2021-04-22 14:00 | |
Title | Narrative Minutes interim-2021-iesg-09 2021-04-22 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2021-iesg-09-202104221400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2021-04-22 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 Roman Danyliw (CERT/SEI) / Security Area Martin Duke (F5 Networks Inc) / 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 Martin Vigoureux (Nokia) / Routing 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 Eric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Michelle Cotton (ICANN) / IANA Liaison OBSERVERS --------------------------------- Duncan Doug Dodson Enno Rey Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything they'd like to add to today's agenda? Any other changes? 1.3 Approval of the minutes of past telechats Amy: Is there any objection to approving the minutes from April 8? Hearing no objection. Does anyone have an objection to the narrative minutes from April 8 being approved? Hearing no objection there either. We will get those posted. 1.4 List of remaining action items from last telechat o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at updating the I-D Checklist. Murray: Robert Sparks took a run at doing the whole thing from the beginning because he had an idea about reorganizing the document around more modern xml2rfc and so forth. I think I heard from him a day or two ago that it was ready, so I need to take a look at it. The short answer is that it's in progress. o Warren Kumari, Deborah Brungard, Stephen Farrell, and Jay Daley to investigate ways to recruit, recognize, and retain volunteers in the IETF. Warren: Not going hugely well. I've been trying to get it rescheduled and have been having a hard time, so no progress since last time. o Ben Kaduk to find designated experts for RFC 8935 [IANA #1184035]. Amy: This is on later as a management item so we'll call this provisionally done. o Eric Vyncke to draft text for the WG Chairs about requesting early review of documents by existing Directorates. Eric V: This has been sent. You can mark this as done. o Alvaro Retana, Rob Wilton, and Martin Vigoureux to draft text on the framework for a long-term future plan for the IETF. Alvaro: This is in progress. Some of this is in next week's retreat. o Alvaro Retana and Martin V to draft text to update the IESG Statement on Internet Draft Authorship to include "Contributors." o Alvaro Retana and Martin V to draft a note to wgchairs Asking them to always confirm author/contributor status. o Alvaro Retana and Martin V to draft text to include in the I-D Submission tool warning about too many authors. Alvaro: We sent an email about the first item on Monday. Lars took a look and made a bunch of comments. I haven't heard from anyone else. We'll leave this text there for a few days and then do the publication of the new statement. The next two we're going to handle in order, so once the first one is done we'll go to the next. Those two are in progress. o Lars Eggert to update the text of the IESG Statement "Last Call Guidance to the Community." Amy: This is done. o Lars Eggert to update BCP 45. Lars: That was one of the two items that came out of the conclusion of the last Call experiment. One of them we did, which was the previous action item to update the statement. BCP 45 is the charter of the IETF discuss list. There's an individual draft that I put together and discussed a little bit in gendispatch. It's gotten the feedback it needed and I'm looking for someone to AD Sponsor this. I suspect more feedback will come in during Last Call. Rob: I was wondering whether it's worth having this discussion after the retreat, depending on what comes out of the discussion on the IETF mailing list. Lars: That makes sense. If we decide to make any changes to the list quickly, this will be overtaken by events. So let's leave this here until the next formal [telechat] and we'll see where we are. o Martin Duke to draft an email to the WG Chairs about session requests for IETF 111. Amy: This is done, isn't it? Martin D: I believe it went out. Amy: That's what I thought. We'll mark this as done. o Erik Kline to find designated experts for RFC 8822 [IANA #1195655]. Amy: This is on [today's agenda] as a management item so we'll call this provisionally done. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-roll-aodv-rpl-10 - IETF stream Supporting Asymmetric Links in Low Power Networks: AODV-RPL (Proposed Standard) Token: Alvaro Retana Amy: I have a number of Discusses for this document; do we need to discuss any of those today? Alvaro: For most of them, we need the authors to get involved in providing answers and revisions. I did want to ask Rob about yours. Do we need to talk about it more? Later in email? Rob: I think we should probably have a conversation, maybe on an informal. My basic question is, if the WG decides to publish a protocol without doing a YANG model for it, and it looks like that model may not come anytime soon, if at all, is that something that we care enough about? Would be we delaying publication of documents until it looks like that's going to happen? I'm not saying we should stop this document on that basis, which seems unreasonable, but I do think there's a general question here as it's unclear to me if and when a YANG model might come along for this protocol. Alvaro: Sure. I guess we can talk about that at the next informal. Rob: But I won't block the document on that basis. Alvaro: Perfect, thanks. Lars: Quickly, do you think all protocols should have YANG models, or specifically routing ones? Rob: No, not all protocols, I mean ones in the network area. I'm not even sure we want to do that, but I think having a conversation about it would be useful. Warren: I think that would be a new requirement so we should have a discussion about it. Lars: There's some time in the agenda for the retreat so we could provisionally put it in the parking lot for next week. Alvaro: Okay. So for this document, we're going to need a Revised ID. o draft-ietf-tls-dtls-connection-id-11 - IETF stream Connection Identifiers for DTLS 1.2 (Proposed Standard) Token: Benjamin Kaduk Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this document is approved. Ben: Let's put it in Revised ID Needed; there are some good comments and already some pull requests in Github so we should get those fixed. Francesca: I didn't want to block this, but I do have a question about this 53 number that was highlighted before. I got some answers from the authors about why this number is incompatible with this document, but the authors had some preference about if this IANA number once it expires, if it gets used with something that is DTLS compatible or only for TLS? I don't know how to make sure that this number is not reallocated for something that works with DTLS. Ben: My expectation is that IANA is basically going to not reuse numbers until we're out of other numbers. Francesca: Even if the allocation is expired? Ben: I think so but I'm not entirely sure. Sabrina: That's correct. We won't use the number until everything is exhausted, but we would also notify you a couple of months before it expires to ask if you want to renew it. Ben: So I think in this case we would just not renew it and it would linger in this state of previously allocated but currently expired. Sabrina: The expiration date will remain in the registry if you decide to let it expire. Francesca: That answers my question. Thank you. Amy: Okay, so this will go into Approved, Announcement to be Sent, Revised ID Needed. o draft-ietf-opsawg-tacacs-yang-10 - IETF stream A YANG Module for TACACS+ (Proposed Standard) Token: Robert Wilton Amy: I have a couple of Discusses for this document; do we need to discuss any of those today? Rob: Yes please. I want to discuss both of them. My first question to Roman is, in your Discuss are you asking both about the status of the document in terms of being informational vs standards track, or just some of the text in the document? Roman: I'm largely looking at the status. I'm trying to be practical here. My worldview is that we did 8907 with all of the challenges that document has. We did it primarily because we wanted a written reference to be able to use as a springboard for next gen development and we caveated that this does not meet the modern day bar but we're documenting the world as it's currently being used. My finesse here is that no one's got a YANG module, no one's got any running code, and we're about to say in a PS you have alternatives here but let me give you new functionality for an insecure technique. That did not seem right to me. Warren: You're right. The existing TACACS+ protocol is awful and 8907 does just document the existing stuff and also kind of implies it's awful. However, this is one of the main, if not the main, way that people currently authenticate operator log on to network devices, so having a management thing which says seeing as you're doing this anyway, here's a way to manage what you're currently doing even though it's stupid, does not seem completely unreasonable to me. I'd rather that people have a way they can easily manage their admittedly stupid TACACS+ protocol in a standardized way than that they don't, so never get around to maintaining and managing and rolling the keys. I kind of think this is the lesser of two evils. Roman: Again, I agreed with the thinking on 8907 and I can get on board with accepting reality and asking if it's a bridge too far to say 'we're already using it so can you just help us do this insecure thing in a standardized fashion?' But I don't think we should do that as a PS. 8907 is informational. If we're talking about configuring an informational thing, that should also be informational. And probably some more caveats as well, just like the ones that are in 8907. Rob: I sort of agree with Warren here. I think Proposed Standard is better for YANG modules. Again, the same explanation Warren has given. I agree that 8907 is informational and that makes sense, but I don't think it necessarily follows that this one should be informational. I think by and large this is just finding a management API. As Warren says, if you're going to manage this protocol, this is the way the IETF thinks it should be done. Roman: We get into the bigger discussion then. PS has a bar, so I'm now providing an administrative interface for the thing I know is bad and I lay out in the document that there are alternatives to. Rob: I think actually also on the point on YANG modules anyway, as a side point, a discussion came up with the Routing ADs about what the standard is of documents that define YANG models, in that case in terms of experimental. I think having some discussion and guidance from the IESG makes sense. Does it make sense to have a broader discussion there and then come back to this? Roman: So what you're saying is do we have a consistent way of saying a particular status for a YANG module? Rob: Yes. In their context it was experimental. For me this is to find an API and it comes back to saying this is the way to configure this protocol. It's not like this is one possible YANG module you could use, we're saying this is what you should use and what everyone should implement as accurately as possible. If you make it informational, it feels to me like it waters that down. Then if we come back along and try to build upon the YANG module and fix the security things, I'd presume that fix, that augmentation, would probably be Standards track and then that will be building on top of an informational YANG model. That feels like potentially the worst of two evils. Murray: I think I heard in there something I agree with, which is that this goes to interoperability, which means Proposed Standard to me, and that kind of ends the argument in my head. Roman: So the piece I guess I didn't understand is, is the thinking that the YANG module we're talking about here covers some future protocol we don't have yet? Because I thought if there was a new TACACS++, there would be a new YANG module. So this struck me as a self contained thing covering just the old TACACS+ protocol. The language I read in there said this is the YANG module for the thing we have now. Warren: So there is in theory supposed to be a TACACS++. What it really was going to be was wrapping TACACS+ in TLS and be done. Honestly though, the birth of the original TACACS+ document was so drawn out and so painful, I think nobody really has the stomach to take it on anymore. They spent months and months and were beaten a number of times by various people and I think the wrapping in TLS part people have kind of, not lost interest in, but it's more trouble than they're willing to do. Roman: That's a pretty scary situation, because that says we're going to endorse the current way we have it, we all acknowledge it's really bad, and we're not using this as a springboard for new work but accepting the scary as-is which doesn't meet modern security. Warren: That's true, however, going back to I believe that this is still the standard way that most people authenticate for CLI logons onto devices. There is no alternative. We can try to push again and say hey authors who wrote TACACS+, the update should be easier, we can try for that. Regardless, seeing as this is the thing that gets used, I think it's better to have a way for people to be able to easily roll the keys and manage it than not. Roman: The keys don't buy you anything. I don't get that. Warren: They do some. In order to do anything interesting with it you need to either know what the key is, and then you can decrypt everything, or you need to know the structure of a bunch of things and then you can get back some stuff. It's far from great. I believe almost everybody who actually uses the protocol uses it in a limited domain / closed network. I don't really know what the alternative is though, in the same way that we still kind of allow MD5 and BGP open authentication stuff, which is also awful. We can choose between acknowledging how the real world works and try to move people along, or not. One thing worth mentioning is that part of the reason we haven't managed to move it forward, is that last time people tried to document how the real world existed, they got beaten so many times they ran away, potentially we propagate that problem if -- [cut off] Roman: Do you think we could write that up? That motivation, in terms of operational considerations? Warren: Possibly. I'm not sure that this is the document to do that, though. This document says we have a protocol, this is how to manage it. This isn't my document. Maybe having something to remind people that TACACS+ is probably a bad idea, but if you're going to do it, here's how you manage it. Lars: I was just going to ask whether this might be case where we want to put an IESG note on the document to talk about this. Eric V: But do we have the same caution when we're using a YANG model for OSPF v2 or v3 without any authentication? Alvaro: The YANG model covers the authentication. Whether people choose to configure it or not. Eric V: But in YANG if I'm not mistaken, you can make a leaf mandatory. Is it mandatory, the YANG model? I don't think so, for OSPF. John: It seems like there's a fine line here between a YANG model that can be used to do something stupid, which is probably every YANG model in existence, and a YANG model that can't be used to do anything that's not stupid, which is this one. Roman: I can get off the philosophical position of not evolving the thing that isn't up to modern stuff because it's in the world and we need a way to manage this thing that's widely deployed. I guess what I was saying is to remind folks that this is here to help us manage this widely deployed thing which has these known issues. It is what it is. I don't think we're inventing new language, we're repeating the language we have in 8907. Having said that, there's clearly a break that's happening here because this is the other part of the Discuss. We actually are changing the guidance on the shared secret, because we're saying MUST in the YANG module, and we're only saying SHOULD in the core TACACS+ document. We're saying different security things for the YANG than we are for the base spec. Rob: I don't know if you saw my reply, but the base spec also says that you SHOULD use a minimum of sixteen, so I think the YANG model is consistent with another sentence in the spec. Roman: But a SHOULD is that I could potentially use four. It is literally impossible, maybe I don't know YANG well enough, to do anything less than sixteen, so the YANG model is MUST. Warren: I might be stretching things a little far here, but I think what's agreed is using something less than 16 in TACACS+ is probably a bad idea. That's what the TACACS+ document says. How do you feel about saying the management protocol doesn't let you do something stupid? If you want to do something less than 16, you can't configure it using this management protocol. That means if you're already using something lower, like eight, when you start using this management protocol, seeing as you can no longer configure something that short, you automatically are getting better security. I wonder if this is getting hand wavy. Roman: I'm hesitating because this is going to be a bizarre set of things coming out of my mouth. I actually don't think we should do that. You open up the Pandora's box. Either the YANG model is a one to one for TACACS+ as it's currently documented, but if you're in the business of saying I know things are bad, but let's selectively try to do that, why do we stop there? To me that reopens the box. Either we're saying we know the thing is bad, but it's widely used, let's just provide a standardized way to twiddle it, or we do it the other way. My recommendation would just be don't make it 16..max, just make it whatever TACACS+ is, which I think is zero..max. John: Are there any other best practices? This is basically in the category of enforcing a best practice. If there are other best practices that should be enforced but aren't in the model, it seems like that's worth doing. But the model is just a configuration API, right? It doesn't make sense to in that model go and try to fix other things we know are bad about TACACS+, like how it uses or doesn't use cryptography. It doesn't seem inconsistent to me, although your argument is worth thinking about but at least for me, it's not compelling. Rob: So Roman, if you look at my email reply, there are two sentences in the document that are almost contradictory in the base spec. One saying you should use more than 16, on saying you can use any number. I think if we had zero that would be violating that other statement in the base spec. If you look at my email reply, I've got the quoted text. That one we can probably resolve offline. So to sum this up, looking at the chat, it sounds like having a general discussion in the IESG about the standards of these YANG models related to informational and experimental would be helpful. For this particular one, it also sounds like having some text that's like a warning to explain the background here, would that be sufficient to move this forward? Roman: I could get on board with that. Let me check the language you have around the second point. Rob: Francesca, would that be sufficient for you as well? Or are you still concerned? Francesca: I'm still a bit confused, this discussion would be not only for this document. It's a good idea we should talk bout more YANG modules for informational and experimental in general. I won't block this document but I realize that I am not aware if this is common practice or not and I haven't thought about the consequences of publishing this as informational instead of proposed standard, so I think we should talk about that. Rob: So I think we're done for today. I'll take an action to discuss it hopefully next week during the retreat if there's time available, and then we can decide in the general context and then this document in particular, if necessary. So I guess AD Followup is the right state? Amy: Sure, this will stay in IESG Evaluation and go into the substate of AD Followup. o draft-ietf-idr-ext-opt-param-12 - IETF stream Extended Optional Parameters Length for BGP OPEN Message (Proposed Standard) Token: Alvaro Retana Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this document is approved. Alvaro: Can we put this in AD Followup? I just want to catch up on the updates made. Amy: Okay, this is Approved, announcement to be sent, AD Followup and you can let us know when you're ready. o draft-ietf-regext-secure-authinfo-transfer-06 - IETF stream Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer (Proposed Standard) Token: Murray Kucherawy Amy: I have a Discuss in the tracker; do we need to discuss that today? Murray: I don't think so. I need to go back and see how the WG wants to respond to it. AD Followup, please. o draft-ietf-emu-eap-noob-04 - IETF stream Nimble out-of-band authentication for EAP (EAP-NOOB) (Proposed Standard) Token: Roman Danyliw Amy: I have a couple of Discusses; do we need to discuss any of those today? Roman: I don't think so. I appreciate the detailed feedback. I think we need Revised ID here and the authors need to work through some of this. 2.1.2 Returning items o draft-ietf-stir-cert-delegation-04 - IETF stream STIR Certificate Delegation (Proposed Standard) Token: Murray Kucherawy Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this document is approved. Murray: This is ready to rock. I only put it on because there was a Discuss on it that cleared, but then the IESG rotated and it didn't have enough ballots, so I just let it ride one more time. Amy: Okay, we'll send that announcement as usual and move on. 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-opsec-v6-26 - IETF stream Operational Security Considerations for IPv6 Networks (Informational) Token: Warren Kumari Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this document is approved. Warren: I think Revised ID needed. There are a bunch of helpful comments that would be useful if they were folded in. Eric V: I was about to say the same. Many comments are sensible and we need to work on it again. Amy: So I'll put this in Approved, Announcement to be Sent, Revised ID needed. You can let us know when that's ready to go. Murray: Brief process question here. This got deferred to this telechat a couple of weeks ago and the state is still IESG Evaluation - Defer. Is the Defer not supposed to automatically clear on the second telechat? Ben: If it did, you could just keep deferring and deferring. Murray: Oh, so this blocks a second deferral. Okay, I get it, thanks. Amy: It used to be that the Datatracker put in a block for the defer, so if it went back to IESG Evaluation it still wouldn't allow another Defer, but it's been several years and I don't know if that's still the case. o draft-ietf-dmarc-psd-12 - IETF stream Experimental DMARC Extension For Public Suffix Domains (Experimental) Token: Murray Kucherawy Amy: I have a Discuss in the tracker; do we need to discuss that today? Murray: No, I don't think so. Tim is the co author who has been responding and he's been very responsive so he plans to respond to Ben very soon. Everything else is comments and he's replied to most of those. We're fine here. Amy: Sounds like this is going to get a Revised ID? Murray: Yes, sorry. o draft-ietf-v6ops-ipv6-ehs-packet-drops-06 - IETF stream Operational Implications of IPv6 Packets with Extension Headers (Informational) Token: Robert Wilton Amy: I have no Discusses in the tracker, so unless there's an objection now, it looks like this document is approved. Rob: I was just going to make a quick comment. Murray asked if I'd seen there were six authors and if they were okay. I was going to quickly ask Warren since he's an author, if he knows whether all the authors have contributed to this document or if I should check with the chairs? Warren: I believe they have all contributed to the document. This document has also been around a really long time. If it was a newer document, the number of authors might be a more reasonable question, but I think all of them have contributed and contributed significantly. Rob: Okay. That's enough for me. Murray, is that okay with you? Murray: Yes, that's fine. I just wanted to ask the question. Rob: Thanks for asking. And thanks for the reviews, I'll make sure the markups get done. Amy: So are we waiting on anything for this? Rob: This will be a Revised ID, I'm sure. 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 3.4.3 For action o conflict-review-yao-regext-bundling-registration-00 IETF conflict review for draft-yao-regext-bundling-registration draft-yao-regext-bundling-registration-03 Extensible Provisioning Protocol (EPP) Domain Name Mapping Extension for Strict Bundling Registration (ISE: Informational) Token: Lars Eggert Amy: This was assigned to Murray this morning so we'll come back to this when the review is done. 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o Effective Terminology in IETF Documents (term) Amy: I have no blocks on this second external review, so unless there's an objection now it looks like this second external review can go out for version 00-07. Lars: It can, thank you. The interesting discussion will happen when it comes back. Amy: Okay, so this review has been approved, and we'll send an announcement. 4.1.2 Proposed for approval NONE 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Limited Additional Mechanisms for PKIX and SMIME (lamps) Amy: It looks like this needs to go for external review, is that correct? Roman: That's correct. I'd like to get it out for external review. What's interesting about this one is that it's the start of getting support for post quantum. Jody added to some of our protocols so if not for any other reason I want to make sure we get a lot of eyes on it. There's some text some folks suggested and I think that's worth doing before we get it out for external review as well. Amy: I'm hearing no objection to sending it for external review, so that's approved. Did you want to do those edits before it goes? Roman: Yes please. Amy: Okay, so you can just let us know when it's ready for external review and we'll send the note. 4.2.2 Proposed for approval NONE 5. IAB news we can use Amy: Martin V had to drop from the call but he sent an email update about the IAB. 6. Management issues 6.1 [IANA #1194832] Designated experts for RFC 9018 (Warren Kumari) Amy: Any objection to approving Donald Eastlake as the second expert for this registry? Hearing no objection, so we'll send official note to IANA. 6.2 [IANA #1184035] Designated experts for RFC 8935 (Ben Kaduk) Amy: Any objection to approving Mike Jones and John Bradley as the designated experts for this registry? Hearing no objection, so we'll send official note to IANA. 6.3 [IANA #1195260] Renewing early allocations for draft-ietf-lsr-flex-algo (IANA) Amy: Any objection to approving this early allocation renewal? John: I think we should approve it. The document has passed WG Last Call and is waiting for me now. That's all. I'm pretty sure it already has implementations. Amy: Okay, I'm hearing no objections to approving this renewal, so we'll send official note to IANA. 6.4 [IANA #1195655] Designated experts for RFC 8822 (Erik Kline) Amy: Any objection to approving Donald Eastlake as designated expert for this registry? Ben: I don't object to Donald, it's just that this particular registry is an interesting scenario and the author of the document which creates the need for the registry is not necessarily an informed expert for the registry as a whole, but Donald has been around for a long time so I suspect he will be able to do just fine. Erik K: Given what we went through to create it in the first place, I don't envision too many updates. Amy: I'm hearing no objection to approving Donald, so we'll send official note to IANA. 6.5 Finalize the Retreat Agenda (Lars Eggert) The IESG edited and finalized the agenda for the following week's retreat. 7. Any Other Business (WG News, New Proposals, etc.) Lars: I grabbed a bunch of Alissa's Discusses that got cleared when she stepped down. I'm going to follow up and I'll either drop them or figure out what needs to happen. That's why you saw email on those old Discusses today. Francesca: I have a question. I have three documents that should advance together. They'll soon go For IETF Last Call and I'd like them to get to the telechat at the same time, but they will take almost all of the pages for a telechat. How do I make sure they get to the same telechat? Warren: The same way you do almost anything; you ask the Secretariat. Amy: When you issue the ballot for each of the three of them, you can send us a separate email just to let us know all three should be on the same telechat and if we have to we'll put them out to a later telechat so they all get on the same one. Francesca: Thank you.