Narrative Minutes interim-2022-iesg-06 2022-03-03 15:00
narrative-minutes-interim-2022-iesg-06-202203031500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-03-03 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) / incoming Routing Area
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Benjamin Kaduk (Akamai Technologies) / Security Area
Erik Kline (Google) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Eric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
Paul Wouters (Aiven) / incoming Security Area

OBSERVERS
---------------------------------
Ben Schwartz
Lee-Berkeley Shaw
Greg Wood

​​
1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to the minutes from the February 17th telechat
being approved? Hearing no objection. Does anyone have an objection to the
narrative minutes of February 17 being approved? I'm hearing no objection there
either; we will get those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     NONE

   * OPEN ACTION ITEMS

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.

Martin V: The text is drafted; I've confirmed that I'm okay with it to Alvaro,
so I think he will take over and submit it to you for a final check. It's in
progress and nearly done.

     o Robert Wilton, Alvaro Retana, and Warren Kumari to report back to
       the IESG on the impact of COVID-19 to the IETF in March 2022.

Amy: This is on hold until next week.

     o Murray Kucherawy to look into updating the guidance in BCP 13 on
       when to add organizations to the "Standards-related organizations
       that have registered Media Types in the Standards Tree" list.

Murray: This is in progress; I'm collecting information from people with grayer
beards than mine about why we do this and the history behind it so I can get
the proposal right. I should have something next time.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-dnsop-svcb-https-08  - IETF stream
   Service binding and parameter specification via the DNS (DNS SVCB
   and HTTPS RRs) (Proposed Standard)
   Token: Warren Kumari

Amy: I have a number of Discusses; do we need to discuss any of those today?

Warren: Only for me to apologize and say I have not kept up with the Discuss
stuff. Ben Schwartz is usually good at responding to stuff so I'm assuming that
he is under control and doing things. Let me apologize to him as well because
he's on the call and ask him if there's anything quickly that he wants to ask.

Ben Schwartz: I've noted a number of Discusses and I've tried to answer
questions where I have them. I haven't gotten to Francesca's response yet but
I'll try to do that shortly. It's clear the draft is going to need some
revisions before it goes back to the IESG so I think you can expect to see an
-09 relatively shortly.

Warren: Excellent, thank you.

Amy: Unless anybody has anything else, it looks like this is going to stay in
IESG Evaluation with Revised ID Needed. Thanks.

 o draft-ietf-kitten-tls-channel-bindings-for-tls13-14  - IETF stream
   Channel Bindings for TLS 1.3 (Proposed Standard)
   Token: Benjamin Kaduk

Amy: I have a couple of Discusses on this; do we need to discuss those today?

Ben: I was kind of curious if anyone else had thoughts, or had looked at the
updates question at all, or if we should just go forward based on my own
assessment of things.

John: Can you remind us of what your assessment of things is? Give us a short
capsule of what you think the state is?

Ben: Sure. The author thinks that this draft, which is from the KITTEN WG, not
the TLS WG, should update the TLS 1.3 RFC because it says something like "the
channel binding types that were previously defined as the default are not
defined for TLS 1.3." That's still a true statement, that the previous channel
binding types are not defined. We are just defining a new one here that does
work for 1.3. I forwarded the IETF Last Call to the TLS list and we got a
decent amount of feedback, with a few people pretty strongly opposed to making
the updates relationship. Mostly on the grounds that the original reason for
leaving the channel bindings out of RFC 8446 was because we hadn't done the
formal analysis we did for the rest of the protocol. We haven't actually done
any more formal analysis since then; we're relying on the analysis that was
done for the TLS expert construct in general, but we have not analyzed
specifically the use case here. The TLS exporter is supposed to provide some
nice properties for its output values, but we haven't analyzed how we would use
the output values as a channel binding. My stance is that one, the TLS WG has a
pretty authoritative say on what should update or not update its output, and if
this work was proposed in the TLS WG the threshold of review and formal
analysis we currently expect for things from the TLS WG has not been met. So I
don't think the TLS WG would have agreed that this is a core part of the TLS
1.3 specification. Does that answer your question?

