INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2018-08-30 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Ignas Bagdonas (Equinix) / Operations and Management Area Deborah Brungard (AT&T) / Routing Area Ben Campbell (Oracle) / Applications and Real-Time Area Michelle Cotton (ICANN) / IANA Liaison Spencer Dawkins (Wonder Hamster Internetworking) / Transport Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Ted Hardie (Google) / IAB Chair Suresh Krishnan (Kaloom) / Internet Area Mirja Kuehlewind (ETH Zurich) / Transport Area Warren Kumari (Google) / Operations and Management 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 Alice Russo (AMS) / RFC Editor Liaison Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area REGRETS --------------------------------- Alissa Cooper (Cisco) / IETF Chair, General Area Heather Flanagan / RFC Series Editor Sandy Ginoza (AMS) / RFC Editor Liaison Benjamin Kaduk (Akamai Technologies) / Security Area Terry Manderson (ICANN) / Internet Area Jeff Tantsura (Nuage Networks) / IAB Liaison Portia Wenze-Danley (ISOC) / Interim IAD GUESTS --------------------------------- Richard Barnes (author of draft-ietf-acme-acme) Daniel McCarney (author of draft-ietf-acme-acme) OBSERVERS --------------------------------- 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 the minutes of August 16 being approved? Hearing none, it looks like those are approved and we'll get those posted in the public archive. I also saw revised narrative minutes a couple of days ago; any objection to approving those? Hearing none, we'll get those posted as well. 1.4 List of remaining action items from last telechat o Eric Rescorla to find designated experts for RFC-ietf-oauth- discovery [IANA #1113497]. Ekr: No action; in progress. o Martin Vigoureux to find designated experts for RFC-ietf-trill- multi-topology [IANA #1117184]. Amy: I saw this was down as a management item today so we'll mark that provisionally done. o Alissa Cooper to follow up with the editors of the Tao regarding proposed revisions. Amy: Alissa could not be with us today, so we'll move on. o Suresh Krishnan to find designated experts for RFC-ietf-6tisch-6top- protocol [IANA #1119883]. Amy: Suresh, this is just to alert you that you have an action item. Suresh: That's in progress; I'll take care of it. o Eric Rescorla to find designated experts for RFC 8411 [IANA #1120853]. Amy: Ekr, just to let you know this came in not too long ago. o Alvaro Retana to find designated experts for sub-sub-TLVs for BIER Info sub-TLV registry created by RFC 8401 [IANA #1120855]. Alvaro: Working on that, thanks. o Ben Campbell to find designated experts for RFC-ietf-mmusic-rid [IANA #1120856]. Amy: I notice Ben has updated that management item naming an expert and we'll mark that provisionally done. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-acme-acme-14 - IETF stream Automatic Certificate Management Environment (ACME) (Proposed Standard) Token: Eric Rescorla Amy: I have a couple of Discusses in the tracker. Do we need to discuss those today? Ekr: Benjamin's not here so we won't discuss his. I was hoping Adam would clear, since he said he would clear. Adam: I'll clear when the document comes out. There's still some conversation going on; I have a back channel to Richard and he suggested Daniel might not be too happy about the proposal Richard put in there. Ekr: I think Daniel is here, so maybe we can see if we can resolve that now. Adam: With the text Richard has in there, I think it's fine. If we're going to roll it back to something that basically says, in this version of the document these are still gettable resources without any authentication, then we need to talk through the correlatability issue. I'm willing to concede I might be off in the weeds here, but it does seem like the ability to correlate all the orders associated with an account is a real privacy issue. Ekr: I'm actually persuaded by that. Had I noticed that in my review, I would have AD blocked that. So you've got to fix it, in my opinion. Daniel: How do you build that correlation when you only get the orders list from an account resource by an authenticated post to the account url? Adam: It doesn't say that. Daniel: I think it does. Richard: The thing Adam noted is that, at least in the examples we've got, the order list resources have a guessable structure. if you got one account resource, maybe your own, you could potentially guess other people's order list URLs. So you write them that way. Daniel: I'm not super familiar with the process here, I think this is the wrong place to hash out the technical discussion. I think the actual URLs as given as example in the doc, those are up to the server implementer to decide on. We could just make a comment about not choosing predictable URLS, since that was a concern of the server operator. Adam: That's what my comment was, basically, these need to be not predictable. And you probably need to put some parameters around what 'not predictable' generally looks like. Daniel: I'm fine with that, I'm just opposed to changing to requiring posts for those resources. Ekr: I didn't think that was what Richard's text said. Maybe I misread it. Richard: That is in fact what my text said. I was trying to avoid relying on unguessable URLs as an authentication method, to keep the authentication concentrated on safe symmetric modality. My PR says that if you have something you don't want to be gettable, require people to send a post with an empty body, which was kind of a hack, but was at least generic. If we want to have a more blended approach that uses posts for some authentication and uses unguessable urls for some other authentication, we can also do that. It's just a little less uniform. Ekr: It sounds like the authors don't agree, so perhaps the authors can go back and sort it out. The way Daniel characterized it as, if the server cares, I don't think is okay. This is clearly sensitive information and we should be mandating it has extra controls. Richard: I think we have the outlines of a discussion here, we just need to have some iteration on the mailing list. Adam: Thanks everyone. Amy: Okay, that sounds like a Revised ID Needed. We will mark it as such. o draft-ietf-dnsop-terminology-bis-13 - IETF stream DNS Terminology (Best Current Practice) Token: Warren Kumari Amy: I have no Discusses, so unless there any objections it looks like this is approved. Warren: I think it will be Approved, RID, because there were some useful comments provided. the WG did feel relatively strongly that it should be BCP, so I'm going to try and stick with that. Nobody has a Discuss, but does anybody want to shout strongly against BCP? Approved, Revised ID Needed. Amy: Approved, Announcement to be Sent, Revised ID Needed and you can let us know when that is 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-sidrops-rpki-tree-validation-02 - IETF stream RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator (Informational) Token: Warren Kumari Amy: I have no Discusses, so unless there any objections it looks like this is approved. Hearing no objection, this is approved. Does it need any notes? Warren: I think it's good to go. Actually let's do a Revised ID Needed because some of them might need two or three back and forth to get text perfect. And thanks Benjamin for the comments. Amy: Approved, Announcement to be Sent, Revised ID Needed and you can let us know when that is ready. 3.1.2 Returning items NONE 3.2 Individual submissions via AD 3.2.1 New items o draft-york-p-charge-info-08 - IETF stream P-Charge-Info - A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP) (Informational) Token: Ben Campbell Amy: I have no Discusses, so unless there any objections it looks like this is approved. Ben: Let's put this in Point Raised. I would like the authors to respond to Spencer's comments; I don't know if it will require a new revision. Amy: Okay, let us know when you are satisfied, Ben. 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 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 Deborah: Nothing I can think of. 6. Management issues 6.1 Designated Experts for TRILL Ethertypes registry (Martin Vigoureux) Amy: Any objection to approving Donald Eastlake as the primary and Sue Hares as the backup experts for the registry? Hearing none, we will send an official note to IANA identifying them. Martin: Thank you very much. 6.2 [IANA #1119883] Designated experts for RFC-ietf-6tisch-6top-protocol (IANA) Amy: This was to assign an action item to Suresh, which we talked about during action items. 6.3 [IANA #1119224] Designated Experts for draft-richer-vectors-of-trust and ietf-mile-rolie (RFC 8322) (Benjamin Kaduk, IANA) Amy: Benjamin added this for approval. There are two separate sets of designated experts to approve here. For draft-richer-vectors-of-trust they are Justin Richer and Leif Johansson. Any objection to approving those two people? Hearing none, so it looks like they are approved and we will send an official note to IANA. The next one is the draft ietf-mile-rolie. The experts are David Waltermire and Stephen Bangheart. Any objection to approving those? Hearing no objection, we will send that official note to IANA. Alexey: I think there is also a more generic question here for Michelle about when we actually happen to include IANA instructions in writeups. Do we need separate management items for approval or not? Michelle: The names of two experts were included in an approval announcement but we didn't actually have a management item with the official approval. So my question to the IESG was do we accept that as an approval if expert names are listed in the writeup, or do we actually need a management item to approve the expert? Alexey: Do you have a preference? Michelle: I don't think so. Either way works for us. If we do have experts announced with the approval of the document, we can put it in the registry right away. Often we're not that ahead of schedule and we usually are asking for experts later on. Either would work for us, it's really a matter of what you think is acceptable. Alexey: I know that when you create a writeup, there's a field for IANA instructions. I'm usually never organized enough to pick experts on the spot so I usually delete the section but if others are organized I think that's fine. Another interesting question is if people are always reading shepherding writeups. Some people can miss this. Ben: That can change after approval, too, the notes. Do we really need formal management approval of these? If we do, it seems the notes doesn't necessarily get us that. I'm not sure why we do, but there's probably history there I may not know. Alexey: Are you suggesting we should always do a management item? Ben: I'm saying if we really need formal approval we probably need the management item. I'm agnostic about it. Alexey: Any other thoughts? Does anybody other than me and Ben care? Ekr: All I care about is that someone somewhere write down what I have to do. Ted: I put some history into the jabber chat but the basic point was that there have been discussions/objections in the past. I suspect that if you took those to the IESG list and did them as informal, anybody got any heartburn kind of calls, you could get the same issues and resolve them informally. Warren: To me it seems like we spend a long time on these calls doing these expert discussions and I so far have only ever seen people say yeah, okay, whatever. I wasn't aware of what Ted posted that there have been discussions in the past. Michelle: What about: If the experts' names are present when the document is being discussed on the telechat, can it be brought up then? Amy usually says, are the notes correct? We can say at that point there are notes to designate so and so as experts, is that approved? Then we avoid additional management items later on, but at least it was brought up and discussed as approving the experts as well at that point in time. We can try that and see how it works out. Like Alexey said, this is the first time this has happened in a really long time, because usually the experts aren't named at the point the document is approved. If that's something we can do more of that's great, but often we don't ask for experts until the document is actually approved. Let's give that a try and we'll see how it goes. Warren: As an additional thought, what might be helpful is that when IANA does their review, if you notice an expert is required, letting the AD know - just a reminder, if you know who this person is going to be, please stick it in the document. Michelle: We can start doing that. We can give that a try and see if that helps you out. Spencer: I'd like to agree with that. Some of us go chasing experts a lot more often than others. For the ones that don't go chasing experts often, it probably is helpful to have someone who thinks about this more often than we do ask the embarrassing questions. Michelle: Okay, I know what to do going forward now and I'll discuss it with the team. Let's see if that helps. Amy: Do you want to record that in the minutes, or just that it was discussed? Michelle: I'll put something in Jabber for the minutes. 6.4 [IANA #1120853] Designated experts for RFC 8411 (IANA) Amy: We reminded Ekr of that action item at the top of the call. 6.5 [IANA #1120855] Designated experts for RFC 8401 (IANA) Amy: We also let Alvaro know that's a new action item for him. 6.6 [IANA #1120856] Designated experts for RFC-ietf-mmusic-rid (IANA) Amy: We got email not so long ago from Ben naming Adam Roach as the designated expert for this registry. Any objection for Adam taking that on? Hearing none, Adam is approved and we will send the official note to IANA. 7. Any Other Business (WG News, New Proposals, etc.) Amy: Anything anyone wants to bring up today? Hearing nothing from anybody, so it looks like we had a short call today.