Skip to main content

Narrative Minutes interim-2019-iesg-18 2019-09-05 14:00

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

Narrative minutes for the 2019-09-05 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
Michelle Cotton (ICANN) / IANA Liaison
Alissa Cooper (Cisco) / IETF Chair, General Area
Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Wes Hardaker (USC/ISI) / IAB Liaison
Ted Hardie (Google) / IAB Chair
Benjamin Kaduk (Akamai Technologies) / Security Area
Suresh Krishnan (Kaloom) / Internet Area
Mirja Kühlewind (Ericsson) / Transport Area
Warren Kumari (Google) / Operations and Management Area
Barry Leiba (Futurewei Technologies) / Applications and Real-Time Area
Alexey Melnikov / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Alvaro Retana (Futurewei Technologies) / Routing Area
Adam Roach (Mozilla) / Applications and Real-Time Area
Martin Vigoureux (Nokia) / Routing Area
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Magnus Westerlund (Ericsson) / Transport Area

Ignas Bagdonas (Equinix) /  Operations and Management Area
Deborah Brungard (AT&T) / Routing Area
Heather Flanagan / RFC Series Editor
Portia Wenze-Danley (ISOC) / Interim LLC Executive Director

Chris Box
Brian Campbell
Darren Dukes
Bob Hinden
Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to bash the agenda? I did get a late management item; any
other changes?

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the August 22 being
approved? Hearing none, so those are approved. Does anyone have an objection to
the narrative minutes of the August 22 meeting being approved? Hearing none, so
those are approved as well.

1.4 List of remaining action items from last telechat

     o Ignas Bagdonas to propose an additional question on YANG Model
       format validation for each of the styles of document write-ups.

Amy: Ignas is not here so we'll mark this in progress.

     o Roman Danyliw to draft text to be posted on about reporting
       protocol vulnerabilities via an email alias and possible procedures
       on how to assign triage resources.

Roman: That one is still in progress.

     o Martin Vigoureux to work with the IESG to create a list of possible
       IESG Tutorials and will prioritize them for scheduling on a series
       of Informal Telechats.

Amy: Martin is going to be late so we'll keep this in progress for him.

     o Eric Vyncke to write up draft text for the NomCom to help them
       understand the rules for the NomCom.

Amy: Eric is not with us today so we'll keep this in progress.

     o Roman Danyliw to shepherd the analytics discussion
       with the community.

