INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2018-09-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 Ben Campbell (Oracle) / Applications and Real-Time Area Alissa Cooper (Cisco) / IETF Chair, General Area Michelle Cotton (ICANN) / IANA Liaison Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Ted Hardie (Google) / IAB Chair Benjamin Kaduk (Akamai Technologies) / Security Area Suresh Krishnan (Kaloom) / Internet Area Warren Kumari (Google) / Operations and Management Area Terry Manderson (ICANN) / Internet Area Alexey Melnikov / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Eric Rescorla (Mozilla) / Security Area Alvaro Retana (Huawei) / Routing Area Adam Roach (Mozilla) / Applications and Real-Time Area Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area REGRETS --------------------------------- Ignas Bagdonas (Equinix) / Operations and Management Area Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area Heather Flanagan / RFC Series Editor Mirja Kuehlewind (ETH Zurich) / Transport Area Jeff Tantsura (Nuage Networks) / IAB Liaison Portia Wenze-Danley (ISOC) / Interim IAD GUEST --------------------------------- Luigi Iannone (document shepherd for draft-ietf-lisp-gpe, draft-ietf- lisp-rfc6830bis, and draft-ietf-lisp-rfc6833bis) OBSERVERS --------------------------------- Mahesh Jethanandani Mickelly Rodrigues 1.2 Bash the agenda Alissa: I will have to drop after one hour. Warren: I also have to drop after an hour. 1.3 Approval of the minutes of past telechats Amy: Anyone have an objection to approving the minutes from September 13? Hearing none, so those will be posted. I saw slightly revised narrative minutes, any objection to approving those? Hearing none, so those will also be posted. 1.4 List of remaining action items from last telechat o Suresh Krishnan to find designated experts for RFC-ietf-6tisch-6top- protocol [IANA #1119883]. Suresh: Still in progress. Amy: The next are all for Ekr who I don't see in the Webex, so hopefully he knows those are still there for him. We'll move on. o Eric Rescorla to find designated experts for RFC 8411 [IANA #1120853]. o Eric Rescorla to find designated experts for RFC 6509 (mikey-payloads) [IANA #1121057]. o Eric Rescorla to find designated experts for RFC 6043 (mikey-payloads) [IANA #1121239]. o Eric Rescorla to find designated experts for RFC 6267 (mikey-payloads) [IANA #1121240]. o Eric Rescorla to find designated experts for RFC 6309 (mikey-payloads) [IANA #1121241]. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-opsawg-nat-yang-16 - IETF stream A YANG Module for Network Address Translation (NAT) and Network Prefix Translation (NPT) (Proposed Standard) Token: Ignas Bagdonas Amy: Ignas could not be here today. I have no Discusses so unless there's an objection it looks like this one is approved. I'll put it in Point Raised so he can do his final checks. o draft-ietf-tram-stun-pmtud-10 - IETF stream Path MTU Discovery Using Session Traversal Utilities for NAT (STUN) (Proposed Standard) Token: Spencer Dawkins Amy: Spencer unfortunately could not be with us today so all the folks with Discusses are going to have to take it up with Spencer offline. I'm guessing these probably require a Revised ID? Adam: Based on the conversations with Spencer it might not be a Revised ID, it might just run through the process again, but we'll have to hear from Spencer before we make that call. Amy: This will go into IESG Evaluation, Revised ID Needed, and we'll let Spencer make that call. o draft-ietf-netconf-nmda-restconf-04 - IETF stream RESTCONF Extensions to Support the Network Management Datastore Architecture (Proposed Standard) Token: Ignas Bagdonas Amy: There are no Discusses in the tracker so unless there's an objection it looks like this one is approved. Hearing none, this is approved and as he is not here we'll put it into Point Raised and he can follow up and make sure all final checks are done. o draft-ietf-netmod-acl-model-19 - IETF stream Network Access Control List (ACL) YANG Data Model (Proposed Standard) Token: Ignas Bagdonas Amy: I have quite a number of Discusses in the tracker and unfortunately Ignas isn't here to discuss them. Do we think this is going to require a Revised ID so Ignas can pick this up when he's back? Suresh: Yes, for sure. Amy: Okay, this will stay in IESG Evaluation and go to Revised ID Needed. Ted: On the point Alissa raised, there's an IETF/IEEE coordination meeting later today. Do we want to get this in front of one of the people who will be on that call? Alissa: I had sent mail to Dorothy and Russ and the person who was on the IEEE side previously listed as owner, four or five days ago and I didn't get a response, which is why I put it in my ballot. I'm going to have to miss that call so if someone who's going to join the call can take an action to bring this up I'd appreciate it. Suresh: I'll be there; I'll take it up. Ted: I have a memory it's tracked but if you could reconfirm that would be great. Alissa: I looked at the minutes from the last meeting and it's ambiguous if they were going to start work on it or not. o draft-ietf-netconf-nmda-netconf-06 - IETF stream NETCONF Extensions to Support the Network Management Datastore Architecture (Proposed Standard) Token: Ignas Bagdonas Amy: It has no Discusses in the tracker so unless there's an objection it looks like this one is approved, to go to Approved, Point Raised. o draft-ietf-ospf-segment-routing-msd-21 - IETF stream Signaling MSD (Maximum SID Depth) using OSPF (Proposed Standard) Token: Alvaro Retana Amy: I have one Discuss in the tracker. Alvaro, do we need to discuss that today? Alvaro: I don't think we do. We're just waiting for an update, so we'll definitely need a Revised ID for this. Amy: This will go into Revised ID Needed. o draft-ietf-isis-segment-routing-msd-17 - IETF stream Signaling MSD (Maximum SID Depth) using IS-IS (Proposed Standard) Token: Alvaro Retana Amy: It has no Discusses in the tracker so unless there's an objection it looks like this one is approved. Alvaro: We'll also need a Revised ID for this one. Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed. o draft-ietf-softwire-mesh-multicast-23 - IETF stream IPv4 Multicast over an IPv6 Multicast in Softwire Mesh Network (Proposed Standard) Token: Terry Manderson Amy: It has no Discusses in the tracker so unless there's an objection it looks like this one is approved. Terry: Approved, Point Raised. The authors look like they're on the ball but I just want to double check they've covered all the comments. Amy: Great. This will go into Approved, Announcement to be Sent, Point Raised, and you can let us know when it's ready to go. o draft-ietf-dnsop-kskroll-sentinel-15 - IETF stream A Root Key Trust Anchor Sentinel for DNSSEC (Proposed Standard) Token: Terry Manderson Amy: I have a Discuss in the tracker. Do we need to discuss that today? Terry: I think we do. Not specifically on the Discuss item, but tangentially to an issue that is raised as a sidebar: what we're going to do with regards to reserving left hand side labels in domain names. Adam, you had lots to say. Adam: I did and I said most of it in email. I raised this issue when the MTSTS draft went through and I think it's as applicable here as it is there, which is: it seems problematic to start taking names out of delegated name spaces when historically this is something we've left to operators. I pointed out parallels to what we've done with BCP 190 for HTTP when we say we're not going to standardize use of URL components with the exception of this well defined space. It seems like it might be a good idea to start a similar policy in DNS. The email back and forth was converging, I think, on the idea that maybe we could do something like that. I'm not sure how much appetite there would be to pursue this. Warren made a comment that there might not be stomach in DNSOP to take on a work item along these lines. I think it is a place where we could use some clarity and guidance. I don't know if this is a recent thing where we've had two docs come through as a fluke, back to back, that tried to do this sort of thing or if we're starting to see use cases where this is going to become necessary and having a well organized and partitioned part of the namespace to do this in would be helpful. Warren: We had a reasonable amount of discussion on this in DNSOP. According to Stuart Cheshire, who wrote the RFC 6761 special use names document, his document allows for reserving special use names anywhere in the tree. In theory, this could be an RFC 6761 reservation. We asked in the WG if people thought this actually counted as a special use name and I was kind of pushing for that. The WG's interpretation of 6761 is different to Stuart's. The WG didn't feel what Stuart thought it said is what they think it said. The WG came to the fairly strong view that it's not a 6761 special use name, which is why there isn't anything in the IANA Considerations section, suggesting it's a 6761 reservation. We have all the text and it was nicely written but the WG asked us to remove it. This is definitely weird and odd. I think it's just a fluke that we've got two of these recently but yes, this is sort of an open wound and it should be dealt with. From my long interaction with DNS on special use I think this falls on the special use names topic. Trying to get anything more done there is just going to end poorly. Even an AD sponsored thing; the topic is so toxic at the moment there's going to be a world of drama. Maybe that's fine. Terry: Warren, do you think a very simple doc structuring a registry to put these left hand side names in one place would be sufficient? Warren: Possibly if it were just that, but it would reopen the question of isn't this what 6761 is supposed to do? It could be a very short clarification document explaining that 6761 either does say this or doesn't. Ted: It's quite sure that we can make reservations anywhere in the tree because IDNA relies on that. We actually reserved with xm-- that portion of the label space for every part of the DNS hierarchy. If that's not going to be considered something you can do through the special use names registry, we have to have a mechanism for doing something in the future or we can never upgrade from IDNA 2008 to something that needs a different Ascii compatible encoding. You'd certainly have my support and I suspect the support of anyone who thinks IDNA might ever need a rev, for documenting that this is a special use name under the meaning of the act. Adam: Quick clarification: IDNA actually reserved any two characters followed by two dashes. Ted: You can use that portion of the name space for the uses you had laid out in your email. I agree with that, that if you want to make ar registry that says these are the uses of that portion of the already reserved name space, you are well within what we've already reserved. The advantage of that is that means we don't have to go back and have ad discussion with ICANN about why we're taking yet more pieces of the namespace they might want to sell. Adam: That's a good point I hadn't thought of. Warren: The xm-- does make a good analogy. That's another spot where it's not a new registry as far as I know. It's another one of these. I think having a doc saying we already have this xm-- space we can use for stuff. Here are two other ones which have already one similar things. there's another example which Andrew Sullivan pointed out where some names are reserved. Somebody a while back also made an analogy: postmaster, hostmaster, etc, are kind of reserved because of the m name convention in DNS, and naming a machine postmaster.whatever would probably end badly. I don't remember where that conversation was. I think it would be useful to have a doc which creates this registry and says we already have this one, you should try and use it. I'm not sure where that leaves us. Terry: I think that leaves us with me asking Benjamin to hold his discuss, and Warren, are you able to follow up with the idea of creating that document which may inform KSK roll sentinel? Warren: I can try and create that document. It's going to be a long thing to get through the DNSOPS discussion. There was also discussion of using xm-- for KSK sentinel and the WG did not like that. I can figure out why if that would be interesting. We suggested underscore and xm-- and the WG got annoyed. Ted: I think maybe a part of the discussion with the WG it would be quite useful to get that pulled out and if they have a belief that that's not deployable for some reason, we really need to know it and to work on what we're going to do about it. If they have an objection that is more aesthetic, let's say, then I think we need to strongly encourage them to consider the advantages that Adam has put forth. Warren: Paul Hoffman had a thing that he thinks it's a bad idea because some software has letterletter-- reserved even though it shouldn't. It seems some software has been stupid and implemented some workarounds. The WG did not like it. We could try again. Adam: To be clear, the issue with the underscore prefixes in this context. Is that limited to not being able to perform these queries from web browsers? Warren: Most implementations will still fetch things, or will still resolve place names that have that. Some implementations, Android and some linuxes, will not fetch things that start with an underscore. Adam: That was kind of the point. You can resolve them but you can't use them as host names. The point of this draft are that you can resolve these. Warren: And fetch resources from them. Somebody needs to fetch the resource so the browser can say whether or not it was able to resolve the name properly. Adam: That was my question. Is the fact that we can't use underscores limited to the fact that we can't use them in web browsers? Is that the only driving factor? Warren: I believe so yes. The whole point of this is that it can be tested in a browser. Benjamin: If I can jump in, Terry, you asked me to hold my discuss. Is that because wee'r thinking this document might change to use whatever new scheme is proposed? Terry: That's where I was heading, but I get the feeling now after Warren's replay that I don't think that's going to change the situation. I think we're at a point here that this label may simply just go through but we will have to do some additional work in dealing with future issues. Benjamin: That's the conclusion I was coming to. I noticed in some of the DNSOP archives that there was grumbling about changing which host names we're using for this multiple times, and there would no doubt be more grumbling if it were going to change again. We may just let this doc go through with the current name. Ted: if you do that you need to follow up on two fronts. One, if this does still need to get registered in the special use names registry, because it is a reservation that other people in the DNS ecosystem outside the IETF need to be aware of it. The second is you need a plan for going forward. Although this seems like a pair of docs coming through that could be coincidence, my gut tells me that if there are a couple of documents that start coming through people are going to begin to see a pattern. Warren: I think everyone recognizes that this is a bad pattern and should not be repeated. Ted: Why are they preferring it? Warren: During the discussions it was that we shouldn't do this but the pain of not doing it in this particular instance outweighs the pain of doing it. Adam: In both of these cases the rationale has been we want to shove this in an https url. I think hat's going to happen more frequently in the future than it has int he past. Warren: I can write an email to DNSOP that we need to figure out what we're doing in the future. This is another looming problem. Adam: What I would prefer to see is an update to 6761 that clarifies that all of these uses are something that should be registered, and also adds both MTASTS and these two patterns to the IANA registry. Warren: I fully agree. I'm happy to push for that. Terry: That seems like a reasonable path forward; let this go through but draw the line here and any future attempts at left hand side reservations will be stopped until we deal with a registry for this. Warren: Sounds great to me. I would still like to remind people that we the IESG still have an open thing that it's unclear what the use of special names status registry means to people. Suzanne was the last person holding the pen on coming up with a clear updated statement. That's a longer topic. Alissa: I think it would be helpful to capture that line drawing in this document. Some words that explain that for future reference. Warren: Do you have any example proposed text? Basically we understand this is a bad pattern? Alissa: The thought occurred to me while you were talking that there are lots of people who understand right now we're only doing this under exigent circumstances, but it's helpful to write that down in the document so when people come along later we can point them to it. Warren: Sounds like a plan. Benjamin: I will continue holding my discuss. Terry: We can move on. Amy: Sounds like this is going to require a Revised ID. Terry: It will require a revised ID, but Benjamin will be holding his discuss until we come up with appropriate text. Amy: Okay, it will stay in IESG Evaluation, Writeup Needed. o draft-ietf-lisp-gpe-06 - IETF stream LISP Generic Protocol Extension (Proposed Standard) Token: Deborah Brungard Amy: I have some Discusses in the tracker, do we need to discuss any of those today? Deborah: I don't think so. I see Luigi is on the call if anyone has anything they want to ask him. Suresh: This doc is taking a flag from LISP; since you're basing the LISP protocol should the flag be acknowledged? Deborah: I don't know, we'll have to look at it. Luigi: On the last comment, I agree yes to update this document. [muffled] We have to solve a couple of things in this document but it looks good looking forward. Deborah: I think we can discuss more over email with the chairs. Amy: Are the current discusses going to require a Revised ID? Deborah: Yes. Amy: Okay, we'll move on. o draft-ietf-lisp-rfc6830bis-20 - IETF stream The Locator/ID Separation Protocol (LISP) (Proposed Standard) Token: Deborah Brungard Amy: I have a number of discusses. Do we need to discuss any of those today? Deborah: I would say not. There's discussion going on on the list; I'd put this as Revised ID Needed. o draft-ietf-lisp-rfc6833bis-16 - IETF stream Locator/ID Separation Protocol (LISP) Control-Plane (Proposed Standard) Token: Deborah Brungard Amy: I have Discusses; do we need to discuss today? Deborah: Michelle added a very late discuss. We'll keep this as under IESG evaluation and Revised ID definitely needed. o draft-ietf-extra-imap-savedate-01 - IETF stream Internet Message Access Protocol (IMAP) - SAVEDATE Extension (Proposed Standard) Token: Alexey Melnikov Amy: I have no discusses in the tracker so unless there's an objection it looks like this one is approved. Alexey: Can I have this in Point Raised please, to make sure the comments are reviewed by the authors? Amy: You absolutely can. 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-dnsop-isp-ip6rdns-07 - IETF stream Reverse DNS in IPv6 for Internet Service Providers (Informational) Token: Warren Kumari Amy: I have no discusses in the tracker so unless there's an objection it looks like this one is approved. Hearing no objection, this is approved. There are no notes; is this ready to go as is? Warren: I believe so; I think there are some editorial things to be cleared up. Amy: This will go into Approved, Announcement to be Sent. Thanks. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items o draft-mahesh-etsi-urn-03 - IETF stream URN Namespace for ETSI Documents (Informational) Note: This is to add ETSI namespace identifier, specifically targeting YANG model development by ETSI. Token: Ignas Bagdonas Amy: Ignas could not be with us today. I have a consensus flagged as Unknown. Do we know if this is going to be yes or no? Warren: I believe it will be yes. Amy: Alexey, do you have a feeling if this is going to be Revised ID? Alexey: I think it probably will be Revised ID. Amy: We can put this in Revised ID Needed and Ignas can follow up as needed. 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 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 o Source Packet Routing in Networking (spring) Amy: The charter version is 01-02. I have no blocking comments for this; unless there's an objection it looks like the recharter for SPRING has been approved. Martin: Alissa, were you okay with my reply to your comment? Alissa: I thought your answer was good. Do you think everybody who reads the charter will have that same understanding? Martin: I'll see if I can tweak the wording in the charter. I'll take a look. Alissa: It seems a little bit ambiguous to me so the more clear it can be for the standards are it will be better. Martin: Okay, I'll see what I can do. Then the next step is to send this for external review, correct? Amy: No, do you think it needs an external review? Martin: I think the original plan was to have an external review. Alvaro: I thought we just did. Martin: This is where I got confused. It went through internally and went in front of us once, then I moved it to external review. Cindy: An external review message was sent on September 10. Amy: I was almost positive that had happened already. Martin: I missed it! We are good then. Amy: It generally doesn't show up as proposed for approval until it's been for external review. If you want to make additional edits, it looks like it's approved pending edits. With that you just let us know when your edits are in the tracker and you're satisfied; then you can send us a ticket and we'll get the recharter message sent. Martin: Excellent, thanks. 5. IAB news we can use Amy: Deborah, any news this week? Deborah: No, I don't think so. 6. Management issues 6.1 Request from the tools team: update id-nits to allow for non ASCII in drafts? (Alexey Melnikov) Amy: Alexey, you added this and sent some text. Alexey: I think after feedback from Sandy it looks like tools will be ready around the end of the year, and then it will take 6-9 months for RFC editor to implement. I see a couple of options; one is to say we'll review in six months, but Robert asked about this because Paul Hoffman wants to publish a draft and at the moment he needs to do manual posting and it's quite annoying. We might want to consider allowing documents with non-ASCII on the condition that if they are going to be approved by IESG for publication then they'll be delayed until the RFC editor is ready. Sandy: Our optimistic goal is to be publishing these documents 6 to 9 months from now, not from December. Alexey: You're suggesting we can move this decision point a bit earlier? One option is to review in 3 or 6 months. Another option is to approve this now on the condition that drafts can be posted with non-ASCII, but if they're approved they won't be published as RFCs unless the editor is ready. Sandy: As long as we're clear that if it gets approved the characters either get reverted if they don't want it to be held or it's going to be delayed until the tools are ready. Adam: My understating is right now if you try to submit a draft to the website it says it won't take it. Alexey: Yes. IDNITS has warnings which would allow you to submit. This is triggered as an error. Adam: I think given the time frame it would be reasonable to demote this to a warning; point out the caveats that if this goes to the IESG before the RFC editor is ready it will be changed or held. When we talk to the tools team about this we want to be careful not just about changing the status of this but look at what characters are triggering it. For a lot of times you end up with smart quotes and em dashes, which we do want to flag and prevent from going in, so we want them to look at the rules in the format documents and allow those things through but block things that aren't allowed by that. Alexey: Yes, I don't think this will help you with smart quotes. The document recommends that you always use unicode code in the text, or a unicode abbreviation. Adam: These things are detectable. It's not as simple a change, I think. Alexey: I tend to agree with you that I think Henrik thinks it's easier than it is. Ekr: Is your thinking that smart quotes are a defect, whereas some other characters are intentional? So we went to flag the things that are probably screws vs the things that are intentional? Alexey: Smart quotes can still be intentional, but they're probably unlikely to be. Adam: They appear in weird places. A lot of the things that didn't match in errata were because the quoted section had smart quotes, so someone had copied and pasted out of an RFC, then on the way to the errata page had managed to turn quotes into smart quotes. These things get put in myriad places apparently. Alexey: All right, so with caveats about some characters that need to be paid attention to, are we happy to allow non-ASCII by idnits on the condition that if any of the drafts get approved by IESG it will be held or the non-ASCII reverted? Adam: I'm good with that, yes. Ekr: Sounds good to me. Alexey: Okay, I think I can give Robert and Henrik the good news then. 6.2 Approval of port assignment for E1 interface (3GPP) (Mirja Kuehlewind) Amy: Mirja added this but unfortunately she couldn't be here today. I guess the question is, does anyone object to approving this? Alexey: No objection. Amy: Okay, I'm hearing no objection. Michelle, I'm assuming we need to send you an official note. Michelle: Yes, and also I probably need more details than what's in the management item. I can get those from Mirja. I've been combing some old tickets to see if I can find it. I do need some more details from Mirja so I'll drop her a note today. If you send us the approval we'll make sure we get what we need from her. Ted: I think I have the start of this thread in email so I'll send you that and if it doesn't trigger the right thing you can find Mirja. Michelle: Thank you, Ted. 7. Any Other Business (WG News, New Proposals, etc.)