INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2020-08-27 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 Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Loon LLC) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair Warren 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 Martin Vigoureux (Nokia) / Routing Area Eric Vyncke (Cisco) / Internet Area REGRETS --------------------------------- Jay Daley / IETF Executive Director Wes Hardaker (USC/ISI) / IAB Liaison Magnus Westerlund (Ericsson) / Transport Area Robert Wilton (Cisco Systems) / Operations and Management Area OBSERVERS --------------------------------- Adrian Farrel Karen O'Donoghue Sean Turner Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything new to add to today's agenda? Any other changes? None. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes from August 13 being approved? Hearing none, so those are approved. Any objection to approving the narrative minutes from August 13? Hearing none, so those will also be posted in the public archive. 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. Martin V: Still in progress. To give you a heads up, we were waiting on Pete's feedback for the ombudsteam. He has no time so has deferred to the fellow ombudsteam members. We are waiting for their feedback. o Alvaro Retana and Barry Leiba, with Warren Kumari, Alexey Melnikov, Martin Vigoureux, and Roman Danyliw to work on more transparency in the Datatracker about how long each phase of doc process takes / New datatracker flag to indicate who has the ball: area directors, authors, or chairs. Amy: This was the topic of last week's informal telechat; should we mark this done? Barry: Yes, thank you. o Warren Kumari to work on acknowledging shepherds, directorate reviewers in a more standardized/formal way. Warren: In progress. o Eric Vyncke to write up draft text on Special Interest Groups and send to the IESG for comment. Eric V: I was hoping to get the text today but it will be for next week. In progress. o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at updating the I-D Checklist. Amy: Murray, you had the pen on this or you were waiting for comments from someone else? Murray: Both of those are true. Continuing. o Eric Vyncke (with Suresh Krishnan) to write a draft of an IoT Systems charter. Eric V: I'm waiting for Suresh's reply, so in progress for this one. Last time we were discussing IoT operations. Should we combine those things? I will take it offline. o Alvaro Retana and Martin Vigoureux to draft text on guidance regarding the number of document authors on documents. Alvaro: This one is in progress, as is the next one and the other one with my name on it. 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. 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: That's in progress. o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying text on Errata Best Practices. In progress. o Murray Kucherawy to find designated experts for content SDP Parameters, QoS Mechanism Tokens [IANA #1175036]. Murray: I've reached out to a couple of people. I'll probably have something for the next meeting. 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: This is in progress and will be shared very shortly. 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: That is in progress. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-regext-dnrd-objects-mapping-09 - IETF stream Domain Name Registration Data (DNRD) Objects Mapping (Proposed Standard) Token: Barry Leiba Amy: I have a Discuss in the tracker; do we need to discuss that today? Barry: No, that just came in and we need to wait for the authors to respond to it. Put this in AD Followup, please. o draft-ietf-bess-rfc5549revision-04 - IETF stream Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop (Proposed Standard) Token: Martin Vigoureux Amy: I have a Discuss in the tracker; do we need to discuss that today? Martin V: No, not specifically, just to say that I think it's a good point and it will be resolved. I don't think it's a difficult one. Thank you for your review. There are also a lot of valuable comments so we will put this in Revised ID Needed. Thank you very much. o draft-ietf-pce-pcep-flowspec-10 - IETF stream PCEP Extension for Flow Specification (Proposed Standard) Token: Deborah Brungard Amy: I have a couple of Discusses in the tracker; do we need to discuss any of those today? Deborah: I don't think so. The authors are busy discussing. I think it's all okay, so let's keep it in IESG Evaluation, Revised ID Needed. Ben: There was a question about whether it's better to do something in this document or in 5575bis. In particular relating to when you AND two different constraints together and when you OR them together. I don't know if Alvaro had followed that discussion or not. Alvaro: No, I hadn't, but now that you mention it I'll go take a look and reply on the thread. Ben: Thanks. Actually, I think that may have been the next document, sorry. Deborah: No, it was this one. Alvaro, do you know if 5575bis is an RFC or in progress? Ben: It's in the RFC Editor queue. Alvaro: We approved it a couple weeks ago. I'll go take a look at that today. I doubt we're going to change anything in 5575bis. It's a bis because it's reflecting everything that's been implemented and deployed. So if we need to clarify something, sure. If we need to change something, that's going to be a lot harder. In any case I'll go take a look. Amy: Thanks, let's move on. o draft-ietf-lamps-cms-update-alg-id-protect-03 - IETF stream Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection (Proposed Standard) Token: Roman Danyliw Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this is approved. Hearing no objections. There are no notes; are there any needed or is this ready to go? Roman: Thank you everyone for the review. Can you please mark it Revised ID Needed? There are a couple of good comments the author has been working with to revise and he'll drop them in the document. Thanks. Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed and you can let us know when it's ready. 2.1.2 Returning items NONE 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-ntp-mode-6-cmds-09 - IETF stream Control Messages Protocol for Use with Network Time Protocol Version 4 (Informational) Token: Erik Kline Amy: I have a couple of Discusses in the tracker; do we need to discuss any of those today? Erik K: The author's been responsive on the mailing lists for all the feedback. Thank you everyone for viewing. If there's a bit of time, it might be worth discussing one or two points. This document is a bit unusual in that it's bringing forward and updating an appendix from NTPv3 that was essentially not dealt with at all in NTPv4, between 1305 and 5905. 5905 references mode 6 commands but it nowhere really goes into detail about what those are. Apparently there have been some new commands added in the meantime, but it's also not been updated, as Ben notes. The authenticator is particularly old. This document does not propose to go back and fix any of it. The question of Historic status vs Informational came up in the WG. I don't know if folks have thoughts here on what's the best status for this kind of situation? The WG was originally targeting Historic and during Last Call folks pointed out that it's still being used, we don't have a replacement, etc, and there are implementations that actually implement this. Barry: Is it still being used only in the context of RFC 1305 or is it being used in more recent versions? Erik K: It's being used with NTPv4. Eric V: Karen is here on the call and can answer. Warren: It seems like this is still being used so it's better to have it documented and clear instead of not. If Karen's got something useful to say we should ask her. Karen O'Donoghue: This document has sort of a tortured history. There is one person who really wants it to be Standards track, one person who really wants it to be Historic, and most people think Informational is a good compromise. It is still being used in the context of NTP-D implementation. That is the most widely used implementation at this point. It's used, it's evolved a bit, but we had sort of struggled with what the right answer is. In my latest email on this subject I punted and said I was looking for IESG guidance. Warren: Has anyone considered Experimental? Barry: That would be inappropriate, I think. Martin D: I was going to say, what about the ISE? Is there IETF consensus that this is a good design, or are we just documenting what there is, what is happening out there? Ben: We can publish an Informational document with IETF consensus that this is useful information, without saying it's a good idea. Karen: I thought that was what we did. Part of the issue is that RFC 1305 was Standards track, and this was an appendix in RFC 1305, so you can debate if that piece was standards track or not, but it was an oversight that it was not included when we published NTPv4. When this effort first started we thought we'd just correct a mistake we made and publish the material we left out, and as happens when you take too long to do something, all of these other considerations come into play. Barry: Given that discussion, Informational sounds like the right thing and it would be useful to add some text in the introduction that says while these things are still in use, they're not recommended for new implementations. There is something to that effect but maybe making it clearer that they are still in use but that use has faded. Warren: But don't new implementations still have to do this if they want to interact with existing implementations? Isn't it more that this is still in use, and we acknowledge it's a bad idea, but what are you going to do? Karen: It's more of a management piece. It technically can make changes but nobody uses it that way, they use it to gather data. In the real world perhaps you'd be using SNMP but people don't really monitor their NTP instances using SNMP that much. Barry: Maybe a sentence or two to clarify the situation and keep it Informational. It sounds like if it's still in current use Informational is right and not Historic. Ben: Barry, would you have a stance about having it Informational as NTP control mode packets vs the Network Time Foundation's NTP implementation of control mode packets? As far as I can tell from the list discussion, that's the only one that implements it. Barry: I'm not sure how I would spin that. They leak, they're not just in that one organization, right? Karen: Right. The challenge is that a number of promotional products base their products on the NTF Foundation's implementation of NTP. On the one hand you could say it's just this single open source implementation out there that people can go and get, but it's the one that's been around the longest and therefore it's embedded in the most products. Ben: In some sense it's the de facto reference implementation, even if it's debatable that we call it the reference implementation. Karen: Please don't use that word. Barry: Thats why I think it belongs in the IETF stream and that Informational is appropriate. Just a sentence or two to make the situation clear is all that's needed. Warren: Does anyone strongly object to it being Informational and tossing in an extra sentence? Ben: Yes, if you phrase it like that I will strongly object. I think we need to also wordsmith the bits in the text that talk about it being Historic as well, and that's more than a single sentence. Karen: Okay. But with that, if we did all the appropriate wordsmithing, you think Informational? I think we can do the wordsmithing if we just get a final answer on Informational vs Historic. Murray: There was one aspect that caused me to ballot Discuss and that was that this is all plugging into RFC 1305, which is NTPv3, but the title of this is version 4. If we're going to make clarifying text it would be nice to tease that out as well. Karen: Right, okay. Ben: And part of my Discuss is that it has normative dependency on some of the procedures from 1305 so we need to clear that up and make it self contained as well. Or, refer to the modern NTPv4 authentication mechanisms and stuff. Erik K: That might also be a critical change. Roman: That's the opposite of making it self contained, is it not? Ben: We need to not be depending on things that are obsolete. Roman: Karen, where do folks that write the code now get their security guidance from? Are they pivoting to the v4? Karen: NTPv4 is the de facto implementation that's out there now. That's what everybody is using. The question is whether you say are people moving to NTS or are they using the 5905 stuff. Erik K: NTS has only just been published, right? Karen: Right. It's technically not quite published yet. Ben: I thought NTS did get published. Karen: No, it's in the RFC Editor queue. It's getting there. Erik K: I think Ben's Discuss about various BCPs that we should consider, my understanding is it would be revising the protocol. Swapping out the supporting algorithmic agility, supporting a different authenticator, more space for the authenticator, some mechanism to avoid the replay attack, that's all new work. Ben: I don't really know what people are doing. It seems likely that people took the mode 6 logic from v3 and forklifted it into the v4 code base. That would suggest that the v4 authentication mechanisms are actually what's being used, but I don't remember seeing a clear answer to that on the list yet. Karen: I don't have a clear answer to that question. I think what you're really saying is this either needs to go back to the WG to be properly updated and fit into v4 and be published as Informational or it can be published as Historic. Ben: That's my sentiment. Karen: If we're just going to put a couple of sentences in and fix the language, that's not a big effort, but I think making sure that we've updated all the authentication mechanisms appropriately and it adequately reflects what's in 5905 is a bigger effort. Warren: One of the things we need to try and figure out is which is more important, getting the document published so people can understand and read it, or getting it properly polished and resolving all the outstanding issues and making it perfect? Karen: The thing is, just to further muddy the waters, the thing complicating this a little bit is the history of how 5905 got published. We've been dancing around doing the NTPv5 and cleaning up a number of problems that we created for ourselves in the process of doing NTPv4, this being one of them. At the time the NTPv4 was published there was really only the Network Time Foundation public implementation so everything was basically what they said. Since then there have been a number of other implementations that have come along that have caused some contention and disagreement about what is and what is not the way NTP should work. This is an artifact of part of those disagreements because the other implementations don't think this should be used. Erik K: Do we know if the community generally uses this particular authenticator? My impression, with virtually no data, was the only safe way to run this stuff was to use IP access control lists, say which machines can get this data, and to effectively run it in read-only mode rather than allow any old person to make changes to the NTP server. Karen: I don't speak for all the implementations of NTP out there, but all of my experience in this stuff has been using it in read-only mode as a data collector. Erik K: Would one option be to go back to the WG and ask if that is the case and reshape the document a bit? Karen: Narrow the scope to read-only? Erik K: To avoid having to essentially redefine a protocol, including all of its security parameters that people don't generally use? Would that satisfy some of your concerns, Ben? Ben: I expect so. I was going to ask if we think the editor has the energy to make those changes or if they're just pushing to get it done. Karen: The editor is very cooperative. He's easy to work with. Ben: That was the sense I got. Roman: Maybe if I can try to channel all of the input. It seems like we have a couple of options and please correct me if I have it wrong. We can simply write down what we'd hoped to write up and call it Historic, with the caveat that what we have written down, we're just writing down, but no one uses it the way we are describing it. That's one option. Option 2 is we're going to call this document Informational, we realize there are some holes, but this is describing how people are actually using it in the real world . Option 3 is this is Informational and it's describing not only how people use it, but here are some protocol changes as well that harden it. Is that fair in terms of the options we threw out on the table? Erik K: That's my understanding, thank you. Roman: Personally I think option 2 may be the happy medium, which again is bring it back, let's not try to necessarily fix it, let's bring in the operational practices that are currently used to harden, this may not be enough but it's documenting the real world right now. I could get behind an Informational if it's written like that. Ben: I could get behind an Informational written like that. Even if the security story is pretty lousy, with the caveat that we document the ways in which the security story is lousy, Informational is what people do even though we know it is not perfect. Erik K: The security section already documents a number of weaknesses, yeah. When you say bring it back, do you mean bring it back to the WG, or just continued work with Brian and on the list? Roman: I guess it comes down to if we need WG consensus on those practices. I don't have a sense of how controversial those practices are, to get those written down. That's the discriminator for me. Erik K: Karen and I have a sync tomorrow; we can discuss at that time whether it really does need to go all the way back to the WG or not and if it does I'll request that. Otherwise we can try to carry on processing feedback with Brian. Martin D: So if this is IETF stream, should these things be in IANA registries, all these code points and so on? Erik K: The mode grammars are. You're saying it does actually create an IANA registry for some stuff? Martin D: There are tons of code, and four or five different tables here that it would seem have IANA implications, in section 3. Erik K: That's an interesting question. Again, I think the history coming from the code I don't know what it would mean to file IANA requests for all this stuff. Karen, do you have a thought? Karen: No, not really. Erik K: We can continue to iterate on that. Karen and I can talk tomorrow or later today about how to handle whether we're bringing the document back to the WG or whether we can just iterate on the feedback from this telechat. So is that AD Followup? Amy: Yes, I think since you're not sure where it's going to go from here, AD Followup is appropriate. 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-atkins-suit-cose-walnutdsa-00 IETF conflict review for draft-atkins-suit-cose-walnutdsa draft-atkins-suit-cose-walnutdsa-05 Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) (ISE: Informational) Token: Benjamin Kaduk Amy: I have a Discuss in the tracker; do we need to discuss that today? Ben: I do want to talk about this, not least because there's a proposed IESG note and I didn't spend a huge amount of time wordsmithing it and I wanted to double check that people had actually looked at it. I'm also sympathetic to Roman's point that we should at least consider explicitly disclaiming any stance about the validity of the claims that are made. There was a little email discussion with Adrian about being careful about the wording of this. My stance here is that I plan to basically accept the spirit of the change but we'll need to wordsmith it a bit more, possibly in conjunction with some wordsmithing changes to the document itself. I don't know if that means we should approve the conflict review with the expectation that there will be more wordsmithing on the IESG note, or if we want to hold it in IESG Evaluation fora bit longer to make sure it settles down and we have the IESG agree with the final version of the note. Roman: That's the process question I wanted to ask as well. I just wanted us to talk about that. I'm not convinced my words are right but I wanted to talk about putting that extra shim in. Process wise, should I clear my comment and we work on it, or what do we do? Ben: I'm open to putting extra shim in there. Given Adrian's comment I'm not sure if we should be consulting the IETF lawyers. Alissa is probably not here yet, right? Roman: I don't think Adrian was implying lawyers, I think he was implying just more precision, is how I read it. It looked like he was open to shim language like this. I thought he was poking more at the claims of post-quantum secure vs resilient. Since we're taking no position on the claims, we're not going to guide what those claims are. Ben: Right. I was not interpreting Adrian's remarks as definitively you should check with the lawyers, but it did make me wonder. Alissa: I don't think we need legal advice about this but should it really be the IETF that's not taking the position, or the IESG since it's an IESG note? Ben: When I was writing there was at least one spot when I used IESG as opposed to IETF. 'The IETF has chosen,' 'the IESG believes.' I don't have a consistent usage in the current text. Warren: While you're figuring that part out, I have a question on how strong of a smackdown this sounds. If instead this sort of comments was folded more into the document, would we be happy without the response? If instead of us saying you've got this document, we take no position on whether or not it's right, if the document itself had something that it was unclear if everyone thinks it's right, if that would change things. Ben: Funny you should mention that, since Adrian asked me a similar question. I'm open to that possibility but I haven't had a chance to think about it very hard in terms of what that would look like to be in the document vs as an IESG note. Warren: The IETF or IESG takes no position on a thing sort of always sounds like we don't agree with it. Even though we explicitly say we take no position, the fact that we feel the need to not take position carries some sort of implication. Ben: In this case it's true, we don't really agree with it. Roman: The origin of why I was shimming that in is that where we previously had national crypto kinds of things, they'd very often say in the abstract that this wasn't IETF position but we're publishing here for code points. That's the analog I had, because this wasn't in the text I wanted to make sure it was somewhere. Ben: I appreciate that you have done so, because it should be somewhere. Roman: Process wise, do we have do decide this now? Can we continue to iterate somehow in this not-decided state? Ben: I was just going to propose that we leave this in IESG Evaluation and bring it back next time. Warren: If Adrian has something useful, maybe he can contribute. Ben: I'll ask Adrian if he's comfortable waiting another couple of weeks to get something back. Adrian Farrel: Sure. I'm much more enthusiastic about you working on getting the right text that makes you happy than I am about progressing this in the next two weeks. I would say I believe it looks better if the document can go with the right text in the document than having an IESG note. I think that typically looks politically better but it's also more likely to be read. I would hope that if we can come up with text that addresses all the issues and goes in the body of the document, that's a better thing. But if we can't do that, then I'm quite supportive of the note you've got modulo the changes under discussion. Roman: So as the Discuss holder, I think we can work out prose that we can put in the body of the text. To me, whether it's in the body or a note, I'm fine either way. Ben: So I guess we should leave this in IESG Evaluation and think harder about the text. Amy: Did you want to automatically put this on the agenda for September 10? Ben: Yes, let's go ahead and do that to make sure we keep it on our mind. o conflict-review-turner-sodp-profile-00 IETF conflict review for draft-turner-sodp-profile draft-turner-sodp-profile-07 The SODP (Secure Object Delivery Protocol) Server Interfaces: NSA's Profile for Delivery of Certificates, CRLs, and Symmetric Keys to Clients (ISE: Informational) Token: Roman Danyliw Amy: There are no Discusses in the tracker, so unless there's an objection now it looks like this conflict review is approved. Roman: Ben, I just wanted to make sure since we were talking about this. Sean is ok with the text I have there, does that clear it up for you? Ben: I believe so. I'd added a note at the top of my working copy for my comments that are not in the datatracker yet because I still have a page left to go in the document. Hopefully it'll be ok if I sneak my comments to the datatracker in the next half hour. I think this is the right conflict review response and your proposed text sounds good. Roman: Ok. Amy: It sounds like this conflict review is approved. 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 NONE 4.2.2 Proposed for approval NONE 5. IAB news we can use Alvaro: Nothing new this week. 6. Management issues 6.1 [IANA #1175759] renewing early allocations for draft-ietf-bess-evpn-igmp-mld-proxy (IANA) Amy: This is renewing an early allocation that is going to expire next month. Martin V, did you want to speak to this? Martin V: Just that this document is about to finish WG Last Call so it's renewing for just a couple of months. The document is well on the way. Amy: So it sounds like you're advocating to renew this early allocation? Martin V: Yes. Amy: Is there any objection to renewing the early allocation for this document? Hearing no objections, so we'll get note sent to IANA. 6.2 [IANA #1175809] Upcoming Parameter Expiration: Early IANA Allocations for draft-ietf-idr-segment-routing-te-policy (IANA) Amy: This is another early allocation that's due to expire in early October. Alvaro, did you want to speak to this? Alvaro: There are implementations in progress for this. IDR has a policy that we need implementations before the drafts go forward, so it's not ready for WG Last Call but hopefully before the end of the year it should happen. Amy: Is there any objection to renewing the early allocation for this document? I'm hearing no objections, so we'll get note sent to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Eric V: Just want to say that the INT area is currently running a call for adoption for SOCKS v6, which is the 1996 evolution of the SOCKS v5, mainly to improve the TCP opening by sending early data. It's currently in INT Area, I don't know why, but there's impact as well on Transport and maybe Security. Ben: Do we still need SOCKS versions if we have MASQUE? Eric V: That's a very good question. It just happened today, the call for adoption, and it's only one technical university in Bulgaria doing it. They've done INT Area presentations mostly every IETF meeting. So honestly if nobody is shouting that we need to adopt it, I'd say don't adopt it. I don't know whether Transport or Security, you want to say anything else. Ben: We can probably send a heads up to SAAG just to increase the visibility. Eric V: That would be cool. Okay, that's it for me.