Narrative Minutes interim-2019-iesg-11 2019-05-30 14:00
narrative-minutes-interim-2019-iesg-11-201905301400-00
Meeting Narrative Minutes | Internet Engineering Steering Group (iesg) IETF | |
---|---|---|
Date and time | 2019-05-30 14:00 | |
Title | Narrative Minutes interim-2019-iesg-11 2019-05-30 14:00 | |
State | (None) | |
Other versions | plain text | |
Last updated | 2024-02-23 |
narrative-minutes-interim-2019-iesg-11-201905301400-00
INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2019-05-30 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 Alissa Cooper (Cisco) / IETF Chair, General Area Michelle Cotton (ICANN) / IANA Liaison 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 Mirja Kuehlewind (Ericsson) / Transport Area Warren Kumari (Google) / Operations and Management Area Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area Cindy Morgan (AMS) / IETF Secretariat Amy Vezza (AMS) / IETF Secretariat Magnus Westerlund (Ericsson) / Transport Area REGRETS --------------------------------- Ignas Bagdonas (Equinix) / Operations and Management Area Heather Flanagan / RFC Series Editor Alexey Melnikov / Applications and Real-Time Area Alvaro Retana (Futurewei Technologies) / Routing Area Adam Roach (Mozilla) / Applications and Real-Time Area Martin Vigoureux (Nokia) / Routing Area Eric Vyncke (Cisco) / Internet Area Portia Wenze-Danley (ISOC) / Interim LLC Executive Director OBSERVERS --------------------------------- Adrian Farrel Greg Wood 1.2 Bash the agenda Amy: Does anyone want to add anything new to the agenda? I did get a late management item from Roman that made it on. 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes of the May 16 teleconference being approved? Hearing no objection, so those are approved. Does anyone have an objection to the narrative minutes of May 16 being approved? Hearing no objection there. 1.4 List of remaining action items from last telechat o Suresh Krishnan to discuss naming experts for the registries created by draft-irtf-icnrg-ccnxsemantics with Colin Perkins. Suresh: Colin just got back to me and told me all the context has been lost in the transition of the IRTF chair, so I forwarded him all the communications I had with Allison and he promised to discuss further with the IRSG but I don't think it will happen any time soon. I would close this [action item] and when he gets back to me I'll put in a new item to say what he says. o Barry Leiba to write up text on the IESG's expectations regarding conflicts of interest and the disclosure of funding sources. Barry: You can call that done; we're waiting on the LLC to do its version and then we'll coordinate with them. We can open up another action item if we need after that. o Ignas Bagdonas to propose an additional question on YANG Model format validation for each of the styles of document write-ups. Amy: Ignas could not join us today so we'll mark this as in progress. o Roman Danyliw to talk to the tools team to reset the counters on substate change for documents in AD Evaluation. Roman: That's still in progress; I've gotten various feedback from the IESG and I need to consolidate all the feedback to bring that back as a proposal for us to figure out what to do, since we have different opinions. Please do keep that on the list. 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 also still in progress. o Suresh Krishnan to write a document on replacing the "updates" with new terminology (amends/amended by; extends/extended by; see also). Suresh: That's in progress. o Warren Kumari and Ted Hardie to write a document on Implementation Target Sets (aka Living Documents). Warren: Ted's been doing all of the work. Ted: There has been a document written but the discussion of whether it's the right document or not is still in progress. I guess the question is: how do we come to a conclusion on whether we want to go forward on this theory or revert to either the datatracker or other theory? Alissa: A feeling I have about this is people asked for a way to have something like a living document which has actual content, and that is stable but updated with some frequency that's different from all of the other outlets we have now. This is an interesting thing, but it's not that thing. I feel like if we go forward with this then a lot of people who are waiting for the other thing will say, this isn't what we asked for. I realize it's more complicated than that but that's my feeling at the moment. I'm not sure what to do about that. Ted: There's more than one kind of living document and this is definitely only one of the kinds we might produce. For the implementation targets, what this in effect does is allow you to use the Internet-Drafts, which are now semipermanent publications, or at least continually accessible publications, in a document that describes how they fit in to some particular technology. I think it's the combination of this as a frame and the Internet-Drafts which gets you to the other kind of living document. If what people actually wanted was not a framing mechanism that combined with the Internet-Drafts to give you that, then this is definitely not the right approach and we'd have to start over. That question gets us back into, how is this not a replacement for the RFCS? This approach is something that augments the current mechanism we have, the Internet-Drafts and RFC series, but doesn't supplant any of them. If we want to go back into a brainstorming session about what the requirements the community is expecting are, I'm happy to do that. I still think either adopting the datatracker mechanism Mirja pointed to or some flavor of what http and quic were doing would still be valuable, because there are a bunch of people who come into the Hackathon or some other implementation event wanting to tackle a particular piece of technology but finding the state of play distributed over a lot of mailing list discussions that's very hard to boil down. Maybe that's not valuable enough for everyone to spend time on but I do think it's worth at least asking the community whether we ought to systematize in one of the three ways that's out there right now. Warren: Yes I agree it is worth doing, but I don't think this is what the community had been expecting or thinking of as living documents. I think maybe we built something new as well, which is worth pursuing, but it doesn't really solve the use case the community had been asking for. I realize I should have been doing more to push it along. Mirja: That's the whole problem, is that we're talking about at least three different use cases, and the solution for those use cases might be different. For example the implementation draft, I think putting it on GitHub is exactly the right thing because that's where the implementers will look for it. The only thing that might be missing is a quick link from the datatracker to the GitHub. What you have in mind is another use case and I think Ted has another use case there. Ted: It sounds like we probably need to have the use case discussion once more time before we go forward with this. Can I suggest we make that an agenda item for an informal, not next week but the one after that, and we'll go through those and revisit? I think this did do what the action item says, except for the "aka living documents." I don't think this is all living document use cases met, it meets a subset of that of a particular type. We probably need to work out as Mirja says what use cases are still in play and what we want to do there. Alissa: That sounds good. If you're willing to write up the use cases and maybe some requirements that derive from them so we can try to assess how many versions of this would be required to meet the various requirements, that would be useful to structure the discussion. Ted: I'll do what I can. Alissa: You don't have to. That's an action somebody can take. Ted: I'm willing to do it, because it's not going to come due for a couple weeks. In that couple of weeks I should be able to get through the pile of other stuff and get to this, although it may be a bit sketchy. I can at least try something. Alissa: Okay, thanks. o Roman Danyliw and Barry Leiba to draft a starting point for the discussion on setting expectations with the WG Chairs in reference to responses to inappropriate or unacceptable behaviors. Barry: I haven't done anything with that. I presume you haven't either, Roman? Roman: I believe we are in progress. Barry: We are in very slow progress. We will do something in the next couple of weeks. Roman: Yes. Certainly no earlier than next week though. o Martin Vigoureux to work with the IESG to create a list of possible IESG Tutorials and will prioritize them for scheduling on a series of Informal Telechats. Amy: Martin is not with us today so we'll keep this in progress. o All IESG to coordinate with their co-ADs and send a list of specific "hot topic" items that should be checked. The list to be provided for document authors. Roman: SEC has not yet closed this. Warren: We do have a bunch of wiki pages to point to, we just need to get them organized in a format that's more useful. Alissa: More generally, should we capture these on the IESG wiki as opposed to email? Should we try to coalesce them in one place? Warren: Probably. Roman: I would have suggested the first starting point would have been each area puts this set of recommendations on their respective wiki, we can make a list of references, and figure out what to do from there given what the content looks like. Mirja: The wiki page I've been sending around is our wiki page for our review team to which topics they should look for, which is kind of what you're asking for. Alissa: So maybe once the SEC one comes in we can make sure there's a spot on the IESG wiki that points to all of these things. o Eric Vyncke to write up draft text for the NomCom to help them understand the rules for the NomCom. Amy: Eric could not be here today, so we'll keep that in progress for him. o Suresh Krishnan to write up a NomCom Chair BCP (work with past chairs). Suresh: This is still in progress; I'm waiting to hear back from a few more people. o Eric Vyncke to draft text for a more coherent BoF Proposal for MEDIA OPS and add to the BoF Wiki. Amy: Eric could not be here today, so we'll keep that in progress for him. o Roman Danyliw to shepherd the www.ietf.org analytics discussion with the community. Roman: I am out in the field shepherding this along. We have a post out to ietf-discuss with a closing of mid next week and we've been collecting feedback. Unfortunately the snag we've hit now is that due to the latest server configuration we've temporarily lost the pointer to the PDF describing the proposal. We have the PDF in a link in an attachment so folks can still read it and we hope to have that resolved as soon as possible. So please leave it up but it's in flight and we won't have resolution likely until mid next week. o Warren Kumari, Alvaro Retana, and Mirja Kuehlewind with Spencer Dawkins to continue discussion of the next Deep Dive topic for IETF 105. Warren: Not going brilliantly. I'm unclear. I had thought, but I guess I was incorrect, that Magnus and Mirja and Spencer were running with it, but it looks as though possibly I was misinformed. It's useful we have these action items to remind us, and is there any progress on that? Mirja: I did discuss with Magnus a little. We kind of agreed that we don't see a transport topic coming up right now. Either we need more brainstorming, but I'm a little reluctant to involve more and more people without having a clear holder. Or we should cancel the Transport topic and figure out if we have a different topic for the next meeting. Warren: I had thought we'd decided that how the network interacts with transport was the topic. I thought we thought that was a good topic whether we called it a BoF or a deep dive or spaghetti with marinara sauce that it was still something useful for the community. But maybe that's changed. Magnus: I think the problem is to pull this together in a form that makes sense, and interacts and doesn't create more havoc than it needs to. I don't see a clear path. Mirja: Also in the past MTU discovery, this is an active discussion in INT area as well as TEAS WG, so having a separate session at this point in time is not productive. Warren: I suspect it's too late to organize a new deep dive for this meeting, so maybe we'll try it in Singapore. Mirja: The other topic I was proposing, and I would probably have some people in mind to ask, is how does a NIC work. But that seemed to be less interesting for everybody else on the call. Warren: I think that does seem interesting, especially if it includes stuff like the offloading, etc. Mirja: I would call some people in the UNIX community and figure out what the innovations are in the space for them right now. Warren: Should we take this offline and see if we can get it organized? If so, who wants to be part of that? Mirja: The two of us can talk a little bit and I can tell you the two or three people I have in mind and then I can contact them if you think that's a good idea. Warren: Does anyone think that would be harmful to have that discussion? Deep dive, BoF, whatever we call it? Mirja: Ted, I don't remember if the IAB was planning to have technical plenary or not at the next meeting. Can you remind me? Ted: Yes, in fact you were going to talk today about the fact we were going to ask to have the technical plenary as a separate session in front of the administrative plenary, remember all that? Mirja: Yes. But, there will be a technical plenary this time, right? Ted: Yes. Mirja: So the other question for the deep dive is when would we actually have it? Warren: I thought the plan was that since we're starting later, we'd have it in the morning before sessions. Mirja: Okay, just wanted to make sure. Let's take it offline. o Suresh Krishnan to update the text for material behind a paywall to update the reference to section 7.1; update the document shepherd writeup; and draft text for a possible IESG statement to circulate with the WG Chairs. Suresh: I sent this text out two weeks ago and got three +1s from Alissa, Mirja, and Warren. Unless I hear something by let's say next Wednesday, I'll ship this off to the WG chairs list to see what people think about it. As we talked about before, it's supposed to be an IESG statement. So if you have any comments, please send them by next Wednesday. I'll call this done. o Alexey Melnikov, Warren Kumari, and Suresh Krishnan to work with the authors of the recall draft on next steps. Suresh: Alexey and Warren are kind of out of commission so I picked it up. One thing that came up is that the authors want to go for a virtual BoF, so we have to figure out how to do that. I raised issues and I don't have satisfactory answers for them. I also summarized some of the issues that came up in the IETF discussion. I don't think they've been answered and I think we probably have to spend a little time making sure we track the issues that came up and how they were addressed. Some people say "that's not going to be an issue" but without any basis, so I think we need to spend more time on it. This is in progress. Alissa: Specifically on the virtual BoF proposal, that needs to be dealt with one way or the other. Most of the items that would typically be included in a BoF proposal were not included. I think it would help to do some off list engagement with the authors to get that going. Suresh: Sounds good. I'll get to it. o Alexey Melnikov to find designated experts for RFC-ietf-core-object- security [IANA #1141664]. Amy: Alexey could not be here today, so we'll keep that in progress for him. o Alissa to report back on the discussion about the Meeting Room Policy at LLC Board retreat. Alissa: This is done. Eventually there will be a firm policy but this action item is done. o Alvaro Retana to finalize the proposal for relabeling the IETF Meeting Agenda Conflicts, and discuss the proposal with the WG Chairs. Amy: Alvaro could not be here so we'll mark this in progress. o Alissa Cooper and Alexa Morris to take the results of the doodle poll for a second 2019 IESG retreat (possibly combined with the IAB) and look at cost effective places. Alissa: I believe we're waiting on Ben to fill out the Doodle. Ben: I'm signing for my house purchase later today and expect to do the Doodle after that. Alissa: I think there's something emerging from this Doodle but I wanted to wait for Ben's availability. Once that's done I'll send email about it. You can keep this in progress. o Alexey Melnikov to find designated experts for RFC 8554 [IANA #1142796]. Amy: Alexey could not be here today, so we'll mark that in progress for him. o Adam Roach to facilitate the discussion on WG Meeting Structure, related to alternate room layouts and the facilitation of discussion. Amy: Adam could not be here today, so we'll mark that in progress for him. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-pim-igmp-mld-yang-13 - IETF stream A YANG Data Model for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) (Proposed Standard) Token: Alvaro Retana Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this one is approved. Ben: Not objecting per se, just the coverage of the explicit tracking topic Mirja had brought up and I'd briefly made a discuss point; I guess we should probably finish that in email but I'm not entirely sure their proposed text covers the full breadth of the potential considerations. I'm happy to do that in email, just mentioning we probably don't want to just approve this as is. Amy: Alvaro did say he did want this to go into Point Raised. We'll have Alvaro take the next steps to fix what needs to be fixed. With that we'll move on. o draft-ietf-roll-useofrplinfo-29 - IETF stream Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane (Proposed Standard) Token: Alvaro Retana Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this one is approved. Alvaro did request this go into Revised ID Needed. Suresh: There was a late review. Alvaro had requested an IoT-DIR review and it came in late, yesterday evening. I think Revised ID Needed would be the best place to go for this. o draft-ietf-acme-caa-07 - IETF stream CAA Record Extensions for Account URI and ACME Method Binding (Proposed Standard) Token: Roman Danyliw Amy: I have a number of Discusses in the tracker; do we need to discuss any of those today? Roman: No, I'd like the discussion to continue on the list. Amy: Okay. Is this going to be Revised ID Needed? Roman: Yes, definitely. o draft-ietf-calext-eventpub-extensions-13 - IETF stream Event Publishing Extensions to iCalendar (Proposed Standard) Token: Alexey Melnikov Amy: There are a number of Discusses but unfortunately Alexey could not be here today. It looks like this is going to continue on in email unless someone has something to discuss right now. Barry: No, this will continue in email. This is going to have to be a Revised ID Needed, I'm sure, given the changes that are being requested. o draft-ietf-lamps-rfc6844bis-06 - IETF stream DNS Certification Authority Authorization (CAA) Resource Record (Proposed Standard) Token: Roman Danyliw Amy: I have no Discusses in the tracker, and one open position for Ace. Warren: I'm a No Objection. Amy: Then it looks like this one is approved if there are no objections now. Michelle: We still have some open IANA questions that we're not getting responses on. It would be great to get those resolved before it gets approved. I can send you an email in the next hour and notify you exactly what they are and what we're waiting on. Roman: That would be helpful, thank you. Regardless, this will need a Revised ID; some of the comments are very helpful and I'd like to see them incorporated into the text. o draft-ietf-mmusic-rfc4566bis-35 - IETF stream SDP: Session Description Protocol (Proposed Standard) Token: Adam Roach Amy: I have a number of Discusses in the tracker, but Adam isn't here. Does anyone have an idea if this will need a revised ID? Barry: It definitely will; there's at least an ABNF change that's going to have to be made. Amy: Then we'll leave this in IESG Evaluation with Revised ID Needed. o draft-ietf-tsvwg-tinymt32-03 - IETF stream TinyMT32 Pseudo Random Number Generator (PRNG) (Proposed Standard) Token: Magnus Westerlund Amy: There are a couple of Discusses; do we need to discuss any of those today? Magnus: No I don't think so; Revised ID needed. 2.1.2 Returning items o draft-ietf-tsvwg-rlc-fec-scheme-14 - IETF stream Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME (Proposed Standard) Token: Magnus Westerlund Amy: We have a Discuss; do we need to discuss that today? Magnus: No I don't think so, I think it's fairly straightforward. Revised ID needed. 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-lamps-hash-of-root-key-cert-extn-05 - IETF stream Hash Of Root Key Certificate Extension (Informational) Token: Roman Danyliw Amy: We have a Discuss; do we need to discuss that today? Roman: No, Revised ID is right here. o draft-ietf-sipbrandy-osrtp-09 - IETF stream An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) (Informational) Token: Alexey Melnikov Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this one is approved. Barry: Make this Point Raised, please. While I'm here, both of these documents (lamps and sipbrandy) are ones that were Informational and we wondered why, and the shepherd writeup didn't tell us. Can we all please talk to our chairs and remind them about the part of the document status question that says "why is this the correct status?" Most of the shepherds don't seem to be answering that part. I understand that if it's Proposed Standard it's obvious that this is a standard it seems silly to say, but the question is there if it's not obvious land they need to pay attention. Ben: That's a good point Barry. I guess for this OSRTP document in particular there's some longer history that goes back at least to when I was preparing to join the IESG that to me does make informational the correct status. Barry: I didn't want to discuss that particularly on the call, just that if that sort of information is in the writeup, then we don't have to wonder. That's all. Amy: This will go into Point Raised, Writeup Needed and Alexey can take it from there. 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-kanugovi-intarea-mams-framework-00 IETF conflict review for draft-kanugovi-intarea-mams-framework draft-kanugovi-intarea-mams-framework-03 Multiple Access Management Services (ISE: Informational) Token: Suresh Krishnan Amy: There are no Discuss positions, so unless there's an objection it looks like this conflict review message can go back to the ISE. Suresh: There's one point Ben brought up that I'll send off in a note to Adrian off list -- a curious use of the word "other IETF technology" could imply this is an IETF technology. I'll send the note to Adrian but otherwise sounds good to approve. Thanks. Ben: Adrian did reply that he acknowledged those comments; I don't remember if that was to just me or to all of us. Suresh: I didn't see that. Barry: In any case Adrian does see the messages in the datatracker. Amy: It looks like this no problem message is clear to go back to the ISE with the note that's currently in the tracker. We'll do that on Monday as normal. o conflict-review-jenkins-cnsa-cmc-profile-00 IETF conflict review for draft-jenkins-cnsa-cmc-profile draft-jenkins-cnsa-cmc-profile-05 Commercial National Security Algorithm (CNSA) Suite Profile of Certificate Management over CMS (ISE: Informational) Token: Benjamin Kaduk Amy: I have no Discusses in the tracker, so unless there's an objection now it looks like this one is approved to go back to the ISE. Ben: I'm a little uncomfortable with that; the actual ballot has only existed for about a day, so I'm tempted to push this back another week and give people an actual chance to look at it. Barry: You could put it in Point Raised and hold it until Ben thinks there's a critical mass, right? Amy: It can be approved and it can wait for you. Ben: Okay, let's do that then. Amy: This will go into Approved, Announcement to be Sent, Writeup Needed. You'll just need to send us a ticket when the number of people you're comfortable with have reviewed this. 3.4.2 Returning items o conflict-review-nottingham-safe-hint-01 IETF conflict review for draft-nottingham-safe-hint draft-nottingham-safe-hint-09 The "safe" HTTP Preference (ISE: Informational) Token: Barry Leiba Amy: I have a Discuss for this. Barry: Yes. I really don't know where to go with this; Mirja, thank you for writing up the short text you did. I appreciate that. What it tells me is that I think I'm not going to convince you that we don't need an IESG note, and you're not going to convince me that we do. So I don't know where to go from here. It seems a little funny to have an IESG note that simply repeats what's going to be in the documents anyway. Maybe try another pass at why you think an IESG note is so important when we are putting that text in the document? Mirja: We had this discussion last time, that none of the options we have for the conflict review fit quite perfectly well. Barry: I don't agree with that; I think the one we're using does fit perfectly well. That's the core of our disagreement. Mirja: The difference for me is that an IESG note is something that is explicitly stated by the IESG. So instead of just saying, no we don't see any conflict, we say "yes, this can be published as no conflict, but we also have concerns because it was previously in the IETF process and it was rejected there." That's an explicit note that the IESG has an opinion on this. If you just put that text in the document it doesn't say anything about what the feedback from the IESG was. Barry: Then we need to make sure we have consensus in the IESG on that. I certainly disagree with you, and I think Alissa has weighed in that she agrees with you. Do any other ADs want to comment? Mirja: Can I first ask why do you think an IESG note is a problem? I don't think it's a problem, it's just reflecting what we have discussed. Barry: Calling it a "problem" is a little strong. I know Adrian has said to me he thinks an IESG note should be used as a last resort, and I agree with that. Mirja: I very much disagree with that. Barry: That's our basic disagreement. Suresh: I agree with Mirja on this and Barry, I think we do have precedent. I agree with you that part of the text can be gone, where it says it doesn't have IETF consensus. The other part is that it was considered in IETF and rejected. We have precedent for this in 7974 where we had text that got added to the document and talks about why it didn't get through. Consider me on Mirja's side on this one, but I think the text could use some work. Barry: I think the text Mirja wrote, if we're going to do an IESG note, is fine. I understand there's a precedent for saying this. My point here is that it's going to be said in the body of the document itself. That's why I don't think we need an IESG note. Other comments? There's where the problem is, we don't have enough ADs who really care about it to decide what to do. Let me go a different way. Does anyone agree with me that having it in the document body is sufficient and we don't need an IESG note? Okay, guess that settles it and we'll put in the note. Mirja, I'll use the text you proposed unless anyone objects to that. Mirja: Let's ask that question: Does anyone object to putting an IESG note in? Ben: I have mixed feelings. In some cases having the content in the body of the document that this was considered and explicitly rejected for these reasons, that can be enough. If we do put an IESG note in we do want to be careful about the specific wording and make sure there's IESG consensus on it. I'd propose we do another round of this with specific proposed text for the note. Alissa: I was going to suggest the same. I might even change my ballot position if that's the route we're going down. If we can wordsmith the IESG note that would be useful. Barry: I'll put Mirja's proposed text into the conflict review document and let's discuss among the IESG by email. Let's try to resolve that in a couple of days. Mirja: Is there a way to reset all the ballot positions? Because it's completely different now. Barry: That's not a bad idea. I'll do that and we'll go from there. Amy, do I need your help on that or can I do it myself? Amy: I'm not exactly sure; I think we might need to do that for you. We'll experiment after the call and let you know what needs to be done. Barry: Excellent. I'll be in touch after the call. Does anyone else want to comment on this or are we done now? Okay, thanks everyone. Amy: Okay, so this sounds like it's going in AD Followup for now. 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 Mirja: A couple of things to report from the IAB retreat. One I briefly mentioned already was the future of the technical plenary. One outcome is that it's probably useful to split out the technical and administrative plenaries in the agenda, so there's a well defined start time for those who just want to come to the technical plenary. The proposal is to split off the technical plenary for the first hour and mark it that way in the agenda; the first hour will be tech plenary and afterward the administrative plenary. I don't have the exact items in my mind but it's basically switching the order of things in the plenary. And if there will not be a technical plenary there will be one hour extra for side meetings or even the deep dive. Any feedback on that? Warren: The technical plenary often generates interest & excitement. Of course, the other plenary does as well. But if at the end of 55 minutes there's a line of 27 people at the microphone ranting about a particular topic, are we really going to tell them to go away? Note that I'm perfectly fine with that. Suresh: We can tell them to come back at the open mic. Mirja: The plan is to actually keep to the hour. Alissa: We've done that in the past even with the technical plenary in the middle of the slot. Mirja: I will provide this feedback to the IAB. The second thing is a discussion they had about the document draft-iab-protocol-maintenance-03. It's about how we're not doing a good job of protocol maintenance. We have this practice, for example, of leaving mailing lists open even when we close the group. This doesn't really trigger what we want because people don't know there is still a list. It's not easy for people on the outside to find the right mailing list and ask about maintenance. I wanted to bring this back because that's maybe something for the IESG to consider too. Maybe we could have something like "inactive" instead of closed. If people are interested I'll bring it back to the informal at some point. Or actually, Ted, is there a plan to have further discussion on that in the IAB? Ted: We're still talking about whether or not to adopt the draft. Jari had some additional feedback on it. I think probably we'll end up adopting it but not in its current version. It would be great if the IESG read the current version and gave feedback to the IAB about how useful or not useful it is. Once we get into the question of what specific steps does the IESG want to take in response to it, then we can have that in a joint meeting in Montreal or just a joint email conversation. Mirja: Another thing is that the IAB also reviewed their current tasks and one is providing shepherds to BFs. There was a little bit of a discussion with two outcomes: one is that the IAB is still happy to do that and they are also welcome to be asked much earlier than the BoF call, which should be more useful. If you have an activity and you have need for an IAB shepherd, they are happy to be involved early on. The second part is that the IAB plans to outreach to the community that there is this opportunity to ask for a shepherd. Finally, the IAB also adopted a practice of announcing adoption discussions of documents on the architecture-discuss list. In the future, starting from now on basically, when the IAB plans to adopt a draft on a call they will discuss it on the architecture-discuss list. I think that's it. Ben: On the BoF shepherds topic, is it expected requests will still come from the IESG, or will they come from BoF proponents directly? Mirja: I believe there's also an opportunity for BoF proponents to ask but I'm not sure how this will be implemented. 6. Management issues 6.1 [IANA #1143383] Management Item: Acceptance of media type registration from standards organization National Center for Geospatial Intelligence Standards (NCGIS) (IANA) Michelle: We're looking to see if we can add this to the list of standard organizations that can get standards tree media types. Any objections? Barry: It seems like a reasonable thing to me. Ted: It seems like this was going to be an unusual request, so I'd process this request but not add them to the list. I don't know if that's possible. Barry: It's possible. Why would you object to adding them to the list? You're probably right they are not going to request more media types. Ted: Just because the center itself doesn't seem to be an SDO; it's a national standards body that does a very limited amount of things. It's not one that we'd for example consider liaising with. I have no objection to this registration, but I wouldn't make it a general approval. Barry: The point of the list is not to only have SDOs, but organizations we think are suitable for making these requests in the standards tree. I'm okay with making this a one off registration. Ted: Did they request specifically to be added to the list? Barry: This is an automatic thing; when someone requests a standards tree registration, we consider whether they're suitable for being added to the list. Ted: Thanks for that. Barry: Michelle I guess the answer is, process this registration, put them in the standards tree, but do not add them to the list. 7. Any Other Business (WG News, New Proposals, etc.) Barry: Back to the conflict review on safe-hint -- the ballot is cleared and the text is updated, so everybody please re-ballot on that. Thanks.