Minutes interim-2024-iesg-07: Mon 16:00
minutes-interim-2024-iesg-07-202401221600-00

IETF 119 BOF Coordination Call Minutes
2024-01-22

Reported by: Liz Flynn, IETF Secretariat

Additional reference materials available at the datatracker
(https://datatracker.ietf.org/doc/BOF-requests)

Present:

Matthew Bocci (incoming IAB)
Roman Danyliw
Dhruv Dhody
Martin Duke
Lars Eggert
Liz Flynn
Jim Guichard
Cullen Jennings
Mahesh Jethanandani
Erik Kline
Mallory Knodel
Suresh Krishnan
Murray Kucherawy
Mirja Kuehlewind
Warren Kumari
Cindy Morgan
Francesca Palombini
Tommy Pauly
Alvaro Retana
Zaheduzzaman Sarker
David Schinazi
John Scudder
Orie Steele (incoming IESG)
Éric Vyncke
Robert Wilton
Paul Wouters
Qin Wu
Jiankang Yao

Regrets:

Andrew Alston
Wes Hardaker
Colin Perkins
Christopher Wood
Gunter van de Velde

Liz: For those of you who are new to this process, it's pretty straightforward.
We'll go down the list of BOF proposals to decide about each one. The three
choices are approved, rejected, or provisionally approved and then people have
two more weeks to give more detail or whatever else needs more work before
approval. Let's get started with the first one.

1. SRV6 Operations (SRv6OPS)- OPS Area
Provisionally approved -- more work needed on BOF proposal

Final decision: Approved

Warren: I personally think we should approve this. There is some stuff where
they can fill in more detail, but they did send me an email two or three days
before the cutoff asking if they could do this, so props to them for at least
being polite. I think many folks know I'm not really a big SRV6 fan/proponent,
but it does seem that some set of companies are or claim to be deploying it.
There was a side meeting at the previous IETF I wasn't able to get to but it
sounds like there were a number of people there who showed interest. The
slides, etc are posted online. I had a look and it is unclear to me how much
this is simply SRV6 people trying to show how much wonderful stuff they're
doing and how much people care, but I figure the right way to do this is have
an actual meeting where people show up for a discussion. Figure out how many
people are actually interested, if there's a significant amount of work, etc.

Éric V: Not only vendors, but service providers as well.

Warren: A bunch of the proponents are China Mobile, Bell, etc, who all say they
are doing it. I am not a fan and I'm concerned that there will be either much
drama or just people walking around patting each other on the back saying how
wonderful everything is. I don't really think it's appropriate as WG forming
but they did have a very active side meeting so it makes sense for them to at
least try. if there doesn't seem to be good support there's a legit reason to
say this doesn't work.

Alvaro: I agree we need to give them a chance. I'm the SPRING chair also and
one concern is there's some overlap with this and SPRING. For example security
practices are in the charter text and we're working on sec cons. we need to
make sure if this does go forward, that the charters are synchronized and we're
not working on the same things.

Warren: One thing I think will be really important is that this group should
coordinate with SPRING and this should really just be operations stuff. I think
this will be a constant issue. It would be useful for the SPRING WG to review
the charter and make sure there aren't toes being stepped on. I don't want this
to just be where people bring stuff because they couldn't get traction in
SPRING.

Alvaro: One interesting thing in general with operational groups is they don't
necessarily do protocol work. In this case, SPRING doesn't really do protocol
work either. So if there is protocol work to be done, there's something there
that needs to happen.

Martin: is this one of those WGs that exists to chat about issues rather than
have specific protocols? Or is this a more conventional publish standard RFCs
WG?

Warren: That's a very interesting question. I'd hope the plan is that this is
where people discuss issues they had when trying to use and deploy SRV6 in
their networks and where the sharp corners are. Basically what SIDROPS was
supposed to be. I don't think it's a discussion group like MOPS, I think it's
more like here's what went wrong in SRV6 and here are things to keep in mind if
you do it. I don't know if there's anyone on the call who was at their side
meeting that might be able to provide some background. This is basically side
meeting v2.

Dhruv: I was at the side meeting. There were presentations from different
operators going over what they've done so far, what's been working, what they
are planning to do, things like that.

Warren: What are your views on this BOF?

Dhruv: My personal opinion would be we should have a BOF. One of the things to
figure out is whether they would have enough things to talk about. We had a
very good initial one but is it going to be a recap of the same or bring in new
discussion as well. We already have V6OPS and SPRING, you could also argue that
this could also be discussed in other WGs. The key is proving that having a
focused group on SRV6 is needed and that's what I would be looking for. I think
you should get them an email list pretty soon so they can start discussing the
charter soon.

Warren: That's a good idea. Hopefully we can add you to the conflict list, if
you're okay with that.

Mirja: Dhruv, do you want to be the IAB shepherd for this?

Dhruv: Yeah, I can do that.

John: It seems reasonable to give them a meeting and let them demonstrate
they've got enough juice for a WG. Hopefully they'll dial in their BOF
description a little better. In particular, the third paragraph; the BOF can
provide input to various groups, etc. I think that should all be removed with
prejudice. If the BOF is WG forming the BOF should focus on forming a WG, not
doing all that other stuff in paragraph 3.

Warren: I thought I liked paragraph 3 because it made it clear that it doesn't
do the work.

John: If the WG could do that, that's in a proposed charter for a WG. That's
not the work item for the BOF.

Warren: Okay. i understood it differently but that's definitely not clear.

Zahed: I think this BOF makes sense to do. I'm not sure how much SRV6 work is
going on and how much they will have to talk about. Maybe that can be clarified
in the BOF. I also had this idea what exactly they're going to do, discuss or
protocol, but you answered that already. This could be good to watch but I'm
not sure how effective they could be.

Mirja: I'm still trying to understand why it's not possible to have the
discussion of this work in any of the other existing WGs.

Warren: I think the other WGs are all much more for designing protocol whereas
this is supposed to be when you try to use the protocol. Most of it wouldn't
work in V6OPS because even though SRV6 has v6 in the name, it's significantly
different to just v6.

Mirja: It depends a little bit on what V6OPS and SPRING are currently doing and
how much work they are expecting. Maybe if it's one guidance document you don't
need a new WG, but that's not very clear at the moment. The list of things is
very broad and it's not clear they're all needed. Maybe That's a good question
for the BOF to figure out if there's a need for a WG, but then it shouldn't be
WG forming.

Alvaro: I said before that one thing we need to do is make sure the charters
are in sync. We the SPRING chairs started looking at the current charter
because we think we need to update it. Just so you know that, there's another
option to include something operational in there if the ADs want to.

Warren: Clearly i'm not the SPRING AD but i'd be more than happy if the outcome
from this was SPRING should do more operations stuff. That would be perfectly
fine with me.

Alvaro: Then maybe it's time to do SPRING-OPS. But that's a different story.

Warren: Sure. But what I don't want is for this to be SPRING v2. There seems to
be a lot of drama around SR stuff and I'd prefer to not exponentially increase
the drama. If it's people in spring discussing how the protocol didn't really
work when they wanted it that's fine.

Rob: I like an operator focus coming to the IETF. I think we should work out
the best way to do that. I'm trying to create NMOP which is trying to do
similar things too. It's good to encourage operators to come. These are quite
new proponents, not necessarily that experienced with the IETF process and
might need some help. I'm worried that if this pattern continues we could end
up with a lot of ops WGs so that's something to keep in mind. I have some
questions about if this would be short lived or long lived and what does
success look like? I had a quick look at the charter and it looks rough. I
think we should hold the BOF but there are quite a lot of questions that need
to be worked out.

Warren: If they have the BOF and it ends up with there's not enough work to do,
or maybe for a very short WG, that would be fine.

Rob: I did go to the side meeting and that was very well attended. There were a
lot of people who were interested.

Suresh: I agree with a lot of the things Rob said. Maybe if there are just a
few small things they could go somewhere else. I'm thinking there are some gaps
in here, especially on the OAM side, and people could come up with things that
haven't been addressed. I also think the charter is pretty wide and requires
help. I'm also willing to help out if needed.

Jim: I guess I should say something, being the AD for SPRING. I do have some
concerns about the BOF in the sense that they really need to explain why this
work can't be done in SPRING. I've asked the SPRING chairs to recharter. What
I'd like to see as an outcome from the BOF is a list of things they think need
to be done and why those cannot be done in existing WGs like SPRING. My fear is
having to jump between SPRING and this potential new WG to figure out what's
going on and I don't want any issues between the two. I'd like to approve the
BOF in the sense of coming up with a list of work items, although I don't think
it's ready to be a WG forming BOF at this point.

Warren: As SPRING AD, can we add you to the conflict list and have you show up?
I think it would be really useful for us to both be able to stand up and say
something.

Jim: I'm happy to do that but I may not be in Brisbane because I'm still
waiting for my passport to come back.

Warren: I like the idea of it being listed as WG forming even if they can't
form a WG. If we decide this is not a great outcome, it doesn't just result in
them coming back for a second bite at the apple with WG forming listed the next
time.

Jim: That's fine. I'll work with the SPRING chairs because we should all take a
close look at this.

Éric V: We should have a really good chair for this. And V6OPS, 6MAN, and
SPRING should be added to the conflict list.

Liz: Thanks for leading in to what I was going to say; there are no conflicts
listed here, so Warren, if you could work with them to make sure they build out
a good conflict list that would be great.

Mirja: Is this approved or provisionally approved?

Warren: I think there's enough support to approve it but we should mark it as
provisional because there are some more things they need to do.

2. DELEG Capabilities - OPS Area
Provisionally approved -- more work needed on BOF proposal

Final decision: Approved

Warren: DELEG is a proposal that was discussed during the last hackathon. The
people working on it made a substantial amount of progress and there seems to
be substantial interest. It's trying to modernize some of the historical pain
points around DNS and make things newer, better, shinier, etc. There was a fair
bit of discussion in the hackathon. There are 20+ people working on a document
in github and we keep trying to push them to publish it as a draft for people
to look at. I will push again and say you really need the document published so
people can review it. But there are a lot of people who are supportive and
interested. Some background, most of the people are in DNSOP which is going to
be having an interim meeting to discuss this. But I'm concerned this needs a
lot more visibility throughout the IETF so I think it's really useful if they
have a BOF. That's all a little messy. There's going to be a DNSOP interim but
it's unclear if the work should be done in DNSOP or if it should be spun up in
another WG.

Mirja: Can you explain the use case?

Warren: Currently, when you're resolving a name, you walk from the parent down
to the child. The information at the parent is just, this is where the child
is. They would like to have more information at the parent about the child name
service. A classic example is if the authoritative servers support DOH, there's
no way to announce that at the parent so the child has to do some probing.
Instead of having all the information in the child, they'd like to be able to
have stuff like nameservers and they're reachable over these protocols, etc. I
had a long chat with John Klensin about this recently. DNS is a very old
protocol at this point and if we were to have designed it now it would be done
in a cleaner way. Although this is just talking about the delegation record,
one of the potential outcomes is people starting to clean up some of the uglier
rough edges around DNS. There are a lot of core IETF people interested.

Cullen: Everything you say here sounds great and I'm sure it's correct. But
there's no problem statement, no charter, no draft, no mailing list. All those
experienced IETF people need to get their shit together before this gets
approved. There's nothing here to approve. I'm fine with provisionally
approving it because people who are involved believe this is going somewhere,
but they need to get all that together before the deadline to approve it and I
believe they could get that stuff all together in an afternoon.

Warren: I fully agree.

Paul: I agree it's a bit sloppy but I think it's important. If this BOF doesn't
go forward the work will all go to DNSOP, which I think isn't good.

Cullen: I totally see that, but this is not ready. That's why we have two
deadlines.

Warren: It was rushed and last minute. Clearly it needs a lot more work and I'm
more than fine to say there's no way to approve this unless they make it clean
and tidy.

Mirja: You don't have to answer this now but it's not clear to me why you and
Paul said this is a big thing but to me that needs to be clarified a bit.

Warren: A lot of people want to work on this. It's unclear just how big a lift
it is but there's also if the work gets done, would it be better in DNSOP or a
different WG. If a different WG, what area? There have been some hits and
misses with splitting work up into things like ADD or DPRIVE or DOH. Assuming
the idea is reasonable, where does the work get done?

Mirja: Isn't that dependent on how big the work is? It sounds like they just
want to add one more piece to something which feel small. I understand it
wasn't part of the initial design of the protocol but what they're proposing
sounds very small.

Warren: I agree with you. There are some strong views as to whether it's
acceptable for ops groups to do protocol work, and this could count. Also DNSOP
is fairly overloaded so maybe splitting it up makes sense. There's a concert
that if you split work up you don't get the required people.

Mirja: It would be a different BOF if they just said we need to do some
protocol maintenance work and we need a WG to do that.

Warren: I think the main takeaway is there's not enough here for us to make an
educated decision on and people need to get this updated. So provisionally
approved if they get a bunch more work done.

Mirja: Are the right people involved already or do we need to assign an IAB
shepherd?

Warren: Wes might be good but I think he's on a plane right now.

Mirja: We can still maybe assign him.

Martin: This seems adjacent to ADD, I get that it's slightly different, but are
these going to be completely different mechanisms from what ADD is doing or
could it just be follow on work for that?

Warren: I think it's a more fundamental thing but ADD should clearly be listed
as a major conflict.

Éric V: ADD is more for bottom up and this is more top down. But it's basically
related. Should we get another DNS protocol development WG sometime? At some
point we should think about that.

Lars: That's a broader discussion. I heard Warren say he wants to give the
proponents some homework and we're going to see if they do it. I agree this
does seem sparse.

Warren: Yes, that all sounds good.

Lars: I think they need to significantly do some homework here. Let's see how
much work they can get done before we can approve it.

Warren: Okay. So possibly Wes as shepherd, I should make a mailing list, and
we'd also like ADD to be a conflict. I think it would be helpful if Paul and
Erik and others can also show up. Anything else?

Lars: Significantly expand the description of what they're doing.

3. SCONE-PROTOCL the topic formerly known as SADCDN (SCONEPRO) - WIT Area
Approved - double check conflict list and reorder information on the BOF
request form

Final decision: Approved

Zahed: Except for the name, I think there's been some discussion the last
couple of IETF meetings. The idea here is that people are having video
communications, you need to adapt. Usually you try to understand the network,
look into a different kind of implicit feedback, and try to understand the
shape of the network. The proponents claim that has been really complex and
tough and it would be really beneficial for the service to maintain the right
level of quality of experience of getting network information. So that's
basically the use case they're focusing on. A network and application talking
with each other. This is where you go into already existing solutions like DHCP
in other SDOs.

Lars: This needs to be in the description. Something needs to go in the session
description.

Zahed: They have a charter proposal.

Dhruv: They have a lot of information at the bottom of the page but for some
reason they didn't put it in the description.

Lars: Oh, I was just looking at the screen here. I withdraw my comment.

Éric V: They put it in the wrong place in the form.

Zahed: So I told them to come up with a charter if they wanted a WG forming
BOF, so they did. They're also still working on it. Any comments?

Cullen: I'll just add that I also think we need to clean up the conflicts here
a little bit. MOQ should definitely be here if they're doing the media they
plan to transport over this.

Roman: This is out of scope for MOQ?

Cullen: This is very much out of scope for MOQ and I think it would be the
wrong place, but it's the same people and the same applications.

Mirja: MOQ is here as a conflict but MASQUE is missing, and MASQUE might be
part of the solution.

Zahed: We are getting into the solutions here.

Cullen: This invokes a lot of stuff going back to the plus type work as well
and I think they have an idea of how to avoid those problems.

Zahed: Plus was to be more declarative, but this is a more explicit
communication. It's much more scoped.

Erik K: I see Spencer in the list of proponents and he's also the author of a
draft in PANRG which is the bestiary of all the times network information
signaling has gone wrong. These proponents seem like there is a path forward?
Conceptually it seems related to what PANRG is doing.

Zahed: My initial understanding of what I discussed with Spencer is that path
aware networking is trying to pick up these issues and SADCDN is how to solve
it. They have some constraints like how they think it could be solved. That is
making it a bit more scoped than what's happening in PANRG. That's one thing
that needs to be clarified in the BOF, if this is something that is scoped to
actually produce something. The outcome of this BOF would be to see if there
are enough people interested.

Erik K: It may be that a sufficiently scoped focus allows for some solution to
emerge. Thank you.

Tommy: I appreciate the narrow scope here. It seems to be that in the
description of what they say is on path, they're only describing stuff between
the network and the client. I know in early discussions there was talk of being
on path between the network and the content providers. To your understanding is
this BOF scoping down to just communication between the network and the client,
and if so, should that be more explicitly listed as one of the properties
they're looking at?

Zahed: I think the idea there is something between the client and server.
That's the general idea. This isn't really explained well so they can clarify,
but that's my initial understanding.

Murray: It looks like Meta is going to want to participate in this rather than
run it, so you may have to look elsewhere for chairs.

Zahed: If anyone has any good suggestions, let me know. I need one chair that
is technically sound and another that does floor control really well. I'm
looking for those qualities.

Lars: Check if Brian Trammell is there. He can do all the things you mentioned.

Mirja: He won't be in Brisbane.

Murray: Will this be in WIT area?

Zahed: I agreed to help them and my intention was to put it in WIT.

Suresh: Following on what Erik was saying, the current description doesn't say
how dynamic this is going to be. That's something you should get a little bit
tighter; that's probably going to determine whether it's going to be a failed
attempt or not.

Zahed: That's something I'll be looking into. My feedback to the proponents has
been that this work needs to be really scoped well. So do we approve this or do
you need more information?

Murray: I'd say yes. Get the stuff filled in properly rather than down at the
bottom and some stuff around conflicts to resolve, but it seems okay to me.

Zahed: Great, then I think I have what I need.

4. Workload Identity in Multi System Environments (WIMSE) - ART Area
Approved; WG chartering will proceed in parallel and session will take place as
either a BOF or a WG.

Final decision: Approved

Liz: This would be a second BOF for WIMSE.

Murray: The first one was non-wg-forming, this one is. We have chairs for both
the BOF and for the WG when it's ready. One of the other things that was
holding this up previously was a discussion about whether it should be ART or
SEC; rather than keep them waiting while we hem and haw I decided it should be
in ART with a SEC advisor, so Paul has agreed to do that.

Francesca: I know they were working on the charter as well and they weren't
sure about putting in this request in case they managed to get the charter
through.

Murray: They wanted to start the charter process directly; this would morph
into an actual WG meeting if it goes through.

Mirja: This looks really good to me. They say they don't want to do protocol
work but they have a point in the charter talking about workload token
exchange, which sounds like a protocol. Maybe That's something to clarify.

Murray: Okay. I'll move it ahead, thanks.

5. NMOP Placeholder (NMOP) - OPS Area
Approved; WG chartering will proceed in parallel and session will take place as
either a BOF or a WG.

Rob: I'll update the charter this week. One significant comment was about
scoping down so I'm chasing the proponents. The idea is to get this chartered
before 119 and if we don't, then it will be a BOF. I'm not sure we need to
discuss it further today.

Liz: Reminder from me, make sure you get that conflict list filled out --
whether it goes ahead as a BOF or a WG, we'll need a conflict list.

6. Symmetric Key Exchange (SKEX) - SEC Area
Maybe; Paul and Roman are discussing with proponents.

Final Decision: Not Approved.

Liz: Roman, this is one of yours?

Roman: Mine in the sense that they put my name on it, which I discovered on
Friday when it appeared in the Datatracker.

Paul: I did exchange a few emails with them. My biggest concern is that this
seems to be creating a new cryptographic building block not using asymmetric
keys to authenticate things. It has some trust element with peer to peer
networking. They did add a paper link to the email discussion that describes it
a bit more. Fundamentally it's a new cryptographic building block and we
normally don't do that work in the IETF. Maybe the IRTF. so i'm not entirely
sure what we should do here.

Éric V: I was going to say that, is it IRTF or IETF? Without the BOF we cannot
say.

Paul: I think you can say it even without the BOF. IETF listens to CFRG for
advice on what algorithms to use and there is no algorithm yet, so it should
first make its way through the IRTF before putting it into IETF protocols.

Erik K: Does the IRTF have a BOF process?

Suresh: They have a proposed RG process, they could talk to Colin.

Cullen: I thought they were looking at existing cryptographic algorithms to
select one that avoided the IPR concerns and put them together into a protocol,
but I haven't been following this. Are you sure they want to develop a new one?
That's a surprise. But i could be confused.

Paul: I'll send the link in slack.

Roman: Paul, should we take a week to actually talk with them to see if we can
better route or focus this and use the two weeks to define the way ahead?

Paul: That sounds good.

Roman: I wouldn't want to use the words provisionally approved here. Is "maybe"
a status?

Mirja: Do you need an IAB shepherd?

Roman: Paul's nodding yes. I was going to say I'm not sure it's even mature
enough for that. I'll take help though.

Tommy: He's not on the call but I'll nominate Chris.

Roman: I think we're good on this one.

7. Detecting Unwanted Location Trackers (DULT) - SEC Area
WG Chartering in progress; this should move ahead and be a WG by 119

Roman: We've had two successful BOFs and we've refined a charter that seems
responsive to all the feedback we got. By process we can't really create a
third BOF; this is here for scheduling expediency as a placeholder if it turns
out this chartering process is successful so that it's not forgotten when we
build the agenda. We could not convene this BOF if we wanted to.

Mallory: Will there be a session then at the next IETF?

Roman: It depends on how the chartering process goes. We can't have a third
BOF. If we find consensus on the list we do have sufficient time to run through
review and charter the WG.

Mallory: I just wanted to make sure we didn't lose it if it's not a BOF or a WG.

Cullen: As a side comment, I worry about people not on IAB or IESG reading the
Datatracker and thinking these are real BOFs. We should make it really clear in
the writeup or the naming that they're placeholders.

Roman: That's completely fair. I can be clearer.

Mirja: In the long term I think we need to have a different element for this in
the DAtatracker.

8. Secure Patterns for Internet CrEdentials (SPICE) - SEC Area
WG chartering in progress; session will take place as either BOF or WG

Roman: This is a circumstance where I'm not sure how we will enter 119. There
is a charter under discussion, there is still iteration on what that should
look like. If we find consensus on the list we still do have time to run a
chartering process this could potentially be chartered. If not, we would
convene to discuss all that. So it would either be a WG-forming BOF or it may
be a WG session.

Mirja: How does this relate to PRIVACYPASS? It's not here anywhere but it seems
like the concept is similar.

Roman: As I understand it, this is largely building upon the existing CWT/JWT
registry. This is not trying to target any specific use case, although informed
by the collection of different use cases. This is about publishing a new
container framework guidance that gives better security properties that you
don't get with JWTs and CWTs and in a three party model, but it will be bound
to how things are happening with JWT and CWT. I've been led to believe that's
different than the much narrower use case PRIVACYPASS has.

Mirja: I don't know enough of the details but I'm asking because PRIVACYPASS
has this very tight use case and maybe they're the outlier because they don't
use anything in the rest of the infrastructure. But from an architecture point
of view it looks very similar.

Roman: It's my understanding that the way this is envisioned is this
"credential framework" is that you'd leverage all the engineering and all the
code points that already exist, then you'd add this guidance on frameworks to
get you the selective disclosure to work in a three party model. Then there's
more guidance on how you mix and match and patch that. There are many use cases
from digital driver's licenses to other wallet formats, you can mix and match
from other work and use the security properties. As I understand PRIVACYPASS,
it was developed in an earlier time with a very specific focus and was not
intended for a wide mix and match approach. There were some particular protocol
binding choices made. I can't unpack it more than that.

Mirja: Maybe another option is to take PRIVACYPASS as a basis and extend it and
make it more general.

Roman: I don't think the proponents would like that.

Tommy: Ultimately, they're similar where they end up. But they come from
different ecosystems. It's more that the way people are used to using them is
different. Do they have to be different, no, but they're going to be. The main
outcome is that it would be good to list that as a technology overlap. They
would end up being the two main things using blind signatures in thai way and
being able to have the people interested in those cryptographic protocols
should be able to attend both. There are some things in PRIVACYPASS currently
around key consistency with blind signature keys that are already intended to
be generic. Making sure they're deconflicted so people can go to both would be
useful.

Mirja: Maybe I'm picking at this too much but I feel like people in the space
keep reinventing the wheel instead of using what's already there, so we just
keep adding one more and one more and that won't resolve the confusion. That's
my high level view.

Roman: What's not mentioned here is the overlap with oauth, which had
significant discussion in the first BOF. I Think we have to wait for the
charter to see what's going to get refined here. For the question of go/no go,
i think there's enough information. There is ambiguity but that can get cleared
up in the BOF.

Cullen: Question about scope. It seems to me there's a group of people who want
and need this but mostly they don't need the trusted applications or the T
stuff. The people who are fans of the T stuff are trying very hard to get it to
be attached to something. I do wonder whether that needs to be in scope or
whether that could be added later.

Roman: I completely agree. In my AD review of the charter I told them exactly
that. We'll see how they respond. Okay, I hear approved? [Nods]. I think we're
good here.

9. ALLDISPATCH - GEN Area
Approved

Liz: I don't think we need a lot of discussion here, we just wanted to confirm
that we wanted three hours as the length.

Lars: Can we make it three?

Liz: Yes, sure.

Lars: Let's do that and we can always shorten it if we don't have enough topics.

Éric V: Do we plan to make a break in between?

Martin: They're 20 minute slots. The odds that someone is interested in every
single topic is small. You can give yourself your own break.

Francesca: Lars, will you be the responsible AD?

Lars: Yes, if it's in GEN. just because that's the default. I think we have
several responsible ADs for this one.

Tommy: As a purely practical question, when we're talking about things going to
this, should we tell people to send to the alldispatch list or are we still
expecting people to mail to secdispatch or dispatch and the people there will
redirect to alldispatch?

Lars: My understanding was that we would use the ALLDISPATCH list instead of
all the individual dispatch lists this time, because that's part of the
experiment. I don't know if we've instructed people to actually do that, which
we should.

Martin: We sent out a call for proposals to all the dispatch lists and I think
it was implied it would all be on the alldispatch list. If something comes into
one of the other dispatch lists I don't think the chairs are going to throw it
away.