John: Yes it does, thank you. Based on the information you just shared, which
jogged my memory, I am okay with having it not update. I agree with Martin's
Discuss on the top that of course the intro and header should match.

Ben: Yes, they definitely need to match. Hearing nobody else, I will thank you
and Amy, this is going to be Revised ID Needed and we should move on.

Amy: Thank you Ben.

 o draft-ietf-ipsecme-ikev2-intermediate-09  - IETF stream
   Intermediate Exchange in the IKEv2 Protocol (Proposed Standard)
   Token: Benjamin Kaduk

Amy: I have no Discusses in the tracker, so unless there's an objection it
looks like this is approved.

Ben: Let's put this in AD Followup. I'm pretty sure the author plans to post an
update, but I will just sync up with him.

Martin D: I didn't want to play security AD, so I didn't want to push the point
very hard, and I was glad to see that Valery was willing to add some text, but
there was this concern about it not really being precise about what data can go
in these messages. I don't know if you saw that part of the thread.

Ben: I guess I didn't see that particular part of the thread.

Martin D: In my comment I said it doesn't really say don't put application data
in this or whatever. I understand the intent of this design is to essentially
extend handshake messages, which is completely valid, but it's not very
restrictive about this mechanism. Valery proposed some text that was like, we
envisioned this to do this, so there's non normative text that says you
shouldn't do other stuff with it. I don't want to play security AD but i wanted
to raise the point with security ADs and say, like, I don't know if you want to
suggest to Valery that he tighten it up more normatively.

Ben: I can certainly take a look. I don't remember offhand what core and ipsec
say about user data in IKE packets before the handshake is completed. This
really is before the handshake is completed and you haven't authenticated the
peer and whatnot. I will certainly look at what we end up with as the new text
with that in mind.

Roman: Martin, listen, everyone gets to play SEC AD, the same way the SEC ADs
get to play ART and all the other ADs. All feedback is welcome. I also don't
know what the core ipsec standards say but there's no harm in having a reminder
sentence like remember there will not be application data here for the
following reasons, or just as a reminder you shouldn't do it by citation or a
simple sentence.

Martin D: Like I said, Valery is already committed to do a non-normative
sentence to do that. I just wanted to ask the question if he thought there
should be more and if the answer is no, that's fine and I'm perfectly
comfortable with that. It's not like people are going to start packing
application data in these things. There has to be a spec for it. There are
other opportunities to catch that problem if it arises, so I'm not super
worried about it, I just wanted to flag it for you guys to think about. Thanks.

Ben: Extra eyes are always appreciated.

