Narrative Minutes interim-2020-iesg-22 2020-10-08 14:00
narrative-minutes-interim-2020-iesg-22-202010081400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2020-10-08 14:00 | |
Title | Narrative Minutes interim-2020-iesg-22 2020-10-08 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2020-iesg-22-202010081400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2020-10-08 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Deborah Brungard (AT&T) / Routing Area Jenny Bui (AMS) / IETF Secretariat Alissa Cooper (Cisco) / IETF Chair, General Area Michelle Cotton (ICANN) / IANA Liaison Roman Danyliw (CERT/SEI) / Security Area Martin Duke (F5 Networks Inc) / Transport Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Wes Hardaker (USC/ISI) / IAB Liaison Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Loon LLC) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB ChairWarren Kumari (Google) / Operations and Management Area Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Alvaro Retana (Futurewei Technologies) / Routing Area Amy Vezza (AMS) / IETF Secretariat Eric Vyncke (Cisco) / Internet Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Martin Vigoureux (Nokia) / Routing Area Magnus Westerlund (Ericsson) / Transport Area OBSERVERS --------------------------------- Adrian Farrel Tim McSweeney Francesca Palombini Greg Wood 1.2 Bash the agenda Amy: Does anyone want to add anything new to today's agenda? Any other changes? 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to approving the minutes of the September 24 being approved? Hearing no objection. Does anyone have an objection to approving the narrative minutes? Hearing no objection there. We'll get those posted. 1.4 List of remaining action items from last telechat o Martin Vigoureux with Wes, and Alvaro to work on some mechanism to obtain wider or private feedback from people who are disenfranchised; anonymous flagging of offensive emails to inform leadership; more opportunities for private feedback. Amy: This has been updated into another action item so this particular item is done. o Warren Kumari to work on acknowledging shepherds, directorate reviewers in a more standardized/formal way. Warren: Still in progress. o Eric Vyncke to write up draft text on Special Interest Groups and send to the IESG for comment. Eric V: Still in progress. o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at updating the I-D Checklist. Murray: I have what I need to get Ben and Alvaro together to sync up. Moving slowly but still moving. o Alvaro Retana and Martin Vigoureux to draft text on guidance regarding the number of document authors on documents. Alvaro: In progress. o Alvaro Retana, Rob Wilton, Alissa Cooper, and Martin Vigoureux to draft text on the framework for a long-term future plan for the IETF. Alvaro: In progress. o Roman Danyliw to draft text for a request to the Tools Team to move BoF requests from the BoF Wiki to the Datatracker. Roman: We're in discussions. This won't be live for 109. o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying text on Errata Best Practices. Alvaro: Also in progress. o Eric Vyncke to follow up on the suggestion at IETF 108 to share a list of grammar checking tools with the community. Eric V: Still in progress. o Barry Leiba to discuss possible datatracker feature request regarding flagging who is responsible for the next step for a document; the document authors, the WG Chairs, the AD Discuss Holder, or the Responsible AD, with Robert Sparks. The feature request should include a "length of time in state" flag. Barry: You can mark this done. We need to discuss it at the next informal. The short answer is that I've had some discussion with Robert about it and he's discouraging in his comments because of the difficulty of implementing in the Datatracker. He suggests we might just use the Datatracker comments to keep track of this rather than force it into the Datatracker fields. But we can discuss it at the next informal; I'll put it on the agenda. o Robert Wilton and Warren Kumari to draft a charter for a proposed IOTOPS Working Group. Rob: In progress. o Martin Vigoureux to find designated experts for RFC-ietf-babel- rfc6126bis [IANA #1178016] Amy: This is on the agenda as a management item. o Roman Danyliw and Murray Kucherawy to find designated experts for RFC 8894 [IANA #1177950]. Roman: In progress. o Murray Kucherawy to find designated experts for RFC 8876 [IANA #1178766]. Amy: This is a new item for Murray. o Robert Wilton, Alissa Cooper, Alvaro Retana, and Warren Kumari to gather more data regarding the impact of COVID-19 on the IETF. Alissa: I got some mailing list information from Alexa. I haven't had time to do anything with it yet. o Martin Vigoureux and Alvaro Retana to work with Jay Daley on the process for using EthicsPoint incident management software as the mechanism of private feedback and anonymous reporting. Alvaro: This is in progress and we've already started talking to Jay. o Barry Leiba to draft a policy about when to create and announce mailing lists for new potential Working Groups in order to facilitate discussion of the Proposed WG charters. Barry: This is in progress. I expect to get to it tomorrow. o Erik Kline to find designated Experts for RFC 8915. Amy: This is a new item for Erik K. Erik K: This is in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-idr-rfc8203bis-07 - IETF stream Extended BGP Administrative Shutdown Communication (Proposed Standard) Token: Alvaro Retana Amy: I have a Discuss in the tracker; do we need to discuss that today? Alvaro: Sure. First I want to thank the ART area for letting me have this document here today. Alissa, I know that Jacob has been emailing back and forth. I don't know if you want to talk about that last question that you had. Alissa: He didn't really answer the second question here in the ballot, but that's okay. I think what he's proposed gets to the core of the issue anyway. I was just trying to make sure that whatever information needs to be in the document will be there, so somebody who goes and looks at this knows what message they're going to send and how they're supposed to decide that. That's all. Alvaro: What happens is the notification is an error message that says 'reset the session.' There's nothing that happens after that. It doesn't necessarily matter that much that you understand what I told you as long you know it's a notification. The session is going to be reset anyway, so if I send you no text or 128 bits or octets or 255, we're going to do the same thing and reset the session. Warren: Different people have very different ways of putting info in their ticketing system, etc. This text is fairly much always just used by humans so the interesting thing is there is a message there saying it'll be back in two hours, vs oops it disappeared. I don't know if trying to standardize the message does make much sense. It's similar to people just sending out emails saying 'I'll plan to do these seven things, see you in a bit.' Alissa: I'm not suggesting anybody standardize the message, the question is just literally, the guy there wants to send his message in Cyrillic and how does he decide whether he should or not? That's all. Alvaro: He is going to send it, it doesn't matter if the other guy understands it or not. Barry: It's just going to be a question of if the message appears in the log or not. They're not going to be expecting a message that long, so they'll ignore it. Alissa: I think the text he suggested now captures this much better than the text we're looking at on the screen. Alvaro: Okay. Great. We're going to need a Revised ID on this. Alissa: I just want to ask how we could catch this better in the future on the first try, if anybody has a thought. Alvaro: I have no idea. We thought we were doing the right thing thinking about internationalization. We just didn't think about that some messages when translated would be a lot longer. Usually 'I'll be back in 2 hours' probably fits, but if you want to say more, it just won't fit. Barry: This isn't really a classic internationalization problem of how to represent things or how to compare them. This is simply, nobody thought about that the translation would wind up being more octets than the original. Given that we haven't run into this a lot, I don't think it's worth a lot of cycles to deal with. I don't think it will come up frequently. The only thing I can think of is try doing a few translations before you publish the first version and see what happens. Warren: There was also a lot of effort when this was originally being done to keep the message small. There was a huge amount of discussion that this should not turn into Jabber over BGP. So I think this was a victim of people trying to over-optimize. Alissa: That's interesting. Ben: It seems perhaps it's a case where whether you're counting bytes or unicode code points could be relevant. The idea was to limit the length to avoid the jabber but also to avoid being able to put in long confusable things that might cause problems with your parser. So they put a limit on, but the limit is in bytes. If the limit had been in code points maybe that would have been enough. But we do have the hard cap in the number of bytes in a single byte field, so you still couldn't get all possible combinations of 128 code points within those 255 bytes. Alissa: Okay. I just wanted to check. o draft-ietf-dnsop-dns-zone-digest-12 - IETF stream Message Digest for DNS Zones (Proposed Standard) Token: Barry Leiba Amy: I have a couple of Discusses here; do we need to discuss those today? Barry: There are two discusses and a bunch of useful comments. Mr. Recuse, is there anything you would like to discuss here? Warren: I believe the authors have addressed all of the comments and there are commits/pull requests waiting for Roman and Ben to review. I think we can work with them offline. Roman: Did that happen this morning? I didn't see pull requests. Ben: I did not remember seeing pull requests linked. Warren: I'll have to take a look. I have not checked this morning. Maybe it's actually just a set of commits and not pull requests. I don't think we need to discuss it now. Barry: I will suggest that we just post a Revised ID and let everybody review the Revised ID. Please put this in Revised ID Needed. o draft-ietf-jmap-mdn-15 - IETF stream Handling Message Disposition Notification with JMAP (Proposed Standard) Token: Barry Leiba Amy: I have a Discuss in the tracker. Do we need to discuss that today? Barry: We do not. I have not seen a response from the author yet so I'll bang on the shepherd and/or author. Put it in AD Followup. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items o draft-hardie-dispatch-rfc3405-update-03 - IETF stream Updated registration rules for URI.ARPA (Best Current Practice) Token: Barry Leiba Amy: I have no Discusses in the tracker so unless there's an objection it looks like this one is approved. Barry: There are a couple of good suggestions for minor text updates so let's put this in AD Followup as well. Amy: This is going in Approved, Announcement to be Sent, AD Followup and Barry, you can let us know when that's ready. 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-cellar-ffv1-18 - IETF stream FFV1 Video Coding Format Version 0, 1, and 3 (Informational) Token: Murray Kucherawy Amy: I have a couple of Discusses here; do we need to discuss those today? Murray: No. The authors seem to be responding. They hoped to have something ready for this telechat and didn't quite make it. Definitely Revised ID Needed for this one. o draft-ietf-dprive-rfc7626-bis-06 - IETF stream DNS Privacy Considerations (Informational) Token: Eric Vyncke Amy: I have a Discuss in the tracker. Do we need to discuss that today? Eric V: If you don't mind. Alissa, about your first point, there was a discussion on the IESG mailing list as well as the DNS privacy list. RFC 7626 is dated August 2015, five years ago. DoH is there which it wasn't five years ago. I think this works but for sure there will be a bis document in five years. It's informational, so for me it's normal that those documents go back every five years or so. And the second point of your Discuss is a valid point so it needs something there. I'm assuming everyone agrees on that. I've already been in contact with Tim and he's willing to fix it quickly. Alissa: On the first point, could the parts that are really very uncertain be removed? There's a lot of this that could go either way and at the time of writing we have no information. Why are we putting that in an RFC? Eric V: It's a snapshot, right? Barry: To be fair I think it is useful to call out stuff that's currently being worked on, especially since we do expect to put out another update. I'd rather see the document say here are some changes since the last version, there's more stuff being worked on and this is what it is. We don't know where it's going yet, but go look there in the interim. Warren: I agree that it's worth publishing this as an RFC, because this document is of interest to a much larger audience than just the people in the DPRIVE wg or just the IETF. It provides some background and framework for thinking about things. Even if it is going to be updated, having it available for people to read, because a lot of people won't want to bother reading it until it's an RFC. Even if it's incomplete it has value to the wider community and not just the IETF and so worth publishing. but maybe some more words of 'this is a snapshot of work in progress' would be helpful. Alissa: I think really avoiding claims about the central point of this document, which is the privacy properties of DNS, because on all of these things it's not clear at the moment. You don't want to be telling people these are the properties the various transports have when you don't actually know that yet. Those sections listed there and this intro text probably needs editing to make that a lot clearer. Warren: That's a really good point. Eric V: Okay, point taken. So Revised ID Needed for this one. 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 JSON Path (jsonpath) Amy: I have no blocking comments for this, so if there are no objections now this can go for external review. Murray: Do I have to click anything to make this happen or do you take it from here? Amy: We'll take care of it, unless you have any edits to the charter. Murray: No, nothing pending. Fire away. 4.1.2 Proposed for approval o A Semantic Definition Format for Data and Interactions of Things (asdf) Amy: I have no blocking comments so unless there's an objection now it looks like this charter is approved for this new WG. Barry: We have a little bit of editing to do from Roman's comments. I'll let you know when we're ready, Amy. Roman: The proponents already responded and made even better polish on what I'd suggested, so I think this is relatively easy. Barry: Yes it is. Amy: Okay, so you have chairs identified and all the pieces, so when you're satisfied with the text of the charter let us know and we will send the new WG action announcement. 4.2 WG rechartering 4.2.1 Under evaluation for IETF review o Concise Binary Object Representation Maintenance and Extensions (cbor) Amy: I understand these changes are small and might not need external review, is that right? Barry: That's what I believe, yes. Amy: There are no blocking comments so unless there's an objection now it looks like this is approved. Hearing no objections, so this is approved. 4.2.2 Proposed for approval NONE 5. IAB news we can use Alvaro: No news to report this week. 6. Management issues 6.1 [IANA #1178766] Designated experts for RFC 8876 (IANA) Amy: This is a new item assigned to Murray. 6.2 [IANA #1178016] Designated experts for RFC-ietf-babel-rfc6126bis (Martin Vigoureux) Amy: Martin V has identified two experts. Any objections to approving Donald Eastlake and Juliusz Chroboczek? Hearing no objections, so they are approved and we'll get official note to IANA. 6.3 [IANA #1179647] Designated experts for RFC 8915 (IANA) Amy: This is a new item for Erik K. 6.4 Possible Telechat Dates After IETF 109 (Secretariat) Telechat dates have been drafted and the last back to back formal telechat will be February 25th before IETF 110 starts the weekend of the 6th of March. 7. Any Other Business (WG News, New Proposals, etc.) Amy: The BoF coordination call is tomorrow at this same time. Any other thoughts? Ben: I'll note we have several documents in flight for which Jim Schaad was the only author. We plan to do the final publication that way, even though we'll have someone else take over editing duties for the remaining steps in the process. Michelle: We've identified all the registries Jim was an expert for. There was only one registry for which Jim was the sole expert and Russ Housley said he can handle that one. All others had multiple experts. In the next few weeks we'll probably be submitting a management item to take care of that. Alissa: We should probably schedule our pre-IETF leadership calls for the week of November 9. Amy: Last time you used your normal slot and extended it, so a three hour block that Thursday. The joint IAB meeting followed the IAB meeting on the Wednesday of that week. Alissa: The IAB is meeting at a different time now. Maybe we can use that slot. I'll send email. Barry: I got a note from ISOC about the Jon Postel award ceremony. Do you know why that's going to be before IETF rather than during the plenary? Alissa: The announcement will be during the plenary but usually there's also a reception and I think this is in place of that. Since the IETF meeting is in the Asia time zone they decided to do the reception the week before and not have it conflict.