Skip to main content

Narrative Minutes interim-2020-iesg-20 2020-09-10 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2020-09-10 14:00
Title Narrative Minutes interim-2020-iesg-20 2020-09-10 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

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

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

Deborah Brungard (AT&T) / Routing Area
Jay Daley / IETF Executive Director
Wes Hardaker (USC/ISI) / IAB Liaison
Alvaro Retana (Futurewei Technologies) / Routing Area

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?

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

     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

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

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

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
   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,

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
   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


2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items


3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items

 o conflict-review-atkins-suit-cose-walnutdsa-00
   IETF conflict review for draft-atkins-suit-cose-walnutdsa
     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

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

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

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


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


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

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

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.