Amy: So this one looks like it's Approved, Announcement to be Sent, AD Follow
Up and we'll wait for you, Ben.

 o draft-ietf-ecrit-similar-location-18  - IETF stream
   A LoST extension to return complete and similar location info
   (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have no Discusses in the tracker, so unless there's an objection it
looks like this is approved.

Murray: Also AD Followup. I just want to see if the authors want to respond to
any of the comments they got from directorates or the IESG.

Amy: Okay, this one will also be Approved, Announcement to be Sent, AD Follow
Up.

 o draft-ietf-httpapi-linkset-08  - IETF stream
   Linkset: Media Types and a Link Relation Type for Link Sets
   (Proposed Standard)
   Token: Francesca Palombini

Amy: I have a Discuss for this document; do we need to discuss that today?

Francesca: Let's discuss it. Thank you Lars for noticing the last call was
missing a couple of downrefs. I believe the reason is that this was originally
informational and after last call review comments and community discussion it
was decided to move this to proposed standard instead. We had a second IETF
Last Call and the tool didn't pick up the downrefs and I didn't notice them. So
that's why they were not included in the second Last Call. Ben, you're bringing
up should we have a third IETF Last Call since these documents are in the ISE
stream? In general I would maybe avoid that, because it's not just a two week
delay but a five week delay given that there's an IETF [meeting] and the next
available chance to approve would be the telechat after IETF 113; and also we
will lose some of you. Maybe in this case given also the question about
internationalization, it might be good to give a little bit more time even if
it's a significant delay. I want to hear what others think as well.

Lars: When we discussed these downrefs I was originally of the opinion that we
could probably avoid the Last Call, but I didn't understand these had been
published on the independent stream. So when Ben raised that, that actually
flipped me and I do think we should do another Last Call. These documents that
are being referred to have not been Last Called, they just have been conflict
reviewed. Normatively depending on those is something I don't feel comfortable
doing without a Last Call. Sorry for the delay.

Francesca: I understand your point of view.

Ben: I think I'm in a similar point of view as Lars. The actual content of
those two documents doesn't seem particularly worrisome to me but I just don't
really feel very comfortable de facto promoting them to Standards status
without any real IETF review on them.

Francesca: We would not be promoting them or anything.

Ben: That was a figure of speech rather than a technical term.

Francesca: Another thing I wanted to bring up is that this is still lacking at
least two more reviews. For those who have not reviewed it, it would be great
to have a couple more so that after the Last Call there will be less work. So
then I will move this back to Last Call. And for your information, about the
internationalization question, in my AD review I had meant to send it to the
directorate but I realized I must have missed that. My error, but it's good
that now I can do that during the additional two weeks.

Ben: Yes, now we get a second chance to do that.

Francesca: Thank you so much for the thorough review, it's very much
appreciated. I guess the status will be back to IETF Last Call.

Éric V: Francesca, by the way, I'm puzzled by having two formats for the same
content. Is it the lack of consensus? Merging two drafts together?

Francesca: No. I don't think I've seen your comment.

Éric V: It's nothing bad, more about getting the two formats.

Erik K: I thought that was covered in the document..

Ben: It didn't seem concerning to me, and the HTTP media type negotiation
mechanisms make it very clear which one you're going to get.

Éric V: It means the server needs to support both of them, right?

Ben: Unless it's in a very controlled environment, yeah.

Éric V: Again, not a Discuss, I was just curious.

Francesa: Hopefully if there is text lacking there we can add some context
about it. I will be working with the authors to answer these comments and also
start this Last Call. Thank you, everybody.

Amy: As a point of information, it doesn't look like the Datatracker even now
recognizes that there are downrefs on this document. I don't know how to fix
that.

Lars: Open a ticket, because this seems like a bug. It doesn't show any
references. I think there's something fishy about the extraction here which is
still text based and not XML based. I think Robert will want to have a look at
this.

Francesca: The references don't show any reference; the nit link in the
datatracker does show that there are two downrefs.

Lars: But the idnits link uses a different tool than the datatracker uses for
extraction. Idnits still uses Henrik's old batch script.

Francesca: That's probably why the generated text didn't pick up on those. I
will open a ticket.

Lars: Great, thanks.

Amy: Thank you, Francesca. That will go back to the WG for Last Call and let's
move on.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-tcpm-ao-test-vectors-08  - IETF stream
   TCP-AO Test Vectors (Informational)
   Token: Martin Duke

Amy: I have consensus as Unknown; I'm going to change that to Yes for you. And
I have no Discusses in the tracker; so unless there's an objection now it looks
like this one is approved.

Martin D: Lots of good comments, they seem like pretty minor stuff. This will
be Revised ID Needed and thanks for the reviews, everyone, this is a pretty
good turnout for an Informational document and I appreciate it.

Amy: Okay, this is Approved, Announcement to be Sent, Revised ID Needed.

3.1.2 Returning items

 o draft-ietf-alto-path-vector-22  - IETF stream
   An ALTO Extension: Path Vector (Experimental)
   Token: Martin Duke

Amy: I have a Discuss in the tracker; do we need to discuss that today?

Martin D: I haven't really had a chance to digest this. Ben, do you want to
chat about it, or do you think it's relatively straightforward for the authors?

Ben: Well, the first half I think is pretty straightforward because the
registry already exists and we can just put the registration in. I didn't
actually check the registration policy but hopefully it's compatible. The
second part I'm not so sure about though, because there's a snippet of the core
alto spec that seems to say you MUST use one of these two specific choices for
the cost mode, and then we're trying to use a new one in here. If that part of
7285 really does apply to all future extensions to alto, it would seem you need
to revise 7285 to relax that restriction and establish a registry to track the
extension point and whatnot. I don't really know how much of that you can do in
an experimental document like this. Probably someone, I guess you, should
actually look at the details a little more about what is the scope of that MUST
from 7285 and confirm that the IANA registry for the other rone has a
compatible registration policy. It could prove to be a gnarly problem that
maybe we need a two page document that's standards track and updates 7285 to
relax this. Which is never fun.

Martin D: Yeah. Okay. Well, good catch. I seemed to recall there was a cost
calendar thing which I think was an array, so maybe we already violated it. I
don't know. I'll take a look at it and see, thank you. So this is obviously a
Revised ID Needed and I think that's it.

Ben: I definitely noticed when I was looking at the registries that there was
very little in them other than the initial population. And I wonder if some of
the other alto docs failed to update the registries as well.

Martin D: Thank you. Amy, this is Revised ID Needed and I'll look into that.

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-irtf-icnrg-icn-lte-4g-00
   IETF conflict review for draft-irtf-icnrg-icn-lte-4g
     draft-irtf-icnrg-icn-lte-4g-11
     Experimental Scenarios of ICN Integration in 4G Mobile Networks
   (IRTF: Informational)
   Token: Lars Eggert

Amy: I have no Discusses in the tracker for the conflict review message, so
unless there's an objection now it looks like the no problem message can go
back to the IRSG.

Éric V: I don't want to put a Discuss or a Block on this, but i think this work
is related to work in INTAREA but it doesn't prevent publication. I think that
would be a more accurate statement.

Lars: What work, particularly?

Éric V: Basically it looks like everything done vaguely to DMM and as soon as
it touches the IP layer and mapping of certain v6 addresses, we don't have a WG
on this, which is to be expected, but it's related. I think it would be more
accurate to describe it this way.

Lars: Okay, so I'll change it to that, if nobody disagrees with that change.

Éric V: That would be nice. Thanks.

Lars: Okay. I'll do that on the call and we can send it after.

Amy: Okay, so this will change to -01 and we'll send that conflict review
message on Monday to the IRSG.

3.4.2 Returning items

 NONE

4. Working Group actions
4.1 WG creation
4.1.1 Proposed for IETF review

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Martin V: I couldn't attend the IAB meetings so it's up to Lars or Mirja.

Mirja: Just because Francesca brought this up in the chat already; we have the
docs related to the RFC model in Last Call currently, and hopefully for
approval next week, all three of them. The next steps for us are to start two
things, one is the IAB and IESG are responsible for selecting the chairs for
the new RSE working group. Second, an action item on our side is that each of
these groups need to select a representative for the RSAB. The IAB is planning
to select a representative in our Sunday meeting, where we usually select any
kind of liaison. So that's something to consider from your side.

Lars: The only other thing is we talked about the timeline for making changes
to the RFC Editor model. There's a trello board, I don't know if this is just
shared with Mirja and me or if we could make it available to the IAB and IESG.
The Secretariat made it and it's all the things that need to happen for this
transition to occur at a detailed level.

Mirja: If there is interest, we can share it, but I'm not sure everyone is
interested in these details.

Lars: And we will do a joint call between the IESG and IAB to discuss the RSWG
chairs, because we'll basically be fishing from the same pool and having two
different calls serves no purpose. But then each body picks their candidate and
we kind of need to agree not to pick the same candidate. So there will be some
coordination required.

Mirja: Cindy is preparing the call for us, thank you for that. And as soon as
we have candidates we want to have some interviews so we can think about if we
want to create a joint interview team.

Lars: I think that would make sense.

Mirja: But the plan is to get the call out very soon and leave it open over the
IETF meeting and then this can follow after the IETF meeting.

Lars: And people should already rack their brains for  candidates you might
want to wrangle virtually or in person in Vienna.

6. Management issues

6.1 [IANA #1226140] Designated experts for RFC 9180 (Hybrid Public Key
Encryption) (hpke) (IANA)

Amy: We don't have a convenient AD to find designated experts for this registry.

Roman: I'm happy to track this down.

Amy: Great! Thank you. You might want to reach out to the IRTF. We'll add this
as an action item for Roman.

6.2 Telechat Dates Between IETF 113 and IETF 114 (Secretariat)

Amy: We looked at the calendar with the retreat week which gives us two
possible proposals; the first has a formal telechat on Ascension Day which I
know is a European holiday. That's the week after your retreat week. The first
proposal has a formal telechat on that day and the second one has an informal.

Lars: I will miss the Ascension telechat day because I will be on vacation that
day. It would be slightly better for me if it wasn't a formal one.

Roman: If we're leaning towards proposal 2, I'm fine with that, but if we do
back to back formals [before the retreat] we really need to restrict the page
count, because back to back formals plus the retreat practically means three
weeks of only IETF work, no day job.

Lars: Should we do that? Back to back formals and limit the pages?

Amy: You can limit the page count for any telechat. If you think the back to
backs plus the retreat week is onerous you can have a 200 page limit for both
of those telechats to relieve that a little bit, but it's up to you. I don't
know if that negates the reason to have back to back telechats.

Martin D: Would it be crazy to have a telechat as part of retreat week?

Lars: Yes, that would be crazy.

Roman: We're locked up doing the retreat that week so we wouldn't have time to
read the documents.

Lars: Let's do option 2 and limit the page count [for the back to back]. I
don't think we need to choose the limit now but we should remember to do that.

7. Any Other Business (WG News, New Proposals, etc.)

Éric V: Very quick one. I'm pleased that Juan Carlos Zúñiga joined Cisco and he
is the INTAREA and MADINAS chair. So for some document shepherding, if it's a
Cisco author, we'll need to have the other chair be a shepherd or someone else.
That's all.

John: What was the procedure for announcing changes in affiliation? I did it
once before and I can't remember.

Amy: You can let us know by sending an email to support and we can make any
changes you need, and you may need to update your conflict of interest
declaration just after the March meeting.

Lars: A few small things. First is that the LLC is talking about joining the
retreat joint meeting remotely, since they're not going to travel for it, and
we're not going to have an LLC-only session [during that retreat week]. That
means we can do a variant of Martin D's proposal and use Wednesday afternoon
for IESG and IAB which means people can travel home Friday afternoon. So I'm
going to send a message on that but that means we can compress the retreat
slightly.

Mirja: That's fine for me but in your original proposal you had a whole day for
the joint LLC meetings. I believe half a day is enough but we should probably
confirm what topics we have and how much time we actually need.

Lars: At the moment we have Tuesday for IESG only, we had the Wednesday morning
for IESG + IAB + LLC joint, we had the Wednesday afternoon for only the LLC.

Mirja: What I'm saying is you had a proposal which actually covered five days
initially, where it was a full day for the joint with LLC and which we cut down
to half a day.

Lars: Right, and we made it for everyone. That stands, the LLC people do want
to join for some sessions, but it's not clear whether we need a full day for
IESG and IAB or whether we can take some time away from that and have LLC
people join. I don't actually think there's a reason to keep the LLC out of the
IESG and IAB meeting.

Mirja: I'm just asking if half a day for a joint meeting with the LLC is enough.

Lars: I think so; that's what we currently have.

Mirja: But we only have this because we tried to squeeze everything together.
For all the meetings, we don't have topics yet.

Lars: I think this is going to be enough. There's not so much overlap with the
IESG, IAB and LLC that we need more. The LLC will then probably do a physical
retreat of some sort separately some other time.  The Secretariat is looking at
options in the Bay Area and Google is looking into whether they can host us at
various campuses. Cullen suggested a place in San Francisco that looks nice and
Alexa is looking into it. Most people said on the doodle whether they're coming
in person or not so I think we have enough information to get a hotel block.

Warren: I don't have a useful update yet but we have somebody who's organized
stuff in the past helping out now and I've added Martin and David to the thread
to help get stuff more organized. IT seems relatively likely Google could still
do it but I promised to have an update yesterday and I don't have one.

Lars: That's great. Thank you for trying. I didn't mean to push anything.

Warren: Not at all, if you hadn't mentioned it I would have lost track.

Martin D: David and I are proceeding with the assumption that people prefer to
be in the city rather than down in the valley, but if that's an incorrect
assumption, it would be time to say so.

Warren: Google has a lot more space in the Mountain View area, but it's not as
convenient for many things.

Martin D: But the SFO office has two conference rooms so I'm sure we could
accommodate. Hearing nothing, I think we'll proceed with that preference and
what happens is what happens, but that's our first choice.

Lars: Retreats have worked well when people didn't need to drive around in cars
and San Francisco would allow us that. San Jose or something people would be
spread out more and going out to dinner and stuff would be more difficult. I
was at WTSA this week on a panel and I met a bunch of ITU people. It was
fascinating because of the Ukraine conflict, even at the ITU which is supposed
to be a technical organization, people walked out and there were motions
against basically any Russian that was proposed for any leadership position. It
was a much more interesting session than I expected it to be. That said, you've
seen RIPE has put out a statement and Andrew has put out a blog post for ISOC
about this and we've asked Greg to coordinate with the other comms people,
especially ISOC but also ICANN and so on. We're also trying to set up a meeting
at the leadership level which would include Mirja and me and various other
people to see if there's a joint statement we would want to make or at least
have ready. There's some secondary question here which is sanctions against
Russia; at the moment we believe that  because all our documents are public and
there are no discussions happening in closed fora that the sanctions don't mean
we need to change our processes. That said, we might need to change what we
need to do with our Russian participants so that might mean we need to
coordinate more broadly. This is just a heads up that this is the current
state, we've heard rumors that things might change, but I have no timeline and
no details. I think that was all I had.

Francesca: I have one thing. Next telechat is the last telechat for people
stepping down and the agenda will be set this evening, is that right?

Amy: The agenda will be set tomorrow; the tool rolls over at midnight Pacific.
You'll get the preliminary package tomorrow.

Francesca: Great, so there's still a little bit of time to get more stuff on
there. I'm preparing an email to send to the ART chairs and I was wondering if
everybody else has sent information or guidelines or anything for this hybrid
meeting. Just to make sure I don't forget anything.

Warren: Rob and I sent stuff yesterday. I'll forward our email to the IESG in
case it has useful stuff in it; feel free to crib from it.

Francesca: Thank you, Warren. I just wanted to see if people think there's
anything we need to tell the chairs more than whatever Greg and Meetecho are
organizing.

Warren: A fair bit was just reminding people that it's a hybrid meeting and a
lot of participants are out of practice dealing with other people. We have some
entertaining personalities that might be more entertaining than usual; please
make sure that you're synced up with your co-chairs so you know who's doing
what.

Francesca: Martin, I remember you were telling your chairs that if they're both
going to be remote you can sit at the table and do the in person. I wanted to
encourage my chairs to find someone to do that, but I think I will do the same
otherwise.

Warren: What I've suggested is to please find a participant and see if they'll
do it. Otherwise, see if you can find a different chair in the area who might
be willing. Otherwise the ADs can sit there.

Martin D: I have the luxury of not having too many WGs so it's not too onerous
for me. But knowing who's actually going to be there is so chancy that if I
just show up and draft somebody, that's my first choice.

Roman: Excuse my ignorance on the technology evolution of Meetecho, but I know
last meeting when we [shared] a session with SAAG and SECDISPATCH, [in order to
delegate some chair management things like queue management, we had to add the
chairs of one WG temporarily as chairs of the other WG so they would have chair
privileges in Meetecho.] If we're delegating other people to help, are they
going to be able to [do things like manage the queue?]

Greg: I'm happy to give a general sense of how we expect things to work in the
room. For Meetecho purposes, the roles for any particular session are driven
from the Datatracker. I can ask if it's possible for them to manually override
that.

Martin D: I think the exact permission we need is the ability to add other
people to the queue in case the app goes sideways. An ordinary participant can
be logged in to Meetecho as themselves at the head table and plug that into the
screen. If the app is working great, then we're done, but if the app isn't…

Francesca: What we really want is a temporary chair role. What we've been doing
[for interims] is to assign a temporary chair and announce that. I think that's
what Ben and Roman did for SAAG also, add chairs and remove them afterward.

Martin D: Does that have zero latency? If I go to the Datatracker and add
someone as chair of something does he instantly have the Meetecho access?

Francesca: I think so, because I've added a chair the same day as an interim,
and the new chair had all the buttons. It would be better from a presentation
point of view if there was a presentation role that has all the rights a chair
does but it's clearly temporary.

Greg: I think I have the requirement, which is to be able for ADs to assign
chair roles in Meetecho to people who are not officially listed in Datatracker
at the moment. Would that suffice? Not ADs, sorry, ADs need to be able to
designate people who can have chair roles and Meetecho can do the button
pushing to make that happen.

Martin D: There are a couple ways to solve this problem. Chairs can add people
to queues, right? That's a power they have today?

Greg: I don't know if chairs can add people to queues. I think people need to
nominate themselves to queues.

John: It would be great if we have tooling to let the chair insert people into
the queue but chairs can already add people to queues because we call on
people. The queue is there as a tool to be used for managing the mic line. This
can be solved at the human layer also.

Martin D: In my model of this, if both chairs are remote, they have no
visibility over the mic line.

Greg: Sorry, that's not true. There will be a camera in the room that shows a
persistent mic line, so chairs and everyone else in a session will be able to
see who is standing at the mic.

Martin D: So what I said is not literally true but strikes me as difficult to
manage.

Greg: I agree that people in person will need to be reminded in many ways that
the queue is being kept notionally in Meetecho and there will be various
reminders in the room, in the training, and in the materials that to enter the
queue officially they should indicate that via the Meetecho app that's being
developed for the participants.

Martin D: So in a perfect world, everyone in person is in the app and there's a
single source of truth, which is the Meetecho queue, and if people forget to
remove themselves the chairs can manage that whether they're remote or in
person. The point of the designated chair is to put something up on the screen,
which currently anyone can do from Meetecho if I'm not mistaken.

Ben: You have to ask permission to share your screen.

Martin D: To log into Meetecho and then share your laptop screen with the
projector.

Greg: That's true with the chair's permission you can share your screen. Based
on feedback from the last meeting it seems like things work much better if
people upload slides to the Datatracker.

 Ben: I think he means the front of the room, physically walking up to the
 front of the room and plugging in your computer to the projector.

Martin D: Any Meetecho user can log into Meetecho and have what any user sees
as the presentation, and then someone can plug that into the projector so
everyone in the room can see it without being logged in to Meetecho. That's
what I'm trying to say, it's nothing to do with sharing the screen into
Meetecho, it's sharing from Meetecho into the projector.

Warren: The Meetecho laptop is plugged in to the projector and you used to be
able to plug Meetecho into your laptop and it would ingest that video, I do not
believe that's something that will still work. All presentations have to be
shared through Meetecho and there's no longer a video stream to ingest it.

Martin D: In my mental model of this it's exactly like a remote meeting in
first principles, except that there are a bunch of people in the room who
aren't logged into Meetecho and instead there's one person who takes their
laptop, logged in via Meetecho, and plugs that into the projector so we can lal
watch it together instead of having everyone on their own screen, for multiple
reasons. So that's the minimum functionality of this person sitting at the
front.

Amy: But we don't need that person to plug their laptop into anything because
all of that is being done by Meetecho at this meeting. They're on site.

Warren: The only thing the person at the front needs to do is pay attention in
the room and say hey you, stop poking the guy next to you. Everything else can
operate exactly like remote. There's no need for a person to do anything. The
projection from the Meetecho laptop shows on the projector, nobody needs to
touch anything. It should be exactly the same as remote, just not everybody is
logged into their own laptops, they're looking at one big screen.

Martin D: So the difference between this and a remote meeting are number one
that there's an authority figure, number 2 people in the room use the app
instead of the full Meetecho and can join the queue via the app. That's the
desired use case. This whole conversation about an additional requirement is in
the event the Meetecho app has problems, because it's new and people lose their
phones or whatever. What is the fallback to get people who are in person into
the queue? And whether we could do that at the human layer or if we have some
sort of tooling where the person at the front who's babysitting can also just
take Fred and put him in the queue. I think that would be nice but maybe we can
survive without it.

Amy: At that point the functionality of the person "babysitting" is that
someone would alert them they can't get into the queue, they could add
themselves to the queue [as proxy], and the person can go to the microphone.

Warren: What I would do if I were a random participant and my phone battery
died I'd ask the person next to me to add themselves to the queue for me. We
can be grownups.

Éric V: We are grownups and participants are grownups and I don't have a real
problem there.

Martin D: I think this is all perfectly agreeable and I'm glad we seem to be
converging on a consistent way to do this so each WG doesn't have a different
norm for this. That's good. IT sounds like in the end we are not creating a new
requirement for Greg to chase down, because we're going to handle this on the
human layer.

Éric V: It may be worth it to get the Meetecho people in the next telechat so
we are all on the same page.

Greg: I'd be happy to talk to the Meetecho folks to see about their
availability. I'm happy to set something up for next week or at the telechat if
you want.

Rob: My suggestion is, should we try and arrange a meeting on Tuesday morning
so we can resolve any issues that came up on Monday, and if nothing needs to be
discussed we can just cancel it Monday afternoon. Does anyone object to that?

Martin D: It might be better to do it Monday evening so MEetecho has a night to
respond. If at 9 am we tell them something's broken, it's not going to work by
10. I don't know if they'd work overnight but at least in theory they could fix
the problem.

Lars: I like that idea but there is some stuff we need to work around on Monday
evening.

Greg: There will be Meetecho folks on site and the LLC / Secretariat / NOC team
usually has daily recaps every day after sessions to have a check in, and we
could do this as part of the check in on Monday evening after sessions.

Warren: Meetecho people are also friendly and sane and we can drop them notes
in the chat as well. Not big changes but just feedback throughout the day.

Martin D: There's a 90% chance that things went okay, we just want to tweak
something, and we're done. But if there's an emergency we should talk about it
and skip the other events.

Lars: I don't think everyone needs to be in this meeting, a subset is probably
enough.

Warren: It doesn't seem like a bad idea to have something planned and
scheduled, and if nobody shows up, we can cancel it.

Lars: I like the idea from Greg that we open up that Monday post-session huddle
with the admin people for those IESG members who want to join here. That's
where we'd discuss it operationally anyway. So we'll just schedule basically
the same meeting on the IESG calendar.

Rob: The other point I would want to raise is there is an issue in terms of
people trying to track the chat messages happening and in person conversations
and trying to bring them together? In the past we've had jabber scribes, should
we be trying to do something similar here to make sure that chat conversations'
key points get pulled into the in room discussion?

Francesca: Since I started coming to IETF meetings the conversations in Jabber
have changed a lot. Now that we have been doing everything remotely there are
two sets of conversations, one in the room and one on Jabber. I agree it's hard
to track both at the same time. I don't expect my chairs to do that, and I
don't expect the jabber scribe to summarize what's going on in the chat. It's
usually just to report comments that people want brought to the mic. That's
also how it was used in person. What I try to do is remind everybody to please
bring any substantial comments to the mic. To be really practical, I don't see
how we can summarize those conversations and keep track of what is going on in
the room. Sometimes my chairs split, one is focusing on the conversation in the
room and the other is reading the chat and trying to bring up the consensus
they read in the chat. It's really hard. The best I could come with is to
remind everyone both in the chat and in the room that substantial comments
should go to the mic.

Rob: I wasn't thinking about how to summarize it but more about trying to
remind people on the chat they need to bring conversations to the mic.

Francesca: I will bring this to my chairs as well so thanks for the reminder.