Skip to main content

Narrative Minutes interim-2022-iesg-02 2022-01-20 15:00
narrative-minutes-interim-2022-iesg-02-202201201500-00

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

narrative-minutes-interim-2022-iesg-02-202201201500-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-01-20 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Ben Campbell (Independent Consultant) / IAB Liaison
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
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Martin Vigoureux (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area

OBSERVERS
---------------------------------
Andrew Alston
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: Does anyone have anything new to add to today's agenda?

Rob: Not sure if it's new, but can I request to bump my document up to the
start? I'm going to need to drop out between half past and the hour. That's the
ANIMA document. Thanks.

Francesca: I have something to report from EMODIR, so we can take that at the
end.

Warren: I probably need to drop after an hour but that likely won't change
anything.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the January 6
teleconference being approved? I'm hearing no objection to approving those so
we will post those in the public archive. I saw final narrative minutes; any
objection to approving the final narrative minutes from January 6?

Éric V: I have a minor correction; I was talking about the SAVI WG but it was
written as "savvy" in the narrative minutes.

Amy: We will make that change, thank you.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Zahed Sarker to find designated experts for multiple Bundle Protocol
       Registries (bundle) [IANA #1217632].

Amy: We have this on the agenda as a management item to approve these experts,
so we'll call this provisionally done.

   * OPEN ACTION ITEMS

     o John Scudder, Martin Duke, and Robert Wilton to review the document
       shepherd templates and propose changes to include updated questions,
       cross-area checks, and an expanded section on the use of YANG
       models.

Rob: If anyone's got any review comments, please can you do that today and
tomorrow? I'll sync up with Martin and John next week to get it into final
format and then we'll try to bring it to the next informal.

     o Alvaro Retana and Martin Vigoureux to draft a note to wgchairs
       asking them to always confirm author/contributor status.
     o Alvaro Retana and Martin Vigoureux to draft text to include in the
       I-D submission tool warning about too many authors.

Amy: These two hinge on the first.

     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 a little more time has passed.

     o Francesca Palombini to draft a proposal for requirements for
       archiving AUTH48 conversations between the RPC and authors/AD/
       working groups.

Amy: Is this one done? We talked about this last week and a different action
item came out of it, but this particular action seems to be done.

Francesca: This one is done. Many thanks to Jean for sending much better
requirements than I had drafted. I think with her requirements we can consider
this done.

     o Éric Vyncke to talk to the Tools Team about adding the page counts
       for documents getting an RFC 5742 conflict review to the telechat
       page count in the Datatracker.

Éric V: I've put in a ticket on this and it has been accepted by Robert, so I
think we can remove it from the list here.

     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: There has been no progress on this yet but it's next on my list of
things to do.

     o Francesca Palombini to draft text to the community on archiving
       conversations between RPC and authors.

Francesca: This is in progress but it's not too urgent.

     o Éric Vyncke to create a tools team ticket to add more
       guidance for BoF Requests in the datatracker.

Éric V: The ticket has been created today but not yet accepted. Let's leave
this until next time and once it's accepted we can remove it.

Warren: I was supposed to have one to approve the IESG statement?

Amy: That's a management item on today's agenda.

Warren: You're probably right.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-idr-bgp-open-policy-20  - IETF stream
   Route Leak Prevention and Detection using Roles in UPDATE and OPEN
   Messages (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: We're going to need a Revised ID for this one, please.

Amy: Okay, this will go into Approved, Announcement to be Sent, Revised ID
Needed. It looks like it also has a downref to RFC 7908; does that need to be
added to the downref registry?

Alvaro: I would like to see it there, but I don't think it has to [be added].
Several people commented that maybe it shouldn't be a downref. It is because it
describes the problem we're trying to solve with this draft, which is why we
made it normative. For now I would say let's leave it off the registry and we
can come back later to decide that.

Amy: So you don't need this to be added to the downref registry once the
approval announcement goes out?

Alvaro: I don't think so.

Amy: Okay, we'll make a note of that.

 o draft-ietf-httpbis-targeted-cache-control-03  - IETF stream
   Targeted HTTP Cache Control (Proposed Standard)
   Token: Francesca Palombini

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

Francesca: Thanks everybody for the reviews. I believe the authors have
addressed all the comments and proposed text. This will require a Revised ID.
the only thing I wanted to ask is, Ben, I think they have answered your
comments and they have some questions for you. Everything else is basically
addressed so once that's uploaded, if you don't have any more comments, I'll
send it forward.

Ben: I plan to reply to the email today.

Francesca: Great, thank you so much. It's just if you have any suggestions for
how to improve the text, nothing major.

Ben: There was one spot where I wanted more text and Rob has caused it to be
put into existence already.

Francesca: Great. Sounds good. Thank you.

Amy: So that sounded like it's Approved, Announcement to be Sent, Revised ID
Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-eastlake-rfc6931bis-xmlsec-uris-22  - IETF stream
   Additional XML Security Uniform Resource Identifiers (URIs)
   (Proposed Standard)
   Token: Roman Danyliw

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

Ben: No, I don't think so. And you saw that Roman sent in some directives in
email for how to process this one?

Amy: I did not but I could have missed it….ah, Revised ID. Got it. This will go
into Revised ID Needed.

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-anima-asa-guidelines-05  - IETF stream
   Guidelines for Autonomic Service Agents (Informational)
   Token: Robert Wilton

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

Rob: Only very briefly. I think actually Roman's has already been replied to on
email and I think that has resolution. Ben's one, that looks to me like a
fairly easy one to resolve in terms of fixing the code so that's being handled.
I'd like to thank everyone for their reviews and comments but I think we're
okay and don't have anything to discuss, unless Ben or anyone wants to say
anything else.

Ben: I don't have anything else to say.

Rob: Thanks everyone.

Amy: So it sounds like it needs a Revised ID?

Rob: Almost certainly. Thanks.

Amy: Okay, we'll put this in Revised ID Needed.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-zia-route-00
   IETF conflict review for draft-zia-route
     draft-zia-route-04
     Real-time Transport Object delivery over Unidirectional Transport
   (ROUTE) (ISE: Informational)
   Token: Zaheduzzaman Sarker

Amy: I have no Discusses for this conflict review, so unless there's an
objection now it looks like this is ready to go back to the ISE.

Éric V: Just a quick question, Zahed, no discussion because I don't mind too
much, but that conflict review would benefit from adding MOPS in the list of
related WGs.

Zahed: I replied to that one. I'm fine with adding that, no problem with it.
The reason I didn't talk about that was because MOPS does operations and this
is really a protocol, nothing related to video. So that's why I didn't include
it. But if you think it should be, I can do it, no problem.

Éric V: I think it's more realistic if we say it. It's been presented at MOPS
so I think it's better to include it.

Zahed: One of the things I was taking into account is that in TSV we had
discussion on what to do with this document because the ISE asked us if any TSV
groups wanted to take it. Then I had input from a number of experts and we
presented this in one of our TSV area meetings. The response was this is
interesting, but there was not much interest in doing it in the IETF. Otherwise
it would have really been a conflict with TSVWG. I have one thing to add to
Ben, Ben put up a really good comment about these normative references in this
document. I was also thinking, is that a criteria to object? I also found a
similar kind of documentation, but I think the normative language is only for
the IETF stream. Ben, do you have anything else?

Ben: No, I think this is the right conflict review response. The ISE gets to
make its own rules about what needs to be a normative reference so I don't
think that should change what conflict review response we provide.

Zahed: This is the first time I've done this and I've been really trying to
read things before I pick the right sentence for this review. This is an area
perhaps where we can be more purposeful to the ADs who are doing reviews, in
what are the different things we should be looking into. I can write a huge
list of comments for this document. Anyway, let's add MOPS here during the call
and then we can approve it.

Amy: Okay, so it sounds like this is approved to go back to the ISE with a note
that's going to be updated shortly. We'll get that sent on Monday. Thank you.

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

 o Stay Home Meet Only Online (shmoo)

Amy: This has a few blocks on it. Do we need to discuss the blocks?

Lars: I don't think so, and I don't think this is quite ready for external
review yet given the blocks. I'm hoping the chairs, who have basically written
the rechartered version, will respond. Mallory at least is active. I'm hoping
we'll get a new charter proposal written that addresses the blocks and we can
then go forward. I think the issues they raise are reasonable but I must have
read it in not enough detail to pick up on them myself, I apologize for that. I
think we're going to see new text for this.

Martin D: I kind of viewed this as a Discuss block. Lars, do you have an intent
forward, or do we need to just talk to the chairs?

Lars: At the very least it seems unclear. In the email discussion before Alex
started taking it to other things I think we were on point and just need to
clarify what we mean here.

Martin D: Okay.

Amy: Okay, so it sounds like this is going to stay right where it is and we
will wait for instruction from you, Lars, regarding SHMOO.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Martin V: None specifically, unless Mirja has a different point of view.

Mirja: It might be interesting for you to know that we confirmed the Nomcom
IESG selections so the process is ongoing now.

6. Management issues

6.1 Confirmation of NomCom selections (IETF Trust and LLC Board) (Lars Eggert)

Amy: This is just to minute the decision. Have you come to a decision and is it
ready for minuting?

Martin D: A bunch of email went by. Was it the LLC Board we did over email?

Lars: We did both. We did already confirm and we just need to minute it, so we
don't need to have a discussion since we're already done.

Amy: Can I minute that the IESG has confirmed the NomCom selections for the
IETF Trust and LLC Board?

Lars: Yes please.

6.2 [IANA #1217632] Designated experts for multiple Bundle Protocol Registries
(bundle) (Zaheduzzaman Sarker)

Amy: We have a big bundle here. Does anyone object to naming Marc Blanchet and
Keith L Scott for the Bundle Administrative Record Types, and CBHE Node
Numbers,CBHE Service Numbers; also approving Ken McKeever and Edward Birrane
for BPSec BIB-HMAC-SHA2 Integrity Scope Flags, BPSec BCB-AES-GCM AAD Scope
Flags; Brian Sipos and Rick Taylor for Session Extension Types, Transfer
Extension Types, XFER_REFUSE Reason Codes, SESS_TERM Reason Codes, MSG_REJECT
Reason Codes; Stephen Farrell and Edward Birrane for Bundle Metadata Type
Codes, Ciphersuite Numbers, Ciphersuite Flags, Ciphersuite Parameters and
Results Type Registry; and Rick Taylor for Bundle Metadata Type Codes. Any
objections to any of those people being named as the designated experts for
this bundle of registries? I'm hearing no objection so we'll get official
notice sent to IANA naming all of those people to all of those registries.

Zahed: Thank you. It was fun finding all those names. Some of these registries
started in, like, 2011 and some were never used, so it was fun finding the
people. Thanks.

6.3 Handling Ballot Positions IESG Statement (Warren Kumari)

Amy: There's been some discussion of this. Is it ready for approval today?

Warren: I think it is. Francesca just made a suggestion which I incorporated,
which is pointing to another thing.

Francesca: Thank you, uyes.

Warren: I don't really know what the process is. I think it's great, does
anybody object? If not, let's approve it.

Mirja: I'm not objecting because it's not really my business but this is a very
untypical IESG statement because it's very long and written in a different way.
I just want to say that this will be published in exactly the same way as a
blog post and people might not know the difference. I don't see the value in
publishing this twice more or less in the same form. I think a blog post is
better than the statement. But I'm not objecting to it.

Lars: Warren's done a lot of work on this. I don't quite know why we needed an
IESG statement, I think this might have predated me, but I'm fine with
publishing it. It's not going to move the world.

Mirja: For me as a reader I think the blog post is a good read. Otherwise if it
was a statement I would want it to be something really short I could read
really quickly to get the information. I don't really see the additional value
in this.

Francesca: I supported this becoming an IESG statement because there are fewer
IESG statements and for me it was easier to find IESG statements. The meaning
between a blog post and an IESG statement is different. I really liked having
this as an IESG statement. It means something else. If people find it in
different ways, that's fine. I don't see it as a problem.

Amy: Generally IESG statements are posted to the ietf.org website and we also
announce them on ietf-announce. I don't know that we do that typically for blog
posts. It's possible that it will get a wider readership, at least in the short
term, and be easier to find as a statement.

Warren: I think a fair bit of the value is that it's easier to find. A blog
post is not exactly temporary, but more ephemeral. I think some of the utility
is the fact that it is different to our standard IESG statements which always
seem very formal and we do very few of them. That's a completely separate
discussion.

Ben: I think part of the original motivation for wanting to convert this to an
IESG statement is that the statement has some weight to it, that the IESG has
made a decision as a whole that this is what we think, whereas a blog has a
fuzzier position that may not have any official standing. I volunteered Warren
to write the IESG statement version and I'm happy to see it go ahead as an IESG
statement.

Warren: Does anyone think this is a really bad idea? I fully agree it's not
going to change the world but I think having more people read it would be
useful, especially since I recently had a thing where some authors said they
have no idea what any of this stuff means.

Éric V: Regarding the readership, should we include a reference, to whether the
blog or statement, into every email sent when an AD ballots a Discuss?

Warren: I believe there's already a link to the blog post in one of the sets of
emails that authors get, but I can't remember where it is and they often don't
see it.

Ben: I think we currently have a once removed link, so there's a link to some
general information page and that page links to the blog post.

Warren: I like Éric's idea that if there's a discuss ballot, having this in it
so authors see it-- the primary intent of this is so authors don't overreact
and panic.

Lars: The link there currently goes to the blog post, handling ballot
discussions. That's where people are sent at the moment. Éric V: We may want to
replace that with the new one.

Warren: Okay, I'll try and get that done. I think I still have the ticket which
added it so I can update it and say please use this one instead when it's
posted. Awesome, thank you very much everybody.

Amy: Okay, I have this as approved and it's in our hands to post on the
website. We'll let you know when that's done, Warren.

Warren: Greg, it's basically the same as what's been posted before but it would
be nice to have a once-over, like how it still says "title." Never mind, I
think it's all good and we're fixed.

6.4 EMODIR Update (Francesca Palombini)

Francesca: During the last meeting with EMODIR I was asked about updates on
possible technical deep dives for this coming IETF. I don't know if I missed
something; have we discussed this?

Warren: Yes we had discussed it; the plan was that there was going to be a
technical deep dive on QUIC and it was going to be presented or run by a couple
of people. It's not really organized to some extent because every time I try to
convince them to generate content they say it will be better to do it in
person. Brian Trammell, Ian Sweat, and Jana. It's not likely to happen this
time.

Francesca: Not for this IETF.

Warren: Yes, that's the summary.

Francesca: That's okay, sorry I missed that. So we won't have anything
technical. We used to have a technical presentation during the plenary, that
will be the technical deep dive, right?

Warren: The technical plenary presentations have stopped, I think. The deep
dive is a separate thing.

Francesca: I'm a bit confused.

Ben: Talk to the IAB about the technical plenary.

Lars: Right, those are an IAB activity. There's been discussion about whether
those should be restarted but it doesn't look likely.

Mirja: We decided not to organize technical plenaries at this point.

Francesca: Thank you. I can report that to the emodir because if I understand
correctly for the deep dive, the emodir is part of organizing that? Or that's
what I was told?

Lars: There's a difference of opinion about who's in charge. I think Emodir
thinks they are in charge and there are other people who organize them who
believe Emodir is not necessarily helping that much. That's my understanding.
If they happen it would be good if the emodir is at least in the loop so they
can be aware of what's happening in the week.

Francesca: And advertise it to newcomers and everybody, yeah. Okay. I got what
I needed, thank you.

Lars: In answer to the IAB on the tech plenary question, some people think they
have been replaced by the deep dives. They're kind of similar.

Mirja: The deep dives are probably something that the IESG is organizing and
mainly Warren at this point, I guess. We should also make sure that if Warren
ever disappears, someone will pick it up.

Lars: Stick them on the IAB?

Mirja: Maybe we should discuss it at another point in time.

Warren: While we're chatting about this, the plan was the next one will be Quic
and I have the authors committed. We should at some point discuss what other
ones would be useful for the future. The community provided some feedback but
I'm not sure if it's still valid at this point. At the end of the next one we
can ask for yet more suggestions.

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

Martin D: Did we ever do a postmortem on the early plenary experiment and
evaluate the criteria? I don't remember doing it.

Lars: We didn't formally do it. I think we glanced at the attendee numbers and
said this looks pretty good, but I don't think we formally analyzed them. It's
good of you to remember because I think we said we would report to the
community on that.

Martin D: I know Amy, you and I had a bit of back and forth trying to find the
blue sheet numbers for some of the European time zone plenaries.

Amy: I will look but I don't think I got, was it 109 that was a European time
zone?

Martin D: Gosh, I don't remember.

Amy: There were specific ones we were looking for that we were missing. I'm not
sure I actually got the numbers but I will go back into my email and double
check that for you.

Martin D: Do you have ready access to the criteria we laid out or would it be
helpful to email that to you?

Amy: I'm not sure I understand the question.

Martin D: There were something like five criteria we laid out to evaluate this.
If it's possible to do it for the informal, I'd really appreciate your help or
somebody in the Secretariat's, collating that information.

Amy: Sure, why don't you get me what info you're looking for and we'll see what
we can do.

Martin D: Great, I'll send you an email.

Lars: Can we do an action item to track this so it doesn't fall off?

Martin D: Yes. And assuming this isn't hard to gather, the idea is that at the
next informal we can just run through it.

Lars: I just thought to add it to the list of action items so we have it.

Martin D: That's fine.

Francesca: I had a question for my fellow ADs. I figured I would ask rather
than send an email. I got several requests to set up non-wg mailing lists. I
was wondering where I can find information about policies or process and IESG
opinion on when it's appropriate to set up a non-wg mailing list?

Lars: There's a page in the datatracker. It used to be an ascii form you fill
out, I don't know if it's different now.

Ben: The policy is that mailing lists are cheap and you should feel free to
create them with abandon. There's a page that looks like a form that asks you
for some info that you don't really have until the list is created, which is
kind of weird, so whenever I send people a link to the page I include a
disclaimer that some of what it asks for is nonsense and just fill in what you
can.

Warren: There is also, or for a while there was a thing where you filled in a
form and it would send mail to the group that would do something with it. For a
while that link wasn't going anywhere or the mailbox wasn't being monitored.
I'd suggest if someone fills out the form and doesn't get a response in a
couple of days, to poke someone.

Francesca: My question was less about how to do it, because I would ask the
Secretariat for that, but more when is it appropriate to create a non-wg
mailing list? In this particular case I have people who work with stuff that is
related to an ART wg but they don't have a mailing list right now to discuss
this so they asked if they can get a list @ietf.

Warren: I think the general thing is try and make it so that their list does
not end with wg, or people will assume it's a wg. And if people make a mailing
list and then they think they might eventually have a  wg, it gets very
confusing that there's an existing list and a wg and the names are not the same.

Francesca: Yes, they are aware this is not for a wg so that shouldn't be an
issue.

Lars: In general Ben is right, there are very few reasons why you wouldn't give
somebody a list.

Ben: If there's no connection to the IETF at all, you can reject it.

Francesca: There's some connection but it's kind of far.

Lars: if it's related to an ART wg, there's a connection.

John: There's one potential negative I can think of to just creating mailing
lists with abandon. Didn't we run into the problem last year about some mailing
lists that don't have a moderator? These non wg mailing lists have an
administrator but they don't formally have moderators, which makes them an
attractive nuisance or potentially does. Is that something we should fix?

Murray: I think they typically start with a list owner who is the person that
asked for it or an AD or something. Over time, who keeps those things current
is something to consider. If it becomes a big spam trap then tools has to come
in and deal with it or find new owners or shut the list down or something like
that.

John: A spam trap but more problematically a flame trap. Our trolls seem to be
in hibernation right now for the most part but next time they crop up it'll be
a thing again.

Warren: Somebody asked a question off list who I may accidentally expose, what
is the note well stuff for IETF mailing lists for non0-wg lists? I don't know.

Murray: It's the same.

Warren: Okay. So once the new IESG slate is announced, many of the people who
are going to be ADs are likely to start showing up. Technically they are
observers but should we have it so people who are going to be observing can ask
questions without having to have someone ask a question for them?

Lars: Once they are announced I think we can basically treat the incoming ADs
as ADs for all intents and purposes. They should speak up because it's going to
be their game shortly afterwards. I'm pushing Gabriel to get the announcements
out so we can have a nice and long overlap period.

Murray: One last thing about non-wg mailing lists, I would just make sure that
someone's not asking for a non-wg mailing list because they want a venue to
talk about their thing where that thing is already covered by an existing wg
because they don't like those people. That sort of nonsense is something I
would look for.

Warren: Another thing related to non -g lists. If it happens to be purely a
social activity it would be nice if the list ended in -ag and then we can add
it to the affiliates list, which is basically runners or cyclists and that sort
of stuff. Just to make it easier for people to find.

Alvaro: It's probably good to give everyone a heads up about a new list just in
case.

Francesca: Okay, so I will send this to IESG.

Warren: We've missed something really obvious. Dear Secretariat, is there
something stupid we're misisng about mailing lists?

Amy: I don't think so. Just send email to support and we can help you in any
way you need setting up a list. Francesca: Thank you for all the information, I
got what I needed.

Lars: Looking at next week, on Wednesday we have a joint workshop with the IAB
on bringing new work to the IETF. Since this predates my vacation, I forgot
about it. Is the IAB organizing this for us, or who owns the content? I know it
came out of a bunch of ideas the IAB had but I don't know who's preparing
something.

Mirja: That's a good question. We will discuss this on the IAB but I'm not sure.

Lars: Okay, so we've identified a need to send some email to some people. The
IAB can propose some ideas and there are some on the IESG side too. This is an
opportunity for everyone, if you have ideas for starting new work, we have two
hours next Wednesday to discuss this. Virtual BOFs is something we could
propose and I don't think the IAB has heard directly from us.

Francesca: I started a thread talking about virtual bofs and I got some really
interesting comments. I still have to reply and incorporate the feedback
directly in the document. I think the goal was to discuss it during the BOF
call, which was the deadline we had set.

Mirja: When we discussed this new work there was some feedback during the last
plenary to the IAB that we could be more active in supporting new work and we
ended up discussing mostly about how to support people in creating BOFs. There
might be another step of how to support people actually getting into the IETF
that we can discuss but this is closely related to how to organize BOFs.

Francesca: If I need to have some sort of recap of what we discussed by
Wednesday, if we plan to discuss it, that would be good to know. In my head it
was [going to be] on the BOF coordination call.

Mirja: If it's possible for you, I think it would be a good fit. I would think
having it there makes more sense.

Francesca: Okay, I will try to do it. That's one topic.

Lars: We have a few more BOF proposals now in the tracker which is encouraging.
I pinged the group of people who approached me earlier about doing a NomCom
term limits related BOF and asked them if they were going to send us a proposal
or not but I haven't heard back. My latest state before that was they thought
somebody else would arrange this BOF and maybe they lost energy or something.
I'll let you know if something's happening.

Éric V: Speaking of those BOF proposals, I know we have a call next Friday.
Should we try to get, among ourselves, a preview of who could be the
shepherding ADs?

Alvaro: I have to drop off in a second for a call. I am looking at that
multicast source routing one. The proponents of the CAN one sent the routing
ADs an email this morning about looking at that. In the description they talk
about overlap with things like ALTO and some other TSV stuff. I think I sent an
email to Martin earlier about looking at that too. It may be routing or
transport so we probably need to figure that one out. And the other one I think
is you, Éric.

Éric V: In that one there's maybe an impact on BGP so it could be routing as
well, the source address validation for intra-and inter-domain. I've been
approached by Dan Li and others from the Chinese university. I'm fine taking
ownership but it also intersects with routing and security as well. So it's a
little bit unclear.

Alvaro: We would all three be happy to talk to you about the routing stuff.

Éric V: I will put myself as the shepherding AD and we can always change it
later.

Murray: I have one last thing to discuss. We've had a flurry over the last
several months in ART of email extension docs that are looking for processing.
They don't have a home; we don't have a WG that's able to take them. The active
email WGs right now are very tightly chartered to work on just the things they
were set up for, and are not very interested in rechartering outside that, at
least not until their first work items are done. All of these documents have
been going to the ISE and getting individually processed, which is fine and
they can do that, but we've had a couple of problems. One is the realization
that there are a lot of these, and the ISE is now becoming a mini IETF except
nobody works on consensus. The first one through becomes the official one,
which is not a great place for us to be. In other cases where we have two
competing views, both of them go to the ISE and now who's right? Or one will go
to the ISE and one will attempt to get me to sponsor it, because the standards
track is stronger. The proposal from the ISE is that we really should have a
place in the IETF to deal with this stuff. It's not right that it just all
keeps landing on the ISE. It's not his area of expertise. He can ask for
reviews of course but when there are actually competing documents and two
groups of authors don't see eye to eye and aren't willing to cooperate, how do
we break this tie? We could just say neither of you get to publish anything,
but then we're doing a disservice to the community that this information is not
getting published. The proposal is a standing WG that can deal with the flow of
these coming in and it can go dormant from time to time. The problem is past
IESGs have said we shouldn't have standing WGs. The one that comes to mind is
DNSEXT, which after a while was shut down because it was just more of a problem
than it was solving. The ops people here will probably have more history on
that than I do. That's just what I remember as the example of why we don't want
to do WGs like this. Of course then for a standing WG you'd have to have
longevity with chairs, when it goes dormant how do you deal with a dormant WG,
when you light it up two years later does it even have chairs? I wanted to test
the waters here and see how does this IESG feel about this. Should we proceed
trying to start a standing WG and find chairs for it? Is there some other
solution here to breaking these ties or this problem we've got that there's a
flurry of work with no home and it doesn't seem like there's enough to spin up
a WG to deal with them individually. With three or four of them in flight I
would have to find eight co-chairs and that seems a little crazy.

John: We have at least several maintenance groups that sound to me like a
standing WG, so I don't really see how this is any different.

Murray: Okay. This is a different IESG than the ones who have shut them down in
the past, which is fine, I'm happy to do it if that's the way we want to go.

Rob: Another possible choice would be to handle them in the area WGs.

Murray: ART doesn't have that anymore. With the merger of RAI and APPS, Apps
used to have APPSAWG which was chartered to do it and had an appropriate
audience for it. We tried it with Dispatch and the audience has changed to
where that was a bit of a disaster we're now cleaning up. The wrong people
looked at it at the wrong times in the wrong ways and then it got all the way
through to IESG approval and now appeals have been threatened. It just didn't
get handled the way we needed it to get handled, so that model does not seem to
work for dispatch. So ART doesn't have an area group anymore, so I agree with
you it could happen that way but we don't have the benefit that other areas
have of that. We could try to spin that up again if there's appetite for it but
that seems like a second choice.

Rob: And there's a downside to an opsawg, in that I think there are quite a lot
of people working on different things in that WG and it's not really clear to
me that they're talking much or cross reviewing the different things. It's
almost like different work happening in the same place. In the other cases,
that's meant to be the maintenance working group for the management protocols
but the experts aren't there, the viewers aren't there, and the interest isn't
there. So it's also stuck that it's hard to pull in the folks that, if there is
anyone who cares about these documents that people should be able to push
through the IETF, but getting the interest to do them is hard. It is a problem.

Lars: In transport there's tsvwg which is lots of different unrelated work
items under one umbrella and it's been struggling for a while now. Email seems
like a large enough technical topic that you could have an email focused
maintenance wg that would probably attract that audience. When you don't need
it anymore you could shut it down.

Murray: Yeah. The obvious name that comes to mind is Mailman but that's what
the software is called, so we'll have to come up with something else. Okay,
I'll put a charter together and see if I can find people who are interested in
chairing something like this. It would be a better place to do it. My most
recent memory of maintenance WGs was that the IESG was negative on them, but if
that's clearly switched, then I'll change my tune and we'll head that way.
Thanks for the discussion. Francesca, did I cover that right and is there
anything you want to add?

Francesca: It was great. The only thing that maybe wasn't very clear is that I
would expect the work in this WG to be non-uncontroversial, let's say. That's
why going through dispatch or AD sponsored would not make a lot of sense. I
think a WG is the best option and we can see how that works.

Amy: Anything else? Thanks, see you next week.