Narrative Minutes interim-2018-iesg-13 2018-06-21 14:00
narrative-minutes-interim-2018-iesg-13-201806211400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2018-06-21 14:00 | |
Title | Narrative Minutes interim-2018-iesg-13 2018-06-21 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2018-iesg-13-201806211400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2018-06-21 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 Alissa Cooper (Cisco) / IETF Chair, General 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 Benjamin Kaduk (Akamai Technologies) / Security Area Suresh Krishnan (Kaloom) / Internet Area Mirja Kuehlewind (ETH Zurich) / Transport 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 Alice Russo (AMS) / RFC Editor Liaison Jeff Tantsura (Nuage Networks) / IAB Liaison Amy Vezza (AMS) / IETF Secretariat Martin Vigoureux (Nokia) / Routing Area REGRETS --------------------------------- Heather Flanagan / RFC Series Editor Sandy Ginoza (AMS) / RFC Editor Liaison Portia Wenze-Danley (ISOC) / Interim IAD OBSERVERS --------------------------------- Greg Wood Amy: I don't see Mirja yet, and we have regrets only from Sandy. 1.2 Bash the agenda Amy: We have two items that were deferred overnight, a conflict review and a status change. Any other changes? 1.3 Approval of the minutes of past telechats Amy: Any objections to the June 7 minutes being approved? Hearing none, these are approved and will be posted. Any objections to the June 7 Narrative minutes being approved? Hearing none, these are approved and will be posted. 1.4 List of remaining action items from last telechat OUTSTANDING TASKS o Benjamin Kaduk to find an additional designated expert for the AEAD Parameters registry. Benjamin: Still in progress. I've been asking for feedback and suggestions but still need to hear back. o Alexey Melnikov to find a designated expert for RFC 8323 [IANA #1108770]. Alexey: In progress. o Alexey Melnikov to find a designated expert for RFC-ietf-core-senml [IANA #1112601]. Amy: Provisionally done; this approval is a management item. o Alexey Melnikov to find designated experts for RFC 6143 [IANA #1113496]. Amy: Provisionally done; this approval is a management item. o Eric Rescorla to find designated experts for RFC-ietf-oauth- discovery [IANA #1113497]. Ekr: In progress. o Adam Roach to designate a new team leader from current URN Namespaces expert pool [IANA #1113095]. Adam: Peter St. Andre has agreed to do this and we'll do it in the approval section. o Alexey Melnikov to find designated experts for RFC-ietf-uta-smtp- tlsrpt [IANA #1113903]. Alexey: In progress. o Alexey Melnikov to find designated experts for RFC-ietf-extra-specialuse- important [IANA #1114238] Amy: Provisionally done; this approval is a management item. o Benjamin Kaduk to find designated experts for RFC 4681 [IANA #1112792] Benjamin: I think this is just a case of churning all the TLS registries anyway, so we wanted to make the experts match up for all the registries that have experts. IANA noticed we haven't done this one yet so we're going to make them consistent. Amy: This might be in the management item itself. When we come to that we can approve those. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-lamps-rfc5750-bis-06 - IETF stream Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling (Proposed Standard) Token: Eric Rescorla Amy: No open positions or active discusses, so unless there's an objection it looks like this is approved. Ekr: Please put it in the thing that says I'm going to look at it before we actually push the button. Amy: Approved, Announcement to be Sent, Point raised, Writeup Needed. Then you can let us know when it's ready. o draft-ietf-spring-segment-routing-ldp-interop-13 - IETF stream Segment Routing interworking with LDP (Proposed Standard) Token: Alvaro Retana Amy: I have a couple of open positions. Terry, did you want to state a position? Terry: It must have fallen off my reading list, no. Amy: Ekr, do you have a position? Ekr: I won't be taking positions on things I'm not taking positions on. Amy: I do have a Discuss in the tracker. Alvaro, do we need to discuss this today? Alvaro: No I don't think so, we need to let the authors respond. We will need a revised ID. o draft-ietf-idr-bgp-prefix-sid-25 - IETF stream Segment Routing Prefix SID extensions for BGP (Proposed Standard) Token: Alvaro Retana Amy: I currently have a Discuss in the tracker. Do we need to discuss that today? Alvaro: We might, I don't know. Adam: We probably do. I'm happy to be told I'm in the weeds. Ignoring the plans for publishing something in the future to rectify this, we pretty much all agree we don't want to be publishing ipv4-only docs in 2018, right? Alvaro: This is not an ipv4 only doc. Adam: In that case I must have misunderstood the implications of the removals. Alvaro: There are 2 flavors of segment routing. one that runs over mpls and one over ipv6. In mpls you can run v4 or v6 or ethernet or whatever you want. Basically the only thing that was removed here was the extensions for the v6only network. You can still run ipv6 over mpls if you want, which is mostly what's deployed out there. Adam: Okay, thanks for clearing that up. I'll clear my Discuss. Suresh: Adam, the v6 stuff that was there was kind of inconsistent, and that's why they removed it. The sending behavior made something optional that was required in the receiving behavior. I had a discuss on the previous version of this document. This is kind of agnostic of the protocols currently of reachability. Warren: I hand't balloted Discuss but now that I think about it more maybe I should have. There's no discussion of whether this needs to be a transitive attribute, and whether making it non transitive would stop... Alvaro: Yes I saw that. Your audio cut out. Warren: I did not ballot a discuss so there's nothing I can do now but I think it would be useful if there was some answer. Alvaro: yes, I've been tracking that discussion and the other one that sprung out of that from Sue so I will hold this until that is settled somehow. The other side thing that you didn't see is the question of whether we need to send it back again. I'll see how much it changes before I make that decision. I won't let it go through. We'll need a Revised ID. o draft-ietf-payload-rtp-vc2hq-06 - IETF stream RTP Payload Format for VC-2 HQ Profile Video (Proposed Standard) Token: Ben Campbell Amy: No open positions or active discusses, so unless there's an objection it looks like this is approved. Ben: It's going to be Revised ID Needed, there are some comments that need to be dealt with and hopefully we'll see authors responding soon. Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed. o draft-ietf-mmusic-sdp-simulcast-12 - IETF stream Using Simulcast in SDP and RTP Sessions (Proposed Standard) Token: Ben Campbell Amy: I currently have an active discuss, do we need to discuss that today? Ben: I think this can be dealt with over email, it just needs to happen. Do you agree, Adam? Adam: Yes. Ben: Just fixing some inconsistencies with a dependency. Amy: Will this require a revised ID? Ben: Almost certainly. o draft-ietf-ippm-twamp-yang-11 - IETF stream Two-Way Active Measurement Protocol (TWAMP) Data Model (Proposed Standard) Token: Spencer Dawkins Amy: I have two open discusses, do we need to discuss those today? Spencer: I think that Ignas's discuss is large and well organized and well presented. The authors are just starting to chew on the three large areas. I think the right things will happen with that in email. Thank you for a clear discuss. Adam's Discuss did knock one process question loose from Alissa, which is that this doc was reviewed by the YANG Doctors in 2016. Whether it should have been re-reviewed at IETF last call time or not, I don't have an opinion, but I did notice that Alissa asked. Let's figure out what the right answer is. Alissa: I don't know either, if it's typical that they re-review YANG models when they go back into last call. Spencer: This is my first one, so I have no idea. I went and looked at the template and Adam is right; the authors will do the right thing. Thank you for an excellent and actionable discuss. Amy: It sounds like this will require a revised ID to fix. Spencer: I'm almost sure that's true, yes. Michelle: Spencer, do you want IANA to kick off a YANG module review with the experts just to cover all bases? Spencer: This is my first YANG model as responsible AD. Is that expert review the same thing as the YANG Doctors review? Michelle: Yes, it is the same as the YANG Doctors. Spencer: That's what I'm confused about. Michelle: How about I follow up with you offline and we'll make sure that whatever review needs to happen gets done? Spencer: We've already got Adam's discuss and I think we know something needs to happen before it gets approved. Let's work though Adam's discuss before we ask the YANG doctors for another look. Thank you so much for your help. Amy: This will go into Revised ID Needed. o draft-ietf-pals-ethernet-cw-06 - IETF stream Use of Ethernet Control Word RECOMMENDED (Proposed Standard) Token: Deborah Brungard Amy: I see no active discusses, if there are no objections this is approved. Deborah: Let's do it Point Raised; the authors will be addressing comments. We'll see if they need a revised draft or not. Amy: This will go to Approved, Announcement to be Sent, Point raised, Writeup Needed. o draft-ietf-dcrup-dkim-crypto-13 - IETF stream A new cryptographic signature method for DKIM (Proposed Standard) Token: Alexey Melnikov Amy: There are no active Discusses, so unless there's an objection this is approved. Alexey: Can I have it in Point Raised just to double check the remaining comments are addressed. Amy: Sure. Let's put it in Approved, Announcement to be Sent, Point raised, Writeup Needed. 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 o status-change-change-ipp-to-internet-standard-00 - IETF stream Internet Printing Protocol/1.1 to Internet Standard (None) Token: Alexey Melnikov Amy: No discusses to this status change, so unless there are objections now it looks like this one is approved. Hearing none, this is approved and we will send it to the RFC Editor with the status change text in the Datatracker. 2.3.2 Returning items NONE 3. Document actions 3.1 WG submissions 3.1.1 New items o draft-ietf-teas-actn-info-model-09 - IETF stream Information Model for Abstraction and Control of TE Networks (ACTN) (Informational) Token: Deborah Brungard Amy: I have no active Discusses, so unless there's an objection this is approved. Deborah: We'll do it again as Point Raised. Amy: This will be Approved, Announcement to be Sent, Point raised, Writeup Needed. o draft-ietf-dprive-padding-policy-05 - IETF stream Padding Policy for EDNS(0) (Experimental) Token: Terry Manderson Amy: I have an unknown consensus, Terry, should I mark it as yes? Terry: Yes please, sorry. Amy: Okay. I have a Discuss in the tracker. Do we need to discuss it today? Terry: I think so, actually. I wanted to ask Ekr -- to be honest I'm quite surprised the authors haven't jumped back on your Discuss. Given that there's significant interaction with MTU size, maximal padding can't actually be used. As experimental best effort, it's a block padding. so yes it's variable but it's limited. So I don't believe it's trying to endorse random padding; it's working with what we can work with. If you do maximal padding you're going to hit up against the MTU size and you're going to fragment. It's kind of best effort. I'm wondering what your thoughts are. Ekr: Maybe I misunderstood. When I read this doc I thought it had a recommended strategy in 4.1 which is this block length padding, which I think is reasonable. In 4.2 it has this thing called Other Sensible Strategies, and lists maximal padding, random length padding, random block length padding. So it calls them all sensible, says maximal is not recommended, doesn't say anything about random length, and nothing about random block length. What I'm complaining about is that it endorses random padding and not ... Terry: I see what you mean. Thank you for clarifying your discuss. I will maintain that and ask the shepherd and authors to update the document pointing out that those other two are in fact not recommended in the same way as 4.2.1 is not recommended. Ekr: Do you want me to leave my discuss? Terry: Leave your discuss and I'll follow up. Amy: Sounds like that will require a Revised ID. o draft-ietf-sfc-hierarchical-09 - IETF stream Hierarchical Service Function Chaining (hSFC) (Informational) Token: Martin Vigoureux Amy: Martin, I have a consensus unknown for you, should that be yes? Martin: Yes, thank you. Amy: I have a Discuss, do we need to discuss? Martin: We can, but it's up to Benjamin. Benjamin: The only thing it seems to make sense to talk about right now is if we want to consider asking this to move to experimental. I don't have all the background but with what I've heard so far it seems like this is laying out some options that have not been deployed very much and we really do want to get some extra experimental results to see how these things work, which have flaws, which are better in which scenarios; and the conclusion of the experiment could be to disrecommend some of these implementation options. Martin: Personally I'm not opposed to that, but I'm wondering whether that conflicts with other opinions that were expressed. Maybe there is not enough information to start deploying one option for another. Benjamin: Right. I guess the experiment would be to try out all these options and the result might be to veto some of these, but we don't know yet. Martin: I think Alvaro was saying some of the options we don't have enough information to even start deploying or testing. Alvaro: Its all very wide open, not specified. A lot of handwaving to me. Martin: Benjamin, would changing the target in the status help clear your discuss? Or are there more things? Benjamin: That would help with at least one of the points in my discuss. The first one, I think the authors provided an easy resolution. Moving to experimental would help with the 2nd and 3rd points I made. The 4th one is still a little unclear to me. You were saying just now that for some of these options they're not even well enough specified to start deploying yet. I think I would need to think about the implications of that some more. Martin: Do you want to write .... I don't remember whether you explicitly raised the option of moving to experimental to the authors. Benjamin: I mentioned it almost in passing, the last sentence of one paragraph: "Perhaps experimental status is more appropriate." I did not get a chance to read their responses in detail yet. Martin: Let's try to discuss that with them and see. Benjamin: Sounds good. Amy: So is this going to be a Revised ID needed? Martin: Definitely. Thank you. o draft-ietf-ippm-2330-ipv6-05 - IETF stream IPv6, IPv4 and Coexistence Updates for IPPM's Active Metric Framework (Informational) Token: Spencer Dawkins Amy: I have a Discuss, do we need to discuss? Spencer: I think we need to meta-discuss for a moment. Al has responded to Suresh's Discuss since the telechat started, so that's a conversation that is starting. He has I think a reasonable point about IPPM needing to be more tolerant of things that are not standards compliant but exist on networks. He's also raising the issue of the IPPM chartered work on in-situ OAM, having some of the same issue with intermediate nodes with header extensions. I think that's a conversation we're going to end up having to have before the In-situ OAM material comes out of the WG. Suresh, do you have a good feel for how we would want to do that? Is that an informal telechat, a Montreal meeting, pistols at dawn? Suresh: To be frank, every time I've brought this issue up I've gotten handwavy answers without acknowledging the issues...I'm not taking a religious position but I'm trying to be a nice person. Write it up, write how you do this in a proper way. That has not happened. I would expect when the IPPM documents like the in-situ OAM come true, I would expect that kind of discussion there. If this can be made to work on the internet, say how to do it, otherwise say it's only for private networks. put in an applicability statement that this is for a private network. The reason I put this as a discuss is the doc actually takes other cases of nodes mangling the packets. The 6lo and nat64, it talks about how the packets get transformed and so on. As long as this document puts in a thing that says this is how these packets are going to change and these are the issues. As long as there's some kind of discussion about what the issues are and how you plan to address them, I'm okay with it. 8200 doesn't use 2119 language and I'm unhappy about that. We don't have any restrictions in IETF that we need to use 2119 language. But that's another discussion. This is specifically because we couldn't find consensus on how we would actually safely do this. I'm going to respond to Al. I think we can merge. Treat this like another exception case and I'll take out the text. That would be enough to resolve my discuss. Spencer: The other thing for me to say is that IPPM is a WG that I've handed to Mirja fairly recently and I'm taking the docs that were already in flight. I think that means you can make me work harder on trying to get stuff like this resolved if I'm not the responsible AD for IPPM. Please involve me in that. Suresh: Sounds good, thank you. Spencer: I would really like to get that worked out before IPPM requests publication on the in situ OAM stuff. Suresh: It's not like it's not workable. We know how to do encapsulation. Spencer: We will do our best to do the right thing. Thank you for the clear statement and for poking that particular bear on a doc where this is a manageable discussion. If this doesn't end up as a Revised ID Needed I'll be pleasantly surprised. Amy: I'll put that into Revised ID Needed. 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 3.3.2 Returning items NONE 3.4 IRTF and Independent Submission stream documents 3.4.1 New items o conflict-review-clausen-lln-rpl-experiences-00 IETF conflict review for draft-clausen-lln-rpl-experiences draft-clausen-lln-rpl-experiences-11 Observations on RPL: IPv6 Routing Protocol for Low power and Lossy Networks (ISE: Informational) Token: Alvaro Retana Amy: This has a Discuss, do we need to discuss today? Alvaro: I think we do. Mirja, I saw the Discuss and sent email right before the call. Mirja: I completely agree that it shouldn't be published. But I hope the ISE is doing the right decision here. I don't think it actually has a conflict with IETF work. It's related, but how does it conflict with IETF work? Alvaro: Thats why I put in the response was that it could disrupt the work. It's basically saying we don't think this protocol works. Mirja: That's also a little bit what the ISE stream is for, right? Alvaro: It doesn't say how it doesn't work because it doesn't provide details on the experiments. To me it seems like this is not the first time it happens with this group of authors, where they publish papers at conferences and then come to the IETF to publish again. Mirja: This is all understandable and it's not good practice. I hope the ISE makes the right decision there. But I'm not comfortable saying there's a conflict in the IETF. Alvaro: What we're saying is it could potentially disrupt. The only options are either it's related and it doesn't prevent publishing, or this one which is it could disrupt and we recommend not to publish. Mirja: I'm not sure if a even not very well written and already discussed in the IETF experimentation report. It's a different case if you have a protocol extension or a new protocol which got rejected, but an experimentation report that's not followed on anymore in the IETF. If everyone else agrees this is a conflict and that's the right proposal I will clear my discuss, but I have the feeling it should rather be answered that it's related but it doesn't permit publication. Hopefully the ISE will see all your comments and react. Alvaro: We're seeing different sides of the coin here. I'd rather recommend not publishing than just hope they don't. Alissa: Even with the recommendation it is just a hope anyway. I agree with you. I'm just saying that in response to Mirja's point, he still doesn't have to do what we recommend. If it seems like it could be disruptive, this seems like the right answer. Mirja: The text says it could potentially be disrupted. If everyone else agrees I can clear my discuss. Spencer: That doesn't mean we don't understand what you're saying. What you're saying made perfect sense to me. Mirja: That reply is fine as well, I just wanted to have a discussion about it to be sure. Spencer: Conflict reviews are complicated. Ekr: Mirja's point is right on some level. The IESG should have a relatively expansive view of what conflict means. The question of conflict is, is this going to screw up our work? If it's documents that don't conflict in a formal sense but are going to disrupt our work, we should encourage the ISE not to publish. I hear Alvaro saying this isn't actually going to override our protocols, but it's going to screw up our work. Mirja: The ISE will read Alvaro's comment and make a decision based on this information. I don't know if people who just see this conflict reply and don't have the context will understand why it's this way. Alvaro: Hopefully no matter what response we give, they read the ballot. We can ask them to put some statement in there but to paraphrase Adrian from another conflict review, he said no one reads the boilerplate or IESG notes anyway. Mirja: Which is a different problem. Alvaro: Hopefully they not only see the boilerplate response but they actually look at the ballots and even the other reviews. I also sent the review to the authors several weeks ago and haven't received a reply. Mirja: The thing about all those conflict reviews is basically how does Adrian perform this? Does everything he gets ask for reviews, including conflict review, or does he do a first look at the document? Alvaro: I don't know exactly but I know there's a board that takes a look first and he gets reviews from other people. In this particular case, Adrian was actually the Routing AD when this doc was discussed in the WG six years ago. There's always been conflict with the authors and Adrian recused himself from this document. So Nevil is the one who's shepherding. I had a little discussion with him about my review and the ballot. He thought it made sense and he wanted to wait for the authors to reply and they haven't replied at all. So yes there's some previous review before they get to us, and hopefully more discussion after. Suresh: What we put in here is a recommendation from the IESG. The ISE sometimes goes ahead and publish anyway. He's not bound by our response. I know there are cases of that happening. Warren: There was a doc on the agenda which got pushed, the YETI. We don't add notes that seem opinion, or we don't ask the ISE editor to add things which are opinion. I admit I don't like the Yeti experiment but I'm concerned we might end up doing .... (audio cut out) Spencer: I had a side conversation with Adrian just before the telechat. I think having a discussion about that would be fabulous. It's not totally obvious from our procedures when we should be proposing an IESG note. Does that go back as part of the conflict review response, or do we basically say this is the conflict review response and the ISE says okay, in that case we need this note. This document is done once we send the conflict review back. I think having a conversation in Montreal on this could be brilliant. Suresh: If I understand your concern correctly, Warren, you don't want us to do the note? I think it's part of the process, because we have a technical opinion, right? Warren: Specifically for the Yeti one, it feels as though it's coming close to our personal opinions on documents. Alissa: Why are we having a discussion about the Yeti one right now? Didn't we defer it so that we could avoid this? Warren: Yes, that's true. Let's discuss it at the next chat then. Amy: We've approved the 'please do not publish.' I have that the Discuss has been cleared and we can move on with that. This is the approval of the 'do not publish' with the note that's currently in the tracker. o conflict-review-mavrogiannopoulos-pkcs8-validated-parameters-02 IETF conflict review for draft-mavrogiannopoulos-pkcs8-validated-parameters draft-mavrogiannopoulos-pkcs8-validated-parameters-02 Storing validation parameters in PKCS#8 (ISE: Informational) Token: Eric Rescorla Amy: No discusses, so unless there's an objection, it looks like the conflict review message can go back. There's some in there just for you guys and ... The note that should be included is that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. We'd just remove the meta bit at the top there. Is that right, or do you want the whole thing? Ekr: I request some guidance from my friends here. The two pieces of context... Mirja: Just put it in your ballot position. Ekr: The other thing is that Adrian has apparently already read this and emailed SECDISPATCH. So I don't know quite how it's going to shake out. I think we should still send this. Mirja: This was never presented previously in SECDISPATCH? Ekr: Not to my knowledge, no. Mirja: Did you say the authors already agreed to take it to SECDISPATCH? Ekr: No, the authors emailed SECDISPATCH and asked them to comment on it. Benjamin: Because SECDISPATCH didn't exist until a couple months ago. My take is the authors originally came to IETF, presented at SAAG and got feedback, but there wasn't a good place for them to publish in IETF so they went to ISE. Now that there is a good way for them to publish in the IETF, we're inviting them to take that route because we think it would be better through the IETF. But I sympathize that it's an implementation detail that could be done outside the IETF. I'm a little torn. Ekr: It's a definition of semantics. It's a protocol. Benjamin: It's in OID that anyone can assign... Ekr: If they want to publish on their own website, go to town. But the document as an RFC, to create confusion of if its an IETF thing or not. Mirja: I think the conflict response as written is appropriate and ISE can decide whether or not to publish. Ekr: If people are happy with that I can take my part out and put it in my ballot. Mirja: Makes sense to me. Benjamin: It does seem like the best option. Ekr: For the record I think both of these are revealing that there's a string we're supposed to send back to the ISE, but needs commentary, and we don't seem to know how to do that. Alissa: But the commentary always goes on the ballot. Ekr: The commentary in this case is that it;s the opinion of the IESG, not the opinion of me. Alissa: That's a problem with us being limited to canned responses. Mirja: It's also not really an opinion, is it? It's advice. Alissa: It says "I." Ekr: I'll put it in my ballot. We can deal with this question if the ISE continues to exist and publish RFCs. Alissa: I would defer all of this high level discussion. Suresh: One thing you could do is to put it in passive voice. Ekr: I will do that. Amy: Whether the conflict review message gets edited again or not, we're going to send the 'do not publish' with this 'please bring this work to us' message. 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 right now. 6. Management issues 6.1 [IANA #1113496] Designated expert for RFC 6143 (Alexey Melnikov) Amy: Alexey has suggested John Levine as the expert. Unless there's an objection, it looks like this one may be approved. Hearing none, this is approved and we will send the official note to IANA. 6.2 [IANA #1113497] Designated experts for RFC-ietf-oauth-discovery (IANA) Amy: We discussed this at the top in action items. 6.3 [IANA #1113095] Designating new team leader from current URN Namespaces expert pool (IANA) Amy: Adam said that Peter Saint-Andre had agreed to be the new team lead. Unless there's an objection now, it looks like this is approved. Hearing none, this is approved and we will send the official note to IANA. 6.4 Change of Change Controller for port 631 (service "ipp") (Alexey Melnikov) Alexey: Authors of the original RFC agreed that they represent the IEEE group responsible for printing and they agree the IESG should be the change controller. Mirja: The person currently listed in the registry is not reachable anymore. Benjamin: For the original address, is it that the email bounces and we've also tried to reach the human? Alexey: It was somebody from Xerox. The port number is documented in two RFCs. I think the IESG is the right thing here anyway. Benjamin: I also think so, I'm just wondering if we've done our due diligence to find the original person to have them also authorize the change. Mirja: The question is also if we have to do that. This came originally because the new chairs, who are also the authors of the updated RFC, requested to change the change control to themselves, and then we suggested the IESG and they agreed. Warren: Even if we don't have to have to do it, it seems like it cuts down on potential liability issues in the future and is also a polite thing to do. Mirja: It's kind of related to the port cleanup. It's 2 different things, who is the original assignee and who is the change control. It's kind of mixed up at the moment and probably should separate those things. We can put it in the draft but it still needs an RFC to be published to make that change. The current version of the draft says the original assignee should still be noted in the notes to have it on record. Alexey: So are we changing our recommendation to the original assignee without email address and change control to IESG? Mirja: We don't have a row in the table that says change control. That's kind of the problem. Michelle: In the port registry you do have two fields, registrant and contact. Mirja: But they're supposed to be together, right? If not we can do that as well. Benjamin: It seems pretty likely that if we tried to find the original person we would succeed in contacting them. Mirja: He might have reliability issues but we also should think about how much effort to go into to contact him. Benjamin: I don't want to insist we go through these huge efforts. Alissa: I found his LinkedIn profile in 15 seconds, so it wouldn't be that much effort. But it's not like we need to wait and see if he responds or anything. Mirja: I guess if we publish the cleanup document we will have a number of cases where we will not reach anybody and this will come up again. Fr this case, the recommendation is to contact the original assignee once again and if we don't get a response we get it back. Benjamin: Make the additional attempt to contact the original assignee in parallel with going ahead to make the IESG the change controller. Inform them that we are in the process of changing this, and if you disagree we can revisit. Alissa: That seems reasonable. Alexey: This is a test case for our future bulk changes, so we might as well try it. Can you add an action item for me to do this? Mirja: Is it you or IANA? Michelle: Is the action item reaching out to the current contact? I'll do that. Alexey: Thank you. Mirja: How long do we wait for a reply? Michelle: Maybe 2 weeks? Mirja: Fine for me. Amy: So If we're going to wait 2 weeks for a possible reply from the current listed contact do you want us to add this to the agenda for July 5 to check back? Alexey: Let's do that, thanks. 6.5 [IANA #1113903] Designated experts for RFC-ietf-uta-smtp-tlsrpt (IANA) Amy: We have assigned this to Alexey and it's on the outstanding tasks list. 6.6 Proposed Telechat Dates between IETF 102 and IETF 103 (IESG Secretary) Amy: We really couldn't come up with a second proposal; it very clearly falls in a pattern. Any questions or objections to this telechat schedule? Hearing none, these dates are approved. 6.7 [IANA #1112792] Designated experts for RFC 4681 (Amanda Baber / IANA) Michelle: For 6.7 you mentioned Benjamin was working on that but that's the one where we already have 3 names because it's a TLS registry. Can we just approve that? Amy: Yes, sorry. You have Yoav, Rich, and Nick listed as experts for other TLS specification registries and you want to add them to this one? Hearing no objection, this is approved. 6.8 [IANA #1114238] Designated experts for RFC-ietf-extra-specialuse-important (Amanda Baber / IANA) Amy: IANA added this but I believe Alexey has updated it with two experts. Alexey: The latest version is both Barry and Bron. Amy: Is there any objection to appointing Barry and Bron as the experts? Hearing none, we will send the official note to IANA. 6.9 IANA #1112387] Management Item: Correction in the tsig-algorithm-names registry (IANA) Amy: We're looking for advice, correct? Michelle: Alexey has suggested that we go ahead and make the correction, but I didn't know if the IESG agrees with that. There's also an errata report that was filed and is currently held for document update. I don't know whats happening with that. We would like advice on whether we should just go ahead and correct the registry. Alissa: That seems fine. Alexey: If people are using names from the registry I think it's better to have it corrected because it's an obvious fix. Amy: Do you need an official note or are you good with the instruction? Michelle: A note back just saying to go ahead and update the registry would be great. Usually when we fix a registry that pertains to an errata we put a reference in pointing to that errata, so it would be great if there was some type of movement to fix it so we could move on. Alice: Would you like me to change the status to verified? Michelle: That would work. We could point to that so people know where the correction came from. Alice: Typically when the IANA registries point to an erratum the erratum is verified, correct? Michelle: Yes that's correct. 6.11 Proposed Designated Expert for "SenML Units" and "SenML Labels" registries (Alexey Melnikov) Alexey would like to approve Ari Keranen as the designated expert. Any objection? Hearing none, this is approved and we will send note to IANA. 6.12 IESG approval of .well-known allocation from draft-ietf-uta-mta-sts (Alexey Melnikov) Alexey: We talked about this, the document got approved. The rules for the registry are changing but I don't want to hold this doc until the updated rules are approved so I'd like an exception. Adam: That sounds reasonable. Benjamin: We informally talked about doing this previously, if I recall correctly. Amy: Hearing no objection to approving the exception. What exactly does that mean? Alexey: Basically instead of approving a designated expert according to current practice it's IESG exception. So we just need to tell IANA it's approved based on IESG exception. Michelle: Amy, you can just send that to iana@iana.org and when it comes in we'll merge it with our open ticket. Amy: Basically it's sending an official note saying the IESG has approved this exception. 6.10 IETF 102 Agenda Conflicts (Liz Flynn) [Discussion of IETF 102 agenda conflicts not minuted] 7. Any Other Business (WG News, New Proposals, etc.) ------------------------------------------------------------------------