Roman: We have time to talk about this later. Let's just keep this in progress.

     o Alexey Melnikov to find designated experts for RFC-ietf-core-object-
       security [IANA #1141664].

Amy: This is a management item today so we'll mark it provisionally done, and
same for the next item.

     o Alexey Melnikov to find designated experts for RFC 8554 [IANA #1142796].

     o Alexey Melnikov to find designated experts for RFC 8610 [IANA #1145107].

Alexey: This one is in progress; it probably will be done next time.

     o Ignas Bagdonas to find designated experts for RFC 7317 [IANA

Amy: Since Ignas is not here we will mark this in progress for him.

     o Adam Roach to collate the list of specific "hot topic" items from
       each Area that will be provided to document authors and post it on
       the wiki.

Adam: Leave this one in progress.

     o Barry Leiba to come up with a proposal for moving Last Call
       discussions to a separate mailing list.

Barry: The action is done, we just need to discuss today when to actually do it.

     o Suresh Krishnan to ask Heather F and Sandy G to introduce the
       Updates Tags Document (draft-kuehlewind-update-tag) to the RFC-
       Interest email list for discussion, and inform the community via the
       IETF discussion list with a pointer to RFC-Interest.

Suresh: This is done; we agreed on text last week but the mail itself hasn't
gone out. Heather agreed to send the mail and we agree on the text of it.  I
would say this is done.

     o Adam Roach to send a message to the tools team cc Roman as
       liaison about removing the required date associated with milestones
       on WG Charters.

Adam: Also in progress. Thanks.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-curdle-ssh-curves-11  - IETF stream
   Secure Shell (SSH) Key Exchange Method using Curve25519 and
   Curve448 (Proposed Standard)
   Token: Benjamin Kaduk

Amy: There are no Discusses in the tracker, so unless there is an objection now
this is approved.

Ben: It sounded like the authors were in the process of making a few changes.
Let's leave this as Point Raised and I can sync back with them to see whether a
Revised ID is actually needed.

 o draft-ietf-oauth-resource-indicators-05  - IETF stream
   Resource Indicators for OAuth 2.0 (Proposed Standard)
   Token: Roman Danyliw

Amy: There are no Discusses in the tracker, so unless there is an objection now
this is approved. Hearing no objections. I also don't have any notes in the
tracker; are there any needed?

Roman: Can you please mark it Revised ID Needed? I think there was a change or
two that still needed to be made. Thank you.

 o draft-ietf-mile-jsoniodef-10  - IETF stream
   JSON binding of IODEF (Proposed Standard)
   Token: Alexey Melnikov

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

Alexey: I don't think so. I'm waiting for answers from the authors. Suresh's
comment should be fairly simple to resolve and I think Ben's comments are quite
valid as well. So I think this will definitely need a revised ID.

 o draft-ietf-ippm-stamp-07  - IETF stream
   Simple Two-way Active Measurement Protocol (Proposed Standard)
   Token: Mirja Kuehlewind

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

Mirja: I don't really think we need to discuss them. Thank you everyone for
reviewing with such short notice. They're all valid points. I think the main
point here I just want to comment on is that this is really just a testing
protocol so there's no public web server or whatever; it's always in your
domain where the testing client and testing server know each other and are
configured and have to have the same version. The other intention was to make
this version as simple as possible so there's no version negotiation, or any
kind of negotiation mechanism in here. So the way to change anything is
actually to publish a different kind of protocol in a new RFC. That should be
clarified in the document. It should also be discussed, like how you change,
for example, the HMAC algorithm by basically defining a new version in a new
RFC that then both end points have to implement. I will talk to the authors and
maybe we can add a compatibility statement or address these points directly.

Amy: Okay, we'll go to IESG Evaluation, Revised ID Needed.

 o draft-ietf-oauth-jwt-introspection-response-07  - IETF stream
   JWT Response for OAuth Token Introspection (Proposed Standard)
   Token: Roman Danyliw

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

Roman: I don't think we need to; we're doing well on the mailing list. Can you
just mark it Revised ID Needed? Thanks.

 o draft-ietf-6man-segment-routing-header-22  - IETF stream
   IPv6 Segment Routing Header (SRH) (Proposed Standard)
   Token: Suresh Krishnan

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

Suresh: Some of this stuff has already started and the authors haven't had a
chance to respond. I had a chat with them, and Darren is on the call too in
case we need something. The idea is we'll make sure discusses are addressed.
Barry's point about the IANA consideration stuff is something we'd already
thought about. We'll come up with a response for that too. I don't think we
need to talk about this on the call but there have been some issues in the WG
regarding specifically the security pieces and the HMAC and the optional nature
of it and everything. We'll work through some text to make sure we come up with
something that's going to hold consensus as well. And for sure this is going to
require a Revised ID.

Amy: Okay, thank you. We'll put this in Revised ID Needed.

 o draft-ietf-iasa2-rfc7776bis-02  - IETF stream
   Update to the IETF Anti-Harassment Procedures for the Replacement
   of the IAOC with the IETF Administration LLC (Best Current Practice)
   Token: Alissa Cooper

Amy: I have a Discuss; do we need to discuss it today?

Ben: Alissa sent this an email this morning, right?

Alissa: I did.

Ben: Maybe I just haven't had enough caffeine but I'm still a little bit
confused. You said we were not asking for the live metadata to change, but we
were expecting it to change as a logical consequence? I'm not sure what you
meant by that.

Alissa: I think the point is that readers of this document together with 7776
should realize that the totality of them doesn't update 7437.

Ben: Sure. I agree with that. I'm finding the right button to clear [my

Alissa:  Thank you all for your patience with this.

Magnus: I would note that I think there are some points for us going forward
for discussion. I did add the topic for the retreat, around the general topic
of updates, refreshing documents, etc and the impact of some steering we try to
do. I think we need more discussion on that side.

Barry: Adam has started something with that and I think we should continue that
discussion. This is a separate one; had I been around when the WG was
chartered, I probably would have pushed back on the way the charter was
created. We need to restrict scope on changes but we need to be careful about
how that's done. That's a separate discussion I think we should also have.

Alissa: So Magnus, is there something beyond the discussion we've already had
around Adam's document?

Magnus: Have a look at the proposed topics; I have it there with three aspects
I think should be discussed. It's in the second retreat wiki page.

Amy: Okay, so I have that Ben has cleared his Discuss. With no Discusses left,
this is approved unless there are any other objections.

Alissa: This can go into Revised ID Needed.

 o draft-ietf-core-senml-etch-05 (Has RFC Editor Note)  - IETF stream
   FETCH & PATCH with Sensor Measurement Lists (SenML) (Proposed
   Token: Alexey Melnikov

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

Alexey: No, thank you everybody for finding various issues. I need a reply from
the editors, I believe.

Amy: Is this going to require a revised ID?

Alexey: Yes, most definitely.

 o draft-ietf-netmod-artwork-folding-09  - IETF stream
   Handling Long Lines in Inclusions in Internet-Drafts and RFCs (Best
   Current Practice)
   Token: Ignas Bagdonas

Amy: Ignas is not with us today. I do have a Discuss in the tracker. Ben, do
you have a feeling if this Discuss is going to require a Revised ID?

Ben: There are definitely some points that would require a Revised ID but I
think we should potentially have a discussion on the last point even though
Ignas is not here, because there are a few people that had balloted Abstain and
I wasn't sure if I wanted to ballot Abstain as well. I think we should probably
discuss the underlying issues.

Suresh: I was right on the border too, for abstain or no objection. I don't
think this should be in the IETF stream, like Alissa, Mirja and Alvaro said,
but I do think the work is useful.

Alvaro: I looked very hard to see if there was anything that kept us from
publishing it. Like if anything having to do with the RFC format had to be done
by the RFC Editor and IAB, but I couldn't find anything. So that's why I ended
up abstaining.

Ben: Just because there's nothing that says we can't do something doesn't mean
we need to think about if us doing that thing is the best way to get that thing
done. That's why I felt comfortable with Discuss. I also don't have a great
sense for what the nature of the previous conversations with Heather have been
about this, and if there would be any interest in trying to undertake a more
general work on folding or a code sample folding mechanisms or preferences to
apply to the series as a whole instead of just IETF stream. I also think many
of these concerns would go away if we did not try to publish this as an IETF
BCP and instead tried to publish it as an informational document. That would be
heavily relied upon by some of the Yang work, even though the Yang tree
diagrams have built in tooling to set the desired line length, because that
gets into the chartering question. This WG is basically focused on Yang and
this treatment we have in this proposed BCP document is applying to all code
samples and similar through the entire IETF, which is pretty clearly not just
Yang related.

Barry: My comment on their mailing list was that this deserves wider attention
and any document saying it's a Yang document is going to be ignored by a large
quantity of the IETF that this ends up affecting, and this should be on a wider
discussion forum.

Ben: That's basically my sentiment. People will say the IETF general discussion
list for last calls is a broader forum so by doing a last call it got the
requisite amount of review. But in some sense that seems like a polite fiction.

Adam: I wanted to weigh in quickly. There are two issues here: whether this
should have gone to netmod and a separate question of whether this should come
out of the IETF. I want to point out that RFC 2629 is an IESG stream document;
that's the xml format for creating RFCs and it's become used across all the
streams and is about to become the basis for the format going forward. I think
the concerns about it coming out of the IETF is probably something we don't
need to worry too terribly much about.

Alissa: That document was obsoleted by an IAB stream document.

Adam: Yes, but at the time it was published it basically spoke to a tool you
could use in creating RFCs, which is kind of what this document feels like to

Suresh: I think the difference was on the same lines as Ben said; it was an
informational document. That's where I was really on the edge. [This is] not
just an informational document.

Adam: That's a fair point.

Alissa: And when did the notion of the streams even start? It was after this
document, right?

Adam: After 2629? That was 1999 and I thought we already had streams by then.
But my memory could be faulty.

Alissa: I did a bit of digging to try to figure this out and the stream isn't
listed on documents from that time period so I assume we didn't have streams. I
don't remember when they started. The thing is, what's the point of having them
and arbitrarily enforcing when something goes on one stream vs another? If it
matters, it matters, or if it doesn't matter, then why do we have them?

Warren: This just provides a way that you can do it. It doesn't say thou must
always do it this way. Right? So if other streams choose not to do it this

Barry: It is a BCP, so at least of the IETF stream says this is the way to do

Ben: I agree with Warren that the way the document is written feels more like
it's "here's a way to do it" which would feel more like an informational
document than a BCP.

Warren: I would think that this is probably the best current way to do it. If
somebody decides not to, it's not that they are violating some law. They're
deciding not to use what we think is a best practice. But that is getting down
into semantics.

Suresh: I might move to a Discuss on this. I hadn't thought of it that way. But
it probably didn't get review from outside the Yang community. If you're going
to go with a BCP then probably we need wider review and to call it out better.
If not, move to informational. That could be a way forward for me.

Ben: That seems reasonable. Of course Ignas is not on the call. I'll just ask
if there are any other points people want to make right now or if we should
take this discussion onto the mailing list?

Mirja: I said this in my ballot but I think this is also completely out of
scope for the WG, which is another reason for the IESG to give pushback.

Warren: I agree it is completely out of scope for the WG charter. Echoing
Spencer, do the right thing. Yes they came up with a document that's not in
charter, but it feels like a useful document, so it's worth us not ignoring.

Mirja: I think we should make sure WGs stick with their charter because
otherwise charters are not useful.

Ben: I'm not saying don't publish the document, I think it should be published
but we should find a better path to publish the document.

Amy: So it sounds like the conversation will continue on the mail list and this
will stay in IESG Evaluation.

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

 o draft-ietf-rmcat-nada-12  - IETF stream
   NADA: A Unified Congestion Control Scheme for Real-Time Media
   Token: Mirja Kuehlewind

Amy: There are no Discusses in the tracker, so unless there is an objection now
this is approved.

Ben: I ran out of time and didn't finish it all the way through. Do we have
something in there about if the level of congestion is such that you can't even
support the minimum bit rate for the encoder you should abort the flow?

Mirja: I don't think that's explicitly mentioned but it's a very general
congestion control concern and I think that would happen automatically based on
the scheme implemented. If you really want to finish reviewing we can wait but
otherwise I think this document is ready to go.

Ben: No, I trust you. Go ahead and mark it approved, don't wait for me.

Mirja: We got a bunch of comments which are generic comments for all congestion
control schemes. We point to documents in the security considerations that
provide further guidance, so I think we're safe.

Ben: Sounds good.

Mirja: This is ready to go with the editor note.

 o draft-ietf-iasa2-rfc5377bis-03  - IETF stream
   Advice to the Trustees of the IETF Trust on Rights to Be Granted in
   IETF Documents (Informational)
   Token: Alissa Cooper

Amy: I have a Status Unknown, is this a yes?

Alissa: Yes, sorry.

Amy: Okay. There are no Discusses in the tracker, so unless there is an
objection now this is approved.

Alissa: Great. You can do a Revised ID please.

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


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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Audio/Video Transport Core Maintenance (avtcore)

Barry: The only question is that everyone who commented said it didn't need
external review. Does anyone think it does?

Ben: I don't have a great sense of if we have consulted the broader community
about if merging these WGs is a good plan. It's not entirely clear to me we
should just do the merge without the broader consultation. But if I'm the only
one who feels that way I don't want to impose my will on everyone.

Barry: I'm good with that.

Magnus: There's no real cost to running this through last call.

Barry: There isn't. Let's do it.

Amy: So that sounds like it should go for the external review and we'll send a
recharter announcement and we'll put it back on the agenda for next time.

4.2.2 Proposed for approval

 o Autonomic Networking Integrated Model and Approach (anima)

Amy: There are no blocking comments for this, so unless there's an objection
now this is approved.

5. IAB news we can use

Mirja: No news this time.

6. Management issues

6.1 Designated Experts for RFC 8613 [IANA #1141664] (Alexey Melnikov)

Amy: Alexey has identified three people as experts for this registry. You had a
note that you were still waiting to hear from the third one; did the last
person say yes?

Alexey: Yes, sorry. I sent a message to the IESG but forgot to BCC you. Yes.

Amy: Is there any objection to naming these three folks as the experts for this
registry? Hearing no objection, so it looks like they are approved.

6.2 Secondary Expert for Emergency Call Data Type (Adam Roach)

Adam: We have a document going through right now where the author is also the
expert, so we need someone to deal with that situation if it ever arises again.

Amy: Okay. Any objection to approving Henning Schulzrinne as a secondary
expert? Hearing none.

6.3 Next steps on IETF Website Analytics (Roman Danyliw)

Roman: Pre Montreal we walked through what the community feedback was. I'd
walked through potential ways to address that. You provided me various feedback
on some of the proposals here. What I sent around yesterday was the
consolidation of all of that feedback. I just wanted to put a time here on the
agenda for anyone that's had a chance to already look at it for questions and

Alissa: I looked at it and I thought it looked good. I think it's ready to go.

Roman: Okay, thanks. My notional plan is if I can get all feedback by next
Friday we can get it out sometime after that. We can reset the date as
required. I think that's all we need, thanks.

6.4 Plans for ADD going forward (Alissa Cooper and Barry Leiba)

Barry: What we need to do is figure out who's got the token so it doesn't get
lost. We talked about doing some sort of rechartering of dprive to pick up some
pieces of work that came from the add discussion, and then whether or not we
need to do anything to the dnsop charter to tighten it up and make sure it
doesn't wind up bleeding in. So that would bring in Eric and Ace. I see Eric
has gotten on the call. Do you have any thoughts about what to do with the
dprive charter or whether you want this stuff there?

Eric: On this one I would prefer, if you don't mind, that you and I get a
separate call on this and chat for 15 minutes. We can do it next week.

Barry: That works great.

Warren: I'd also like to be on that call if easy, but if I can't make it then I
can't. I don't think there's much in the dnsop charter that needs to change. I
think the chairs and me are more than capable of saying whether something seems
outside our scope or that this is something dnsop can make use of.

Eric: It does make sense to have this call with the three of us.

Barry: We'll do that next week and then we'll have a path forward. I have the
token to set up the call.

Alissa: Can we add this to our action items list so you can report back to the
rest of the IESG? Thanks.

Amy: We'll add that action item. Thanks.

6.5 Discuss creating a list (Barry Leiba)

Barry: I don't know that we need a lot of discussion here right now but I
incorporated everyone's suggestions and posted a new version of the plan. If
we're good with that plan we should go ahead. Does anyone have an issue or need
to discuss it further right now?

Warren: I think we just need to be fairly careful with the actual messaging.
I'm sure that's not a surprise to you. Someone had said something that they
hope we're not planning to take this off to a separate list. I had bookmarked
that email but now I've lost it.

Barry: I remember seeing it as well. The first thing I intend to do is post a
message to and I will post it to the IESG list first for a sanity
check, saying what we're planning to do and how we're planning to do it and see
what people see. It certainly seemed like at the plenary we had plenty of
support to do it and I'm sure it's not unanimous. We'll go from there. Other

Alissa: Assuming the first thing you do is reach out to the tools team and the
directorate people, as your plan lays out, in parallel should I start finding
people who will be moderators for the list?

Barry: Yes, I think that's a good idea. The first thing I'll do is post the
plan to the main IETF list and see what kind of pushback we get. I'm going to
cast it as an experiment, as Alvaro suggested, which also gets around some of
the issues with the charter of the IETF list.  If that comes out okay then
we'll go ahead and proceed and you can start looking for moderators.

Alissa: Okay. I thought we were taking a different approach. I know this is
subtle, but I thought what we were doing was a sort of "we're going to do this,
and here's the plan," and give people some time to comment on it but not gate
whether we do it or not based on the feedback. But what you just said sounds

Barry: I'd like to do it that way. Do the rest of you think it's okay to just
do it by feel?

Alvaro: There's an RFC that talks about what's okay on the IETF list, right?

Barry: Right. The problem is that the IETF list's charter specifically says
that last call discussions are appropriate for it. So I think for us to go back
from that we need to either get community consensus on changing that RFC, or
cast it as an experiment.

Alissa: I think casting it as an experiment is fine, but it doesn't say that
you can't have last call discussions on other lists.

Barry: But if what we're saying is that we're explicitly taking last call
discussions off of the IETF list and moving them there, we might or might not
get significant pushback about that.

Ben: Especially if you ask the sergeant-at-arms to enforce that, and steer
people who posted last call discussions off the general list.

Suresh: I think we're going to get pushback no matter what. Even with the RFC
stuff which really belongs in rfc-interest, we got pushback.

Barry: I think it doesn't hurt to post the plan and see what people think. I
expect we'll get some pushback but mostly support. We'll see.

Warren: I think we need to be very careful to make sure that, especially in the
current environment, we're making it very clear that we're doing what the
community wants, and we're not imposing our views.

Barry: I will point out in my note that this was proposed by the community and
we're following up on that. So Amy, there's another action item for me to post
the last call list plan to the IETF list.

6.6 Designated Experts for RFC 8554 [IANA #1141664] (Alexey Melnikov)

Amy: Alexey, you added this to approve David McGrew and Scott Fluhrer as
experts for this registry. Any objections to this?

Alexey: I emailed two of the three authors about this earlier and they just
replied now.

Amy: It looks like those are approved and we will get the note to IANA.

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

Eric: If you look at the protocol numbers on the IANA website, you see a few of
those without any specification. Like, number 114, "any 0-hop protocol."
Another one is "any private encryption scheme." Without any specification of
what needs to be done. How can we say to someone whether they can use this
protocol number?

Michelle: Most likely if there's no specification attached, it was there long
ago; possibly something Jon had put in before our time handling the IANA
services. We often have to reach out to community members to find out what the
background is on some of those registrations.

Eric: So maybe send an email to the IETF list?

Michelle: If that's the appropriate place you think we should go. Otherwise
there might be specific WGs that would be better. It's up to you.

Eric: Will do. Thank you.

Ben: On a different topic, I have a draft charter for the lake WG that I sent
out to a two week call for comments period on the mailing list we had for the
BoF. If that goes well I will be sending the charter to the IESG for review.

Alissa: Yesterday I circulated some draft charter text for gen-dispatch and I'd
appreciate it if people could take a look at that.

Mirja: I took a look and I think it looks good. I'm just wondering if we really
need to do this for every area now, or if this is more something generic we
could say this is the process without having a charter. This is a more generic
question we can discuss later.

Alissa: That's an interesting question.

Roman: I can't answer that generally but in Security we've found having a
dispatch actually quite helpful, to provide a forum to talk about ideas that
would have struggled potentially on a mailing list.

Mirja: I wasn't questioning the approach, just if we need to write a charter
for each dispatch area group separately.

Amy: I'm hoping to close the poll for the BoF coordination call today, so if
you haven't put in your availability please do that today. Right now the
frontrunner is during the time of the IESG retreat in Amsterdam.