INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2019-12-19 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 Roman Danyliw (CERT/SEI) / Security Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Wes Hardaker (USC/ISI) / IAB Liaison Ted Hardie (Google) / IAB Chair Benjamin Kaduk (Akamai Technologies) / Security Area Suresh Krishnan (Kaloom) / Internet Area Warren Kumari (Google) / Operations and Management Area Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area Alvaro Retana (Futurewei Technologies) / Routing Area Adam Roach (Mozilla) / Applications and Real-Time Area Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area Eric Vyncke (Cisco) / Internet Area Magnus Westerlund (Ericsson) / Transport Area REGRETS --------------------------------- Ignas Bagdonas (Equinix) / Operations and Management Area Michelle Cotton (ICANN) / IANA Liaison Jay Daley / IETF Executive Director Heather Flanagan / RFC Series Editor Mirja Kuehlewind (Ericsson) / Transport Area Alexey Melnikov / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat OBSERVERS --------------------------------- Chris Box Jacob Holland Greg Wood 1.2 Bash the agenda Suresh: I sent a mail requesting expedited processing; is that usually a management item? Amy: Yes, I believe it is usually a management item. Suresh: I sent an email; can you add it? Amy: Is this for the lpwan document? Suresh: Yes. Amy: I'll get that in the Datatracker as a management item. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes of the December 5 telechat being approved? Hearing no objection so we'll get those posted. Does anyone have an objection to the final narrative minutes of the December 5 telechat being approved? Hearing no objection so we'll get those posted as well. 1.4 List of remaining action items from last telechat o Roman Danyliw to draft text to be posted on ietf.org about reporting protocol vulnerabilities via an email alias and possible procedures on how to assign triage resources. Roman: That's still in progress, thank you. o Eric Vyncke to write up draft text for the NomCom to help them understand the rules for the NomCom. Eric: The text is written but I still need to make it published, so keep it in progress. o Alexey Melnikov to think about how to analyze how successful WGs and protocols are and why they failed or not. Amy: Alexey could not be here today so we'll mark that in progress for him. 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: In progress. o Alvaro Retana with Warren, Alexey, Martin, Barry, and Roman 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, authors or chairs. Alvaro: This is still in progress, just like any other one that I'm up for. Eric: On this action item, the AD can have the ball as well, not just authors or chairs. Right? Amy: So you want to add ADs in this? Eric: It seems sensible. Amy: We'll make a note, thank you. o Alexey Melnikov and Warren Kumari to add keyword tags to WG charters to identify specs that pertain to some general concept. Warren: Still in progress. o Alvaro Retana to work on a framework for analyzing new proposals. Alvaro: In progress. o Adam Roach to work on a virtual social room for remote attendees (promoting #hallway) Adam: In progress, as well as my other one. Warren: If you want to write something up we can put it on the affiliates page. It kind of fits within that sort of social hangout type thing. So a paragraph or some sentences we can point to. Adam: Are you thinking like for creating a mailing list, or it goes on the same page because it has the same general feel to it? Warren: I was just thinking to stick it on the same page because it has the same general feel. We'll put in a little blurb explaining one of these things is not like the other. Adam: That's a good idea, thank you. I appreciate it. o Warren Kumari to work on acknowledging shepherds, directorate reviewers in a more standardized/formal way. Warren: In progress. o Alexey Melnikov to organize IoT overview discussion with interested ADs. Amy: Alexey could not be here today so we'll mark that in progress for him. o Ignas Bagdonas to write a draft of an IoT Systems charter. Amy: Ignas could not be here today so we'll mark that in progress for him. o Alexey Melnikov to find designated experts for RFC 8620 [IANA #1155192]. Amy: Alexey could not be here today so we'll mark that in progress for him. o Alvaro Retana and Adam Roach to look at updating the I-D Checklist. Alvaro: In progress. o Roman Danilyw to find designated experts for RFC-ietf-lamps-cms-mix- with-psk [IANA #1156116]. o Roman Danilyw to find designated experts for RFC 8471 [IANA #1156118]. Roman: These two are still in progress. o Eric Vyncke to write up draft text on Special Interest Groups and send to the IESG for comment. Eric: Still in progress. o Warren Kumari to write up draft text on Affiliate Groups and send to the IESG for comment. Warren: I did something! You can mark this done. o All IESG to submit their metrics data priorities to Roman (deadline TBD). o Roman Danyliw to collect feedback from the IESG on the metrics data priorities for the IESG to discuss at a future meeting. Amy: I saw email for this and you have a deadline of January 16. Roman: The next action is that I'll synthesize whatever has come in by then. If people think that's not a long enough deadline, let me know. o Ben Kaduk, Alvaro Retana, and Suresh Krishnan to skim the ietf@ietf list and collect a list of topics that seem to be the major concerns for the community from recent discussion threads. Ben: Let's keep that as in progress. o Martin Vigoureux to put together a proposal on disambiguating side meetings from IETF meetings. Martin: I can't call that in progress because I haven't started but please keep it there. o Alexey Melnikov to find designated experts for RFC 7193 [IANA #1156270]. Amy: This is a management item for later in the call. o Magnus Westerlund to draft an IESG Statement regarding the IETF as the default change controller for IANA Registration requests. Magnus: In progress. o Suresh Krishnan to draft a "best errata practices" document and post it on the IESG Wiki. Suresh: I'll do that. We had a conversation about this at the last informal. Keep it in progress and I'll write something up to summarize. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-cellar-ebml-15 - IETF stream Extensible Binary Meta Language (Proposed Standard) Token: Alexey Melnikov Amy: Alexey said this would need a revised ID. o draft-ietf-bfd-vxlan-09 - IETF stream BFD for VXLAN (Proposed Standard) Token: Martin Vigoureux Amy: I have a number of Discusses here. Do we need to discuss any of those today? Martin: Maybe we could, but as I said in jabber I'm not in an excellent position to do so. Let's try. I think Ben, you had a specific point you wanted to discuss on the configurability of the management VNI. Correct? Ben: Right. I think I had two numbered Discuss points. Martin: I remember reading you wanted to discuss this one specifically on the telechat but if you want to discuss more, I'm fine with that. Ben: Sure. I think for both of them, I don't actually know what the right thing to do is, so I rely on the rest of the IESG to give us some hints as to what the right thing to do is. For the particular management VNI configuration, I don't know that it was as much about needing to configure the specific number of the VNI that is the management VNI so much as whether the concept of the management VNI was already something that was specified. Martin: The thing is that it doesn't exist. Part of the issue here is that VXLAN is not an IETF technology. The specification on which we rely is an informal one; it was kind of a de facto standard that was described during an IETF. At that time, there was absolutely no registry defined for VNIs and so on. And I'm not aware of any outside of IETF. So we are a bit in a tricky situation, where some implementations rely on VNI zero, some don't. So I'm not sure I have an easy answer to the problem. Ben: I don't think I have an easy answer either, although I do perhaps have a potential answer; which would be to attempt to adopt the VXLAN specification itself into the IETF stream and publish a new revision of it, which perhaps could include some additions or modifications regarding the management VNI. But then this document would have to wait until that document was complete for us to go forward, and that's obviously not a great situation to be in. I was hoping someone else on the IESG might have some thoughts to share. [long silence] Martin: Apparently not! Do you think we really need to move the VXLAN into the IETF as a standard track document? Maybe we could define a registry, considering it has been used the first time, and start using it from now on? We don't necessarily need to make it standards track. Ben: I don't think we necessarily need to; that's a heavy hammer and I don't have a clear sense that it's needed here. Perhaps it's worth asking Adrian how he would feel about us making a registry for the ISE stream protocol, just so we're not stepping on anyone's toes. Martin: We can check that. Ben: Part of why I don't know what to do is that we don't have a clear single definition for what it means to update another document, so using some of the definitions people have this doc would need to update the other doc, but not using all of the definitions of update. There's not really a clear answer. Given the apathy on the call right now, maybe we're just going to ignore the question and let this document go forward, possibly with a registry but possibly without. Martin: So you hold the Discuss; it's up to you to decide what's the preferred way. I don't have a strong opinion. Ben: For the particular point I mostly just wanted to try to get broader feedback on the topic, but I don't think it's a blocking point. I think we can say we discussed it and we don't have a better proposal than what we're currently doing. If we can move on to the other point, I think Adam had pointed out something interesting I didn't get to look into. Apparently as IETF we have the ability to reserve a special-use IP address, and I didn't have a great sense on what the inherent restrictions on how those can be used and the guarantee that other nodes would not be attempting to route or process packets using those addresses. From some sense that seems like the most appealing route to make progress on this, in terms of being able to keep the broader monitoring properties that some of the WG members wanted, but still having a fairly robust guarantee that the identifiers in question will not collide with the tenant identifiers. Martin: I myself wasn't fully aware of that capability. It looks quite appealing, thanks Adam. I can try to bring the author to this idea. Ben: Adam, was there anything else you wanted to tell us about that approach? Adam: No, I have a question pending for the authors about what they're trying to achieve here. If they want to make certain it's not ever leaving this router if a tunnel is broken, or if it just doesn't have a valid destination. What they're trying to do doesn't really do either of those very well. If we're just trying to find something not routable, I'd think that if we were to put in a null address, like all zeros, which I believe in both v4 and v6 is a "this is not an address" address, then that probably gets to what they want as well without burning a code point. But like I said, I'm still a little unsure what they're trying to achieve here. I think we need to hear back from them before we suggest a concrete route. Eric: They were talking about adding entropy as well. Entropy into the overlay is quite useless. Warren: In v4 there's 0/8 which shouldn't leave the local network, but might. 169254 in v4 space seems like it would do a bunch of what they want and that needs to be confirmed. But I'm also not quite sure what they're trying to accomplish. I tried following their discussion and got lost midway through. Martin: I have to admit it is not always easy to develop a good understanding of what some authors have in mind and I have struggled myself. Let's explore that before effectively taking a decision. What you were proposing, Adam, was interesting. So I don't want to jeopardize the whole call with that document; there are other very important Discusses but I've seen the authors have engaged with you. It's not clear right now where we're going but I want to let the discussion go a bit before stepping in. Thank you very much. Wes: From a routeability point of view, with my operator hat on, I get an amazing amount of addresses reaching me that are not supposed to be routable. Looking through some requests in my archive, I see some arriving from 0000. Warren: The question is was that intentional. It would be useful to figure that out. Wes: My point was that if you want packets not to leave a box, good luck. Warren: It's also possible those were hand-rolled packets, not done through a normal API form. Adam: When you say "from" are you referring to the destination or the source address? Wes: Source. Adam: This is the destination address they're discussing. I can't imagine how a packet addressed to 0000 would route to anyone's network. Wes: Well, it depends on how you have anyone's network configured. But it might leak if someone has their network set up in strange ways. Adam: Thanks. Martin: In any case, it will be Revised ID needed for that document. Amy: Thank you everyone. o draft-ietf-ace-coap-est-17 - IETF stream EST over secure CoAP (EST-coaps) (Proposed Standard) Token: Benjamin Kaduk Amy: I have a number of Discusses here. Do we need to discuss any of those today? Ben: No, I don't think so. I think we should wait for the authors to respond. The primary author had a recent change of affiliation so may be a little slower than usual. Amy: Is this going to require a Revised ID? Ben: Yes. o draft-ietf-tls-certificate-compression-08 - IETF stream TLS Certificate Compression (Proposed Standard) Token: Benjamin Kaduk Amy: There are no Discusses in the tracker. Eric, did you want to state a position? Eric: No, I haven't read it yet. Amy: Okay. So unless there's an objection now, this one is approved. Ben: Let's put it in Point Raised, please. Amy: I also have downrefs for this document; we'll be adding RFC7932 and RFC1950 to the downref registry when this is approved? Ben: Yes, I think that's the right thing to do. Amy: This will go into Approved, Announcement to be Sent, Point Raised. o draft-ietf-bess-nsh-bgp-control-plane-13 - IETF stream BGP Control Plane for NSH SFC (Proposed Standard) Token: Martin Vigoureux Amy: I have a couple of Discusses here; do we need to discuss those today? Martin: The author has been pretty responsive. I didn't see anything unresolvable, so I'll let him continue to do the talking and if needed I'll jump in. But if any of you want to discuss now, I'm fine. Ben: I had this thing about the strategic direction of the SFC architecture, which is kind of wishy washy and not my area of expertise. Has this already been talked about a lot and explicitly taken, or if this is just something we're picking up as a consequence of this document? Martin: I don't think the document breaks anything in the SFC architecture. However, I agree there are some things we could call differences. The authors have argued that we should consider our document as a superset on the functional point of view. I have mixed feelings about that but we don't break anything. Maybe it could be clearer that the document departs a bit from the architecture, in the sense of being a superset from what the architecture specifies, but beyond that I'm not sure what else is needed. Ben: So it sounds like you think we should wait to see what the authors come back and reply with. Martin: Yes. They'll likely say that, because they're already saying that to me when I made the same comments. We'll see. Ben: Thanks. Martin: This will require a revised ID, I believe. o draft-ietf-mboned-driad-amt-discovery-11 - IETF stream DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery (Proposed Standard) Token: Warren Kumari Amy: I have a Discuss; do we need to discuss that today? Warren: I guess if we have a minute. The authors replied some time last night. Suresh: I looked at the new version. I'll clear. Warren: I think the author is going to incorporate some other comments so once that's done it should be okay to progress. Adam: Warren, there's a conversation I'm still having with the authors about Figure 2. They might be coming up with a revision to that. I'd at least double check with them on that point first. Warren: Okay, let's leave it in Point Raised and then once Adam's happy we can clear it. o draft-ietf-6man-ra-pref64-08 - IETF stream Discovering PREF64 in Router Advertisements (Proposed Standard) Token: Suresh Krishnan Amy: There are no Discusses in the tracker, so unless someone has an objection now it looks like this is approved. Suresh: Just put it in Point Raised please. I just want to make sure everything is good. o draft-ietf-nfsv4-rfc5661sesqui-msns-03 - IETF stream Network File System (NFS) Version 4 Minor Version 1 Protocol (Proposed Standard) Token: Magnus Westerlund Amy: I have a Discuss; do we need to discuss that today? Magnus: No, put it in Revised ID Needed. 2.1.2 Returning items NONE 2.2 Individual submissions 2.2.1 New items o draft-thaler-iftype-reg-06 - IETF stream Guidelines and Registration Procedures for Interface Types and Tunnel Types (Proposed Standard) Token: Suresh Krishnan Amy: There are no Discusses in the tracker, so unless there's an objection now it looks like this is approved. Suresh: Please put this in Point Raised as well; I'd like to discuss with Michelle. 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-tls-tls13-cert-with-extern-psk-03 - IETF stream TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key (Experimental) Token: Benjamin Kaduk Amy: there are no Discusses in the tracker, so unless there's an objection now it looks like this is approved. Ben: Let's keep this one in Point Raised for a bit; we had some ongoing discussion I need to read through. 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-vesely-authmethod-dnswl-00 IETF conflict review for draft-vesely-authmethod-dnswl draft-vesely-authmethod-dnswl-12 DNSWL Email Authentication Method Extension (ISE: Informational) Token: Alexey Melnikov Amy: I have no Discuss points in the tracker, so unless there's an objection this conflict review can go back to the ISE with the notes that are currently in the tracker. Hearing no objection, so this can go back to the ISE. o conflict-review-rundgren-json-canonicalization-scheme-00 IETF conflict review for draft-rundgren-json-canonicalization-scheme draft-rundgren-json-canonicalization-scheme-16 JSON Canonicalization Scheme (JCS) (ISE: Informational) Token: Barry Leiba Amy: I have no Discuss points in the tracker, so unless there's an objection this conflict review can go back to the ISE with the notes that are currently in the tracker. Hearing no objection, so this can go back to the ISE. 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 IP Security Maintenance and Extensions (ipsecme) Amy: I have no blocking comments. Does it need to go for external review? Ben: Yes, it will need to go for external review. But first, what state... Amy: Pending Edits, if you need to edit. Ben: Yes, I want to apply the wordsmithing from Barry and update the dates for the milestones that are currently in the past. Amy: So the external review is approved, pending edits, and you can let us know when you're ready. 4.2.2 Proposed for approval o JSON Mail Access Protocol (jmap) Amy: I have no blocking comments, so unless there's an objection the rechartering is approved. I'm hearing no objection, so we will get that approval sent. 5. IAB news we can use Wes: We are currently pushing forward on creating the conflict of interest draft you guys are waiting for, and you should expect to see a draft of it in the not too distant future. 6. Management issues 6.2 Designated Experts for CMS Encapsulating Content Types and CMS Inner Content Types (RFC 7193) Amy: Alexey has identified Russ Housley and Sean Turner as the designated experts for these two registries, with the possibility of adding a third in the future. Is there any objection to naming Russ and Sean as experts? Okay, we will get official note sent to IANA. 6.3 Requesting expedited processing for draft-ietf-lpwan-ipv6-static-context-hc-24 Amy: Suresh is asking for approval to request expedited processing from the RFC Editor. Ben: Suresh, did you see there was some discussion on the lake WG about how this document is not very clear that the header compression portion is somewhat separable from the ipv6 translation layer. I don't know if you saw that. [Note: This discussion was actually on the TLS list.] Suresh: I haven't seen it; I'm not on the lake list. I'll find it. There's another document which is also in process so I'm not sure if it's related to this one or that one. If you can send me the link, otherwise I'll check the lake list. Eric: Out of curiosity, is it to reuse the mechanism from this document to another purpose? Ben: Someone had proposed that the header compression mechanism might be useful for a cTLS type scheme to minimize the size of the messages. But of course if you just need the compression part you don't need the fragmentation and reassembly. Eric: Thank you. It could also be applicable to the compression part of ipsecme. Ben: Yes, I think I saw your note on the charter. Suresh: The draft name doesn't show me any hits on lake mailing list, but if you send me something I'll take a look for sure. Was that a concern about the content of this draft? Ben: I think there was a suggestion that there might be an editorial tweak to reflect that the header compression is usable outside of the immediate context that it's being defined for. Suresh: Okay, excellent. Do you want to hold off on this until that's done, or do you want to do this in parallel? Ben: We should be able to do it in parallel. Suresh: Okay, so I'll make myself a note to check in with you by tomorrow. Ben: I'll try and do it right away. Amy: Okay, I'm hearing no objection to approving the expedited processing, so we'll move on. Thank you. 6.1 Executive session: Invitations for leadership training 7. Any Other Business (WG News, New Proposals, etc.) Amy: I wanted to remind you all that the Secretariat will be on winter holidays from December 24 through the new year. We'll check email sporadically but if you request last calls within that window it might be delayed, so keep that in mind. You have an informal telechat scheduled for January 2 but it's up to you to fill an agenda if you want to have it.