INTERNET ENGINEERING STEERING GROUP (IESG) Narrative minutes for the 2020-09-10 IESG Teleconference These are not an official record of the meeting. Narrative Scribe: Liz Flynn, Secretariat 1. Administrivia 1.1 Roll call ATTENDEES --------------------------------- Jenny Bui (AMS) / IETF Secretariat Alissa Cooper (Cisco) / IETF Chair, General Area Michelle Cotton (ICANN) / IANA Liaison Roman Danyliw (CERT/SEI) / Security Area Martin Duke (F5 Networks Inc) / Transport Area Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe Sandy Ginoza (AMS) / RFC Editor Liaison Benjamin Kaduk (Akamai Technologies) / Security Area Erik Kline (Loon LLC) / Internet Area Murray Kucherawy (Facebook) / Applications and Real-Time Area Mirja Kuehlewind (Ericsson) / IAB Chair 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 Martin Vigoureux (Nokia) / Routing Area Eric Vyncke (Cisco) / Internet Area Magnus Westerlund (Ericsson) / Transport Area Robert Wilton (Cisco Systems) / Operations and Management Area REGRETS --------------------------------- Deborah Brungard (AT&T) / Routing Area Jay Daley / IETF Executive Director Wes Hardaker (USC/ISI) / IAB Liaison Alvaro Retana (Futurewei Technologies) / Routing Area OBSERVERS --------------------------------- Mike Jones Alexey Melnikov Greg Wood 1.2 Bash the agenda Amy: Does anyone have anything new to add to today's agenda? Any other changes? [None.] 1.3 Approval of the minutes of past telechats Amy: Does anyone have an objection to the minutes of August 27 being approved? Hearing no objection, so we'll get those posted. Does anyone have an objection to the narrative minutes of August 27 being approved? Hearing none, so those will be posted as well. 1.4 List of remaining action items from last telechat o Martin Vigoureux with Wes, and Alvaro to work on some mechanism to obtain wider or private feedback from people who are disenfranchised; anonymous flagging of offensive emails to inform leadership; more opportunities for private feedback. Martin V: In progress. o Warren Kumari to work on acknowledging shepherds, directorate reviewers in a more standardized/formal way. Warren: In progress. o Eric Vyncke to write up draft text on Special Interest Groups and send to the IESG for comment. Amy: I think I saw email on this, is this item done? Eric V: It's done somehow, but the real item was to get IESG consensus around the draft text to move forward. Mark it as work in progress, and I've received comments only from Martin V and Mirja and welcome more. So keep it in progress. o Alvaro Retana, Benjamin Kaduk, and Murray Kucherawy to look at updating the I-D Checklist. Murray: Michelle and I are setting up a meeting to set up the IANA input to this. I'll have something for us next time. o Eric Vyncke (with Suresh Krishnan) to write a draft of an IoT Systems charter. Eric V: It will mostly be done after the management item. Let's talk later today on this and then it will be done. Amy: We'll mark this provisionally done pending the discussion in management items. o Alvaro Retana and Martin Vigoureux to draft text on guidance regarding the number of document authors on documents. Martin V: Still in progress. o Alvaro Retana, Rob Wilton, Alissa Cooper, and Martin Vigoureux to draft text on the framework for a long-term future plan for the IETF. Martin V: Still in progress. o Roman Danyliw to draft text for a request to the Tools Team to move BoF requests from the BoF Wiki to the Datatracker. Roman: We're a little further along than that. I'm going to talk to a subset of the tools team next week and come back to us with the options. In progress. o Alvaro Retana, Warren Kumari, and Barry Leiba to draft clarifying text on Errata Best Practices. Warren: In progress. o Murray Kucherawy to find designated experts for content SDP Parameters, QoS Mechanism Tokens [IANA #1175036]. Murray: I'll have that for next time. o Eric Vyncke to follow up on the suggestion at IETF 108 to share a list of grammar checking tools with the community. Eric V: In progress. o Barry Leiba to discuss possible datatracker feature request regarding flagging who is responsible for the next step for a document; the document authors, the WG Chairs, the AD Discuss Holder, or the Responsible AD, with Robert Sparks. The feature request should include a "length of time in state" flag. Barry: That is in progress and it should be done by the next telechat. 2. Protocol actions 2.1 WG submissions 2.1.1 New items o draft-ietf-detnet-mpls-11 - IETF stream DetNet Data Plane: MPLS (Proposed Standard) Token: Deborah Brungard Amy: Deborah could not be with us today. This does have some Discusses and Deborah asked that anything with Discusses go into Revised ID Needed. Does anyone need to discuss these Discusses today? Roman: As one of the Discuss holders, I'm good interacting with the authors so we're going to polish some text. Amy: Great, so this will go into Revised ID Needed as Deborah requested. o draft-ietf-detnet-ip-over-mpls-07 - IETF stream DetNet Data Plane: IP over MPLS (Proposed Standard) Token: Deborah Brungard Amy: It does have a Discuss; do we need to discuss this today or can this just go into Revised ID Needed as Deborah had requested? Ben: Hopefully we can talk about it today and I can clear. Was it Rob who had posted a position that said he supported Proposed Standard? Somebody did, but I don't remember who. Rob: I thought that Proposed Standard made sense here. My justification was that it is actually defining what behavior is mandated and required, so I can't see how Informational would potentially work. I did think PS was more appropriate. Ben: Okay. Do you think we should wait and have Deborah chime in or should I clear and we can approve the document? Rob: I think it would be good to have more discussion in a sense that quite a few people have raised that comment, so some discussion could be a good thing. Ben: Sounds like we have the resolution that Amy is looking for. Amy: This will stay in IESG Evaluation and go into Revised ID per Deborah's request and you can continue the conversation when she's back. o draft-ietf-stir-cert-delegation-03 - IETF stream STIR Certificate Delegation (Proposed Standard) Token: Murray Kucherawy Amy: I have a Discuss in the tracker; do we need to discuss that today? Murray: I don't believe so. The authors tend to be slow at responding to Discusses so I won't be surprised if this parks in Revised ID Needed for a while. Amy: Okay, this will go into Revised ID Needed. o draft-ietf-roll-turnon-rfc8138-14 - IETF stream A RPL DODAG Configuration Option for the 6LoWPAN Routing Header (Proposed Standard) Token: Alvaro Retana Amy: I have a couple of Discusses; do we need to discuss any of those or should we just wait until Alvaro is back to continue the discussion? Martin D: I did want to discuss them, but if no one is here to explain then I think we're done. We'll have to defer this to next time. Amy: It kind of sounds like it might require a Revised ID, so a substate of Revised ID Needed might be appropriate? Is that correct? Martin D: I'm not going to speak for Ben but I legitimately want to discuss this and figure out what they're trying to do. I think it's fairly likely there will be a Revised ID required but I could be persuaded otherwise depending on the outcome of that discussion. Ben: I'm in a similar position. If we think we need to talk about in person should we just move the telechat date to next time so we can talk about it while Alvaro is here? Martin D: I think so. Ben: So bring it back as a returning item? Amy: Okay, we're going to put it in AD Followup but also put it on the agenda for the next telechat, so it will come back on the 24th. Martin D: I think Ben and I have the same problem so there's really only one issue here. o draft-ietf-regext-rdap-partial-response-13 - IETF stream Registration Data Access Protocol (RDAP) Partial Response (Proposed Standard) Token: Barry Leiba Amy: I have a Discuss in the tracker; do we need to discuss that today? Barry: No, we need to have the authors discuss it. Put it in AD Followup, please. Ben: I've very low confidence that I actually understand what's going on, so it's quite possible I just misunderstand and there's no issue. Barry: The author is not a native English speaker and sometimes we may need to tweak the English or he may not understand you. We'll sort it out. Amy: Okay, we'll put that in AD Followup. o draft-ietf-lamps-ocsp-nonce-04 - IETF stream OCSP Nonce Extension (Proposed Standard) Token: Roman Danyliw Amy: I have a Discuss in the tracker; do we need to discuss that today? Roman: No, I think the authors are being responsive to various feedback, and we'll be able to resolve this. Thanks for everyone's feedback. Rob: Quick question. The discussion of the term 'nonce,' should that happen later on? Roman: That was my thinking. Rob: That's fine. Amy: Is this going to require a Revised ID? Roman: Absolutely. Thanks. o draft-ietf-cbor-7049bis-14 - IETF stream Concise Binary Object Representation (CBOR) (Internet Standard) Token: Barry Leiba Amy: I have a Discuss in the tracker; do we need to discuss that today? Barry: No, I think not. I think another one that we need to have more conversations with Carsten about that. Ben: The only thing we might want to discuss would be the tag number 35. Barry: That is the point I'm thinking of, and I think that's a discussion with Carsten. We should be able to resolve that. This one I'm sure will need a Revised ID. o draft-ietf-mpls-base-yang-15 - IETF stream A YANG Data Model for MPLS Base (Proposed Standard) Token: Deborah Brungard Amy: I have a couple of Discusses in the tracker. Unless there's something to discuss today, we're just going to put this in Revised ID Needed as Deborah has asked. Anything to discuss? Great, that will go into Revised ID Needed and we'll move on. o draft-ietf-cbor-date-tag-06 - IETF stream Concise Binary Object Representation (CBOR) Tags for Date (Proposed Standard) Token: Barry Leiba Amy: There are no Discusses in the tracker so unless there's an objection now it looks like this one is approved. Barry: Let's just stick this in AD Followup so I can make sure there's nothing that needs to be tweaked. 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 NONE 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 NONE 3.4.2 Returning items o conflict-review-atkins-suit-cose-walnutdsa-00 IETF conflict review for draft-atkins-suit-cose-walnutdsa draft-atkins-suit-cose-walnutdsa-05 Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) (ISE: Informational) Token: Benjamin Kaduk Ben: We'd kept this over from last time and I was supposed to think about if there was any text we could put in the document instead of an IESG note. I thought about it a little bit but not as much as I would have liked. All the text I'm coming up with is not things I expect the authors to find acceptable. I'm inclined to make the edits to the IESG note and send it with that but I'm also open to trying to mull it over a bit more. I don't know there's anything we need to discuss as a group specifically. I think we can probably just leave this in IESG Evaluation. Amy: Will this come back? Ben: I'll try to just take care of it out of band. Roman: I'm happy to give you a hand. Amy: We'll wait for instructions from you, Ben. 4. Working Group actions 4.1 WG creation 4.1.1 Proposed for IETF review o Building Blocks for HTTP APIs (httpapi) Barry: I think Mark just responded to at least one of the blocks. We've got some updates in there. The response was specifically to Roman's No Objection ballot but it might address other things as well. He posted a GitHub. For those of you who have blocks, take a look at the GitHub link Mark posted. What are the substates on charter ballots? Amy: It's basically pending. Barry: Okay. Hold this and I'll let you know when it's ready. Hopefully Mark's edits will have satisfied enough. o Secure Media Frames (sframe) Amy: We have a couple of blocks. Do we need to discuss those? Murray: Just one point. Eric V's block was not sent to the WG and I'm wondering if that was intentional. Eric V: Ooh, that's a mistake of mine then. Sorry. Murray: Okay. I reminded them to look at the datatracker for that additional feedback. They've been very responsive so far with what Magnus put in his block, but they didn't know about yours, so you'll start to get them soon. We're on top of it and we'll have to wait for the proponents to come back with feedback. Magnus: I haven't seen much on mine. Murray: They may only be responding to the dispatch list, discussing it among themselves, and it's possible they're not talking to you directly yet. Magnus: I'm on the dispatch list so I can check there. Eric V: Was it all really on the dispatch list or is there an sframe mailing list? Magnus: There's sframe also, so I will check that too. I actually want to discuss this a little bit. I have no problems defining the basic sframe et cetera, I think when it comes to the RTP payload format and the interactions between an RTP payload format and some of the goals, etc, is where they've run afoul on that current language. It becomes a bit contradicting because if you're going to define something that works for RTP without another layer of configuration you do get into issues there with the complexities of RTP and some of these stated goals. It's not clear to me how to move forward. Murray: I think I'm going to wait for the authors to come around on it. RTP is not an area I'm really strong in anyway, so I still have to find an opinion. They seemed very eager to answer you so I think this will start to move in some direction. Magnus: I will go read what they write. Alissa: I think as a general matter, how much of this really needs to be documented in detail in the charter vs being part of the discussion in the WG is a useful question to ask. Murray: That's good. Alissa: I don't think you'd want to be going down this path of designing the thing in the charter, with respect to the interaction with RTP. Magnus: My problem is really that they said we're not going to do this particular part which would make the RTP payload format useless unless you had a very particular system, which can work in the context of WebRTC InsertableStreams but basically nowhere else as I see it. That was my kickoff point from here. I'll review and try to comment on it. Amy: So it sounds like we're going to wait for the go-ahead. o Revision of core Email specifications (emailcore) Amy: I have no blocking positions, so it looks like external review is approved. Barry: I'll probably make a tweak to the charter before that actually goes out but there's no reason to hold anything up. Ben, I'll put something in about your SMTP security thing. We'll work up some milestones, although possibly not before it goes out for external review but before it comes back in two weeks. I'll point out that John Klensin put up a post last night on the IESG list about this. He's mostly concerned whether there's really critical mass to get stuff done on this. Part of the issue is there was some confusion about announcing the mailing list. We should talk, maybe at the retreat, about how mailing lists get created for pending WGs. They don't go into the non-WG mailing list list, and they're not WG mailing lists yet, so we've been getting some dropped balls on announcements of mailing lists that are pre-created for pending WGs. Anyway, yes Amy, this is ready to go. Amy: Great, so external review is approved. o A Semantic Definition Format for Data and Interactions of Things (asdf) Amy: I have a block for the charter, so do we need to discuss this today? Barry: Ah, the block just came in. Rob: I'd intended to raise it here and discuss here. I just wanted to note that the charter doesn't mention Yang at all. My question was whether that should be discussed or referenced or mentioned in any way or all those groups like NETMOD that's working on it, whether they should have some point in the charter, or whether it was better to keep them totally separate. Barry: I'm not sure why. What is it about this particular charter that you think relates to Yang? Rob: I see that the OneDM language is primarily almost equivalent to what Yang achieves but specialized to IoT devices. So it's got a slight angle where it's focusing more on operations rather than configuration, whereas Yang I would say emphasizes the other way around, but their capabilities seem to be very similar. I've no objection to work going forward but I wonder whether we should have some comment or review between those two experts to make sure we're not shooting ourselves in the foot. Barry: Okay. Let's hold this and see if there's any response from the proponents about your block, since it just got posted they obviously haven't responded yet. Let's see what they say and then discuss it further. Rob: Okay, thanks. Amy: So we'll wait for instructions from you, Barry. 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 Amy: Our IAB liaison is not with us today. Any news from Alissa or Mirja? Mirja: I don't think so. Alissa: Just one item to plan for. We did talk about this special use names topic which has come up again and again about domains in the root zone of DNS. We do have a document about this which we used to allocate .onion and have not used since. There's a lot of history and context there. This is coming back up in DNSOP. I think the thing for the IESG is that this is being handled in DNSOP and Warren is the author of one of the documents, right? Warren: Only kinda sorta. I have a number of documents which went into DNSOP and then got stuck in this morass of what's happening with special use names. I have a document which is somewhat related in a different organization and then an employee of that organization has a document in DNSOP. It's all very weird. But this is partially of special use but more liaison questions between DNSOP or the IETF and both ICANN and ISO. Alissa: One of the conclusions in the IAB discussions was that it's important for the WG to follow normal WG process, and normally we wouldn't liaise about things that are individual drafts. The only reason I bring this up is because I think if the WG chairs are going to follow normal process and do a call for adoption, and you have a draft which is kind of in the mix there, it would be good to get another AD to be the shepherding AD. Warren: Rob is the shepherding AD. I thought of that a long while back. Alissa: Oh, okay. Great. Warren: There was a call for adoption and then before formally adopting the document the chairs wanted the liaison question answered. It was the chairs who said we're in this position and don't know if it will cause issue, we would like the liaison question answered. Alissa: That's not how it was conveyed to the IAB. So there's already support for adoption? That's what the chairs have concluded on the list? Warren: No, there was a call for adoption. The chairs are unclear if there was sufficient support to some extent because the WG doesn't know what the liaison stuff would all mean. The WG participants are unclear if this is stepping on other orgs' toes, so the WG participants and chairs are stuck in this standoff where they don't know if they should adopt the document or not because we don't know if this is going to cause inter-SDO grumpiness. Alissa: Okay. We can take this offline. 6. Management issues 6.1 [IANA #1177131] Acceptance of media type registration from standards organization IMS Global Learning Consortium Inc (IANA). Amy: Has anyone had a chance to look into this? Barry: Yes, I have as always, and it looks like it is a legitimate subject matter of standards organization that should be listed. Alissa: I agree. Amy: Any objection to adding them to this list? Hearing none, so we will send official note to IANA. 6.2 Chartering IoT systems and IoT operations (Eric Vyncke) Eric V: Thank you Alexey for joining us to discuss on email. This task on my to-do list came when Suresh finished his term, and he got this task a couple of weeks before from Ignas. It's actually to handle stuff like MUD which is currently in OPS. Warren and Rob, it's basically the same thing we discussed a couple of telechats ago or somewhere else, where you want to get an IoT operation group. Basically for Suresh and myself, that's all the same. Getting something that handles not only MUD but all the operation of IoT would be a nice thing. Rob: The next step as well is for Warren and I to start working on a charter, is that the right next step? In terms of previous discussion here, I think there was support for doing something like this, an IoT ops WG with a focus on MUD and maybe onboarding as well. Warren: That's sort of what I remembered as the next set of steps that we were going to try to make a charter work. We should also get Eric and Suresh to have a look and provide input first. One of the things that we need for that is chairs, which dovetails nicely to something which you had wanted me to bring up. Rob: There's been a suggestion that Henk Birkholz might be a good person to chair an IoT ops WG. He has the IETF experience, but doesn't have any WG chair experience. As part of that I proposed to add him as a third chair to OPSAWG, focusing on the existing MUD documents, so he could gain some WG chair experience and experience MUD documents with an aim of potentially making him a chair of this group. We'd need another chair to go with him. There are a few names but if anyone had any other names that would be useful. Eric V: You may want to reach out to Alexey. Warren: That's a great idea. Eric V: I think Alexey knows the process, to understate it. Mirja: What's the actual benefit of having this generic potentially long term IoT operations WG instead of just forming a WG right now focusing on MUD? Warren: There's a lot of related work that isn't just MUD. We keep having people come along with new IoT work who wonder where to put it and we usually say [I don't know] and this would be somewhat of a place to take it. We have a lot of people coming along with onboarding type discussions and we don't have a good place for them to talk about it. Mirja: Isn't ANIMA a good place to talk about onboarding? Warren: Nope. ANIMA is very close to closing down, they're focused on their little slice of stuff they're working on, they don't do generic onboard stuff, so no I don't think ANIMA is. Roman: I'm not understanding. We want to specify another onboarding process that isn't ANIMA that's different, dare I say lighter weight? Warren: No, we want to have space where people can discuss things. We don't want to say this is the new onboarding thing, but when people come along with questions like 'how do I do onboarding?', we don't currently have a good place for them to discuss it. In some ways this is similar to some stuff that's happening in MOPS, where there's a place for people to discuss issues they're seeing, operational type issues with IoT things, one of which was the constant problem of 'I don't know how I should best do onboarding of things' and ANIMA does not seem to be the right answer for many people. Rob: As some of this, some of the work that's currently in ANIMA may also move into this IoT ops group. Then as Warren says we'd look at what's left in ANIMA, and maybe that work completes or moves into ops. But I'm not sure ANIMA should hang out for a long time. Warren: ANIMA is a very heavy weight process designed for mainly onboarding network devices; it's not very well suited to onboarding my new IoT vacuum cleaner or lightbulb. I'm not saying we should build something which is perfect for onboarding my lightbulb or vacuum cleaner, but currently when people want to talk about we say we don't know where they should go. Rob: Or they end up in OPSAWG which is not really a great place for them. Mirja: ANIMA lite, or a completely different set of protocols? Warren: We don't know yet, we're talking about a place where people can come along and have a discussion. Roman: Are we going to scope this to class 1 and class 2 devices, so a smaller thing than ANIMA is doing, or are we thinking the same coverage ANIMA is doing? I'm just trying to get my head wrapped around the size here. And if we don't know, that's ok too. Warren: I think we don't know. A fair bit of this is going to be people coming and saying they want to do a sort of thing, and people say what you're trying to do has already been solved by stuff in WG X, you should go along and talk to them. In some ways this is a WG which does things like MUD, and also something with some similarities to MOPS / DISPATCH type things, where we can say 'that's an interesting problem you're trying to solve, have you considered doing x?' Mirja: I'm not sure if mixing all these concepts together is the best approach. One is an actual technical problem that can be well scoped and you want it solved, which could easily go into its own small WG. The other one is just providing people a place to go, which is the idea behind MOPS which I'm still not sure I completely understand, and the third one is dispatching stuff. We have some groups which are only chartered to dispatch, to not take on their own work. I think it's good to keep those things separate and not mix everything together. That's why we have WGs, because we want to have a charter which has clearly defined the work we want them to do. When you mix it together it's broad like do whatever you want, and that's not actually what we want. Alissa: We've talked about this like seven different times in various IESGs in the last four years. It would be useful if the people who want this could write down the charter as was discussed earlier in conversation, and then we can talk about it in the community. It's been a really long road on this and I don't think the IESG of whatever composition, including the previous five years of IESGs, are going to be able to come to a conclusion. We really need to get input from the community on a specific charter proposal. Eric V: This sounds fair to me. Amy, can you remove this action item from my to-do list and and add another one for the charter? Amy: What's the new action item we should record for someone? Warren: I guess if you wouldn't mind creating a new item for Rob and Warren to create IoT Ops charter. Amy: Great, we'll create a new action item for Warren and Rob. Thank you. 6.3 Refactoring virtual hum tool (Alissa Cooper) Martin D: The small group has made a fair amount of progress on this; we incorporated some feedback from the survey and personally collecting a lot of feedback. The first thing we did is agree there's a need for a hand-raising tool, if nothing else for questions like who's read the draft. Once we made that decision Alissa pointed out that we weren't very far from that being the virtual hum tool. What does a hum provide that a show of hands does not? Anonymity, vagueness (without exact counts), and a way to indicate intensity by humming loudly or softly. We agreed fairly early on that we could make a show of hands anonymous. If you do want to do something like find out who's going to work on a draft, there are tools like chat for that so it would be fairly efficient and preserve that value. Second is vagueness. A lot of people didn't like [the hum tool] and thought it was confusing. I did find that we had long detailed discussions about the design people thought it made sense, but that's not something that's going to happen at scale. The obscuration involved in making it vague just makes it confusing. Our conclusion was just to go ahead and not be vague and report numbers, and trust chairs to not do things like say "it's 35 to 30 so that's consensus." I think we're comfortable with using a hands tool for that. The last bit is intensity, and we didn't actually feel strongly about this one, so this is something we really wanted to take to the larger group. Do we want to have a facility where we can let people raise their hands with intensity? So you can signal strongly or weakly to indicate passion. Would that be viable or would that be too confusing? Rob: Can I answer that with a question. In person meetings we do two hums, one for and one against. It felt to me at 108 that doing that with the countdown time felt very long and people were less keen on doing hums in both directions. Would it be possible to answer positively and negatively in the same hum, or count, and if so then you could potentially give people a scale one for, one against, and everything in between. Martin D: Possibly. Sometimes you have three way hums or something. The more we instrument a structure to the discussion and the choices that are presented, the harder it is to adapt in different places. This is a UI issue but one comment we had that we'll probably incorporate in whatever tool we have is more live feedback, so the show of hands tool could have a counter as people vote, maybe a stop button. Next week we're going to work on a written spec for what we want to do. What I really want is feedback on if this intensity question is important. Many of us have been WG chairs and obviously have seen a lot of how people operate. Does that matter or do we think everyone would use just a straight show of hands? Mirja: I always thought the intensity is rather a side effect from humming but not an actual feature we need to support. That's just my opinion. Rob: I agree with that one. I think a straight yes or no is probably fine. The only advantage I can see to having an intensity thing is having a bit more obfuscation in results, that you don't know if the intensity was between 0 and 1 you don't know there are ten people who voted that way, but I don't think that really matters. Martin D: We got a lot of feedback on how that obfuscation makes it difficult for people to interpret the results, unfortunately. I think it's a good design in terms of modeling the way the hums work and creating its properties, but without forcing everyone to go through training it's just too hard to interpret for people. I'm not hearing anyone speak with even moderate passion for having intensity indicators. To be clear, what we're proposing then is a show of hands tool that's anonymous, so you could vote up or down on something probably one question at a time, and you'd get just absolute numbers of how many people did or didn't raise their hands. Mirja: An easy way to obfuscate a little bit is instead of putting the total number in you just have buckets, like you could say it was between this and this. Martin D: We're strolling down the same road we went on last time. Then you get questions like are those absolute buckets, or are they normalized to the size of the room? Mirja: You have to adapt the buckets. You can make all the buckets the same size so the larger the room the more buckets you have. But you know the number of people in the room already, so that's information you already have when you look at the result. The confusing part is to have both the obfuscation and the intensity level. Alissa: My biggest takeaway from reading all the feedback was that the thing was way too complicated in its presentation and the underlying algorithms. It just was incomprehensible to people. I think experimenting with simplicity and seeing what happens would be a good comparison. It's really important the point that Rob raised of what is the semantic. Are the choices I can raise my hand or I cannot raise my hand, or a thumbs up or thumbs down, which is different? It's really important to be very clear what the semantic choices are. Mirja: Whatever we do, we'll be closer to voting than in the room, so in that case I think it's okay to actually do some kind of voting as long as the chairs do a good job of interpreting it. Martin D: I agree that what you proposed would allow us to do some obfuscation if we think that is important. Ben: In the vein of Alissa's comments, to start with something simple, I'm not sure we want to deliberately introduce lots of obfuscation. If it's a question of just giving a summary count instead of the list of people who raised their hand that's fairly natural, but I don't think we want to add further obfuscation than that right off the bat. We can start with something simple and see how it goes. I was also going to say I personally have some interest in degrees of intensity information but it's probably better to just start with something simple and see where that gets us. Martin D: In meatspace what we do is after the show of hands someone will often ask 'Can anyone not live with that?' Which is going to be another way to achieve that without tooling. Any other comments? I think we're going to proceed with a very simple tool, then. There are still some UI questions to work out but the small group will work on it and we'll probably have something in a few weeks to discuss. 7. Any Other Business (WG News, New Proposals, etc.) Roman: I wanted to talk about one final thing we've been trading some email on, which is what do we want to do with the documents that use the word 'nonce' given the slang terminology which was brought to our attention? Rob: I'm not sure what I can add. In British English it's defined as someone who's a sexual offender. It's a slang term and fairly widely known. As I said in my email I'm not sure whether people would be upset seeing this term or just surprised. The only other observation I made in that email is that lots of words have different meanings in other languages that are not ideal, so there's a risk you go too far down this road and end up painting ourselves into a corner. Ben: One thing that comes to mind is to be fairly rigorous about always using 'cryptographic nonce' and not just use the word 'nonce' in isolation. I don't know how much that would change things. Warren: I don't think someone's going to see 'when you create the packet you should include a nonce' and think 'I need to stick a sex offender in the middle of my packet.' It seems like this is clearly enough separation there's not going to be a source of confusion. I don't think the random number is going to be offended, so there are only so many ways you can make sounds in human languages and there's going to be some collision. The Chevy Nova is a classic example. Sometimes there are going to be collisions in words, and unless this one is likely to cause confusion, which I don't think it will, or offense, and I don't think many sex offenders are going to be offended. Martin D: I don't know anything about this, but I'd imagine if there was capacity for offense it would be in a victim based on whatever traumas they'd suffered because of that term. Have we had any explicit objections to it, or is this kind of an 'on behalf of' concern? Rob: I raised this because I was aware of the word. No explicit objections. Warren: This one feels like it might be going a bit far. Alissa: It's not necessarily a one size fits all either. The distinction between the document and the charter we had on today's call is perhaps useful. I think it's okay for people to suggest different language for the charter because it's really not necessary for it to be there anyway, if the usage in the document is a referent back to a previous version. It becomes more troublesome to have to try to craft something that readers are going to be confused by there might be a different outcome. You'll have to do a case by case suggestion. If this word is basically an acronym, why isn't it capitalized? Ben: It's not exactly an acronym, is my understanding. There's been independent usage of the word for a similar meaning in historical English usage, not in the technical usage. Warren: It's an abbreviation more than an acronym. Rob: I thought Ben's suggestion was quite sensible. Roman: Maybe the advice here is, do a regex search where possible, concatenate 'cryptographic' before the word 'nonce.' Does that seem unreasonable to anyone? Rob: That's sensible to me. Roman: Then I'll work with the author on that.