Narrative Minutes interim-2021-iesg-26 2021-12-16 15:00
narrative-minutes-interim-2021-iesg-26-202112161500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2021-12-16 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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

REGRETS
---------------------------------
Jay Daley / IETF Executive Director

OBSERVERS
---------------------------------
Ian Farrer
Paul Kyzivat
Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? Any other changes?
We got the executive session for today added at the end of the call.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the December 2 telechat
being approved? I'm hearing no objection, so we'll get those posted. I also saw
the final narrative minutes from December 2; any objection to approving those
for posting? Hearing no objections there either.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Zahed Sarker to find designated experts for RFC-ietf-quic-http
       (Hypertext Transfer Protocol Version 3 (HTTP/3))(http3-parameters)
       [IANA #1217617].

Amy: Zahed has identified a couple of experts and their approval is on today's
agenda.

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

Zahed: I'm working on it. I talked with Michelle about maybe not needing
experts for all the registries, since some of them have not had requests since
2011. The response has not been great. Maybe we will not provide all the
experts but some.

     o Roman Danyliw to find designated experts for RFC 9158 (SMI Security
       for PKIX CRMF Registration Controls for Alternate Certificate
       Formats)(smi-numbers) [IANA #1217716].

Amy: This is also on the agenda for approval later today.

     o Roman Danyliw to find designated experts for RFC 6931, (Additional
       XML Security Uniform Resource Identifiers (URIs))[IANA #1218411].

Roman: I'm still working on this--in progress.

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

Amy: I know this was on the agenda last week for the informal but we didn't get
to it, so hopefully this will come back in the new year.

Rob: I think we'll get it back on 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.

These two items depend on the first.

     o Murray Kucherawy to update BCP 97 to provide guidance about handling
       normative references to non-SDO documents.

Murray: In progress. Should we leave this open until it reaches some sort of
IESG state?

Amy: Is this going forward as an individual document? Do you have an AD
identified as shepherd?

Murray: Yes, I have Erik K.

Amy: If you've got a person and it's at the point where it's just in the
pipeline, we can probably call this action item done.

Murray: All right, let's call this done.

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

Amy: This is on hold until March.

     o Warren Kumari to rewrite the IESG blog post on "Handling IESG ballot
       positions" as an IESG statement.

Amy: This is on the agenda as a management item to discuss that text.

     o Martin Duke to draft a followup email to the community regarding the
       ADs 360 degree reviews to include text regarding bringing issues to the
       IETF ombudsteam.

Martin D: I did that and nobody wanted to do it, so I'm happy to let it die,
unless people want me to write a more narrow thing about the ombudsteam. I
don't know that we need that. Does anybody want me to write something else in
this area or are we satisfied?

Rob: I think we're past the window where this would be useful.

Martin D: Okay; let's kill it then.

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

Amy: This came out of a discussion last week and Robert said he would be open
to discussing this again in January.

Francesca: This is in progress; we need more discussion.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-netconf-sztp-csr-12  - IETF stream
   Conveying a Certificate Signing Request (CSR) in a Secure Zero
   Touch Provisioning (SZTP) Bootstrapping Request (Proposed Standard)
   Token: Robert Wilton

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

Rob: I'm not sure. I don't think Kent, the principal author, has gotten back to
Zahed yet so I'll chase him to comment on this. I don't think it has considered
7807 but since this is based on restconf, it's probably trying to use the
mechanisms within that. I'll get Kent's response on that. The second one, I'm
wondering if that's just a typo and it should be using the same one from the
other document. Unless you want to comment, I think we'll just wait for a
response.

Zahed: I got a response from the authors that the second one is a typo and the
first one is because they're using the restconf. I think they're also saying
this should have been done when restconf was considered. I don't think there's
any action we need to do right now other than fixing the typo.

Rob: Okay. So they'll fix that and then you can clear.

Zahed: Yes.

Rob: Okay. Sorry I missed the response.

Amy: Okay, this will stay in IESG Evaluation with Revised ID Needed.

 o draft-ietf-tsvwg-rfc4960-bis-17  - IETF stream
   Stream Control Transmission Protocol (Proposed Standard)
   Token: Martin Duke

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

Martin D: We don't need to discuss the Discuss; it's new and we should let the
authors respond. Some other comments: obviously 8540 yes. The issue we should
probably talk about is going from Proposed to Internet Standard. I got an email
from the authors yesterday that basically some AD, maybe me or maybe Magnus,
gave them the guidance to go ahead and run it as Proposed Standard and if there
were no errata after some time, do a document action to bring it to Internet
Standard. I don't know if that's the procedure; I don't think it is. I don't
know what people think; should we just do it to Internet Standard now? I'm kind
of skeptical there will be more errata.

Ben: I did try to make some notes. There were enough things that changed or
looked like they had changed that I would really want to take a much closer
look before trying to put it to Internet Standard right now.

Martin D: Okay, we can just leave it at PS.

Zahed: I think that's the view of the authors as well; these things have been
changed. THey have implemented some of them but not all of them have been
tested, so maybe some time is needed to make it Internet Standard. I saw a
response to that from Michael and it looks reasonable to me, at least.

John: That sounds just fine.

Martin D: Okay, then I think we're in agreement. Other than that I think the
comments are pretty reasonable and the authors will interact.

Lars: On a similar standards thing, can they take out the sentence that talks
about it being prepared as if for the purposes of being an Internet Standard?
And the WG chairs, this is not only for TSVWG but in general, they should make
sure the Datatracker has the correct intended status. This one says Proposed
and it's confusing if it's not correct because it affects a bunch of stuff.

Martin D: Well for now our intended status is Proposed, so that is accurate.
There will be a later document action in a year or so to do a status change, is
I think how we would proceed.

Lars: That's right. When I read this I thought the Datatracker status was
incorrect.

Martin D: Okay, that's it. This status is obviously Revised ID Needed. It
sounds like Ben's Discuss will not be hard to resolve.

Amy: This will stay in IESG Evaluation, Revised ID Needed.

 o draft-ietf-dhc-dhcpv6-yang-24  - IETF stream
   YANG Data Model for DHCPv6 Configuration (Proposed Standard)
   Token: Eric Vyncke

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

Eric V: If possible, I wouldn't mind. Please note the author Ian is on the call
as well so he may be in a position to talk. Thank you everyone for the review,
specifically to Ben for looking at all of the regex. I had looked at the main
one but not all of them, so thank you. By the way, many of your Yang related
points were not detected by the Yang doctors review, which is kind of a
concern. The main issue is regarding strings that are binary in the model. Some
of them are, like the authentication, and Ian I will give you the floor after
to see if I'm incorrect. The options are binary in the HTTP protocol so they
should be binary in the Yang as well. The only exception is for the HTTP unique
ID which I think is easier to make into the model as hex. Then we can use regex
on it. But we need to be sure.

Ben: I don't have a strong position on should this particular one be string,
should that particular one be binary. My primary concern is that we are clear
on what it should actually be so everyone implements the same thing. I know
we've had a lot of trouble in router configuration when we try to put in the
key for an HMAC or something, some devices will take that string directly but
you can only configure your printable string so the set of keys you can use is
much smaller. Other devices will do a base-64 or hex decoding and it's caused a
lot of problems in the past. I just want to be really clear what exactly is
supposed to go into this configuration.

Warren: It can be very entertaining to have a device which you think is taking
base-64 but it believes that it's taking it as the raw key. That's caused much
entertainment.

Eric V: Or some definition of entertainment, I guess. Ian, do you want to make
a point or ask a question of Ben in order to fix his Discuss? You are free to
talk if you want.

Ian Farrer: I'm just working through the Discuss comments at the moment, thanks
for those. I think they all seem logical enough as far as I've got through at
the moment. Where you've suggested binary, yes that works. We do need to have
the regex patterns and I think you suggested hex for that, not string.

Ben: It would be the string type, and then to say in the description that it's
the hexadecimal.

Ian: Right. You have uncovered one that actually I think I need to remodel an
option altogether. In some cases if you can use a clear text password you can
also supply hex in there, so maybe that just needs some refinement to the way
the option is modeled. I'll rework that and propose it in a reply to you.

Ben: That sounds good; thank you, Ian.

Eric V: Thank you. And the last point, this comment is for you, Rob, based on
Murray's comment point. When we have a Yang model that makes reference to some
RFC, in the document do we need to make those RFCs normative or informative or
not at all?

Rob: I think it would be one of the two. I'm not sure, in the case where it's
in a reference, that it matters too much. It probably comes down to do you need
to understand the meaning of that reference to understand the Yang model? So I
think it probably depends on the use case. Sometimes it might do to understand
the meaning of it, or it might just be here's extra information to find out
where this is defined and you don't need to look elsewhere. I think it's on a
case-by-case basis.

Warren: I agree. I think if you're stuck on a desert island, which set of RFCs
would you need with you if you want to implement this? If it's just something
that's nice to know or you could get by without it, that's informational. At
some point there's a blurring of the lines.

Eric V: So basically Rob, it means we consider the RFCs in the Yang models as
RFC references in the RFC text itself, not in the model.

Rob: I think so, yes, effectively. That makes sense.

Eric V: Okay, I think we are clear. Thank you again for your reviews and thank
you Ian for tuning in. I guess this is Revised ID Needed.

 o draft-ietf-rum-rue-09  - IETF stream
   Interoperability Profile for Relay User Equipment (Proposed
   Standard)
   Token: Murray Kucherawy

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

Murray: No, I don't think so. There's plenty of work for the authors to reply
to. They've replied to a couple of things. The TSV-DIR review generated a lot
of the Discuss stuff and I think they're responding to that rather than to the
Discusses directly, but they are looking into this. I'm wondering if I hold the
record for IPR declarations on this document. Anyway, Revised ID Needed.

 o draft-ietf-httpbis-priority-11  - IETF stream
   Extensible Prioritization Scheme for HTTP (Proposed Standard)
   Token: Francesca Palombini

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

Francesca: Thanks for the reviews, everyone. I would like AD Followup because I
haven't had time to check. I expect there should be an update but I'm not sure
what's been taken care of by the authors yet. Something I noticed that I
thought was strange is that Ben, I couldn't see your review in the mail
archive. I see it in the ballots but when I searched for it in the mail archive
I couldn't find it. I'm not sure if the authors have seen it.

Ben: I thought I had pushed send email, but maybe there's something weird with
the external mail list and the datatracker holding mail for moderation or
something.

Francesca: Because others are there. I'll post a link to the mail archive with
the search. Anyway, I think the authors have answered almost all reviews, not
the one from Eric, but I'll check that. So it's AD Followup.

Amy: Okay, this one is Approved, Announcement to be Sent, AD Followup. You can
let us know when that's ready.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-tls-external-psk-guidance-04  - IETF stream
   Guidance for External PSK Usage in TLS (Informational)
   Token: Benjamin Kaduk

Amy: I have no Discusses  for this document, so unless there's an objection it
looks like this one is approved.

Ben: Let's put this in AD Followup; I was pretty slammed this week and didn't
get a chance to look at all of the comments yet.

Amy: Okay, this is Approved, Announcement to be Sent, AD Followup.

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-mymb-sfc-nsh-allocation-timestamp-00
   IETF conflict review for draft-mymb-sfc-nsh-allocation-timestamp
     draft-mymb-sfc-nsh-allocation-timestamp-11
     Network Service Header (NSH) Fixed-Length Context Header
   Allocation: Timestamp (ISE: Informational)
   Token: Martin Vigoureux

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

Ben: I think the review is fine. I'll just take this opportunity to soapbox
about converting the conflict review from the request for assigning the AD to
actually do it into the thing we need to ballot on during the week of the
telechat can be a little dicey in terms of workload planning, since we do have
to at least somewhat read the document that is being conflict reviewed in order
to ballot on the conflict review. Both of the ones this week were fairly short
so it wasn't a huge problem but it's something to keep in mind when you are
preparing a response.

Martin V: That's a good point, Ben. I had kind of forgotten that this was on my
to-do list so I did it pretty late. I also realized that even if you do the
conflict review you still need to move the document into IESG review, it's not
automatic. It delayed the notification to the IESG that you could ballot on it.

Ben: That's probably true and would be a contributing factor.

Martin V: But it was only a few hours, so I can't take that as an excuse.

Ben: I wasn't trying to pick on you.

Martin V: I understand. Just to let you know, I have sent comments directly to
Adrian on that document in addition.

Ben: Thanks.

Erik K: I wanted to know if anyone knows if the Datatracker estimation of pages
to be read includes the underlying ISE document for conflict reviews.

Cindy: It does not. The page count thing does not count conflict reviews or WG
charters.

Erik K: Okay. That's helpful to know, thank you.

Lars: Could we request that we want to add this? Charters are not typically
that long, but it makes sense to include at least the conflict review.

Erik K: I wasn't terribly worried about charters, but related to Ben's point
about reviewing a document.

Roman: I would support that feature change.

Warren: I guess I'm sort of either way. When I read the documents that are the
base for the conflict review, they're much less time consuming in terms of the
checking I need to do. I mostly read it and see if there's anything dangerous,
instead of reading each sentence and stopping to check that I understand it.
But yeah, it makes sense.

Eric V: As I am the tools liaison, let me take this as an action item to send
an email. I don't think one page of a conflict review equals one page of a
document action, like you said Warren, but maybe 50% or one-third or something.

Lars: It might also be enough to basically count the ones we need to review
because of ballots and then have another count just for informational purposes
of the conflict review pages.

Erik K: It could just be a parenthetical number.

Eric V: Okay. I'll send an email to see what is the best way for us. Can you
make this an action item for me?

Amy: Certainly. Okay, so it sounds like the conflict review is ready to go.

 o conflict-review-moura-dnsop-authoritative-recommendations-01
   IETF conflict review for
   draft-moura-dnsop-authoritative-recommendations
     draft-moura-dnsop-authoritative-recommendations-10
     Considerations for Large Authoritative DNS Servers Operators
   (ISE: Informational)
   Token: Warren Kumari

Amy: I have no Discusses for this conflict review, so unless there's an
objection now it looks like this can go back to the ISE. Okay, I'm hearing no
objection, so we will send this back to the ISE.

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 Secure Telephone Identity Revisited (stir)

Amy: I have no blocks for sending this out to external review, so it looks like
this is approved for external review.

Murray: Thanks for the suggestion, Roman; I have milestones to add and just
didn't bother adding them to the internal version. I'll get them on there
before it goes out to external.

Amy: Okay, we'll get this sent tomorrow unless you want us to wait for those
milestones.

Murray: No, I'll get them in this morning. Thanks.

4.2.2 Proposed for approval

 o General Area Dispatch (gendispatch)

Amy: I have no blocks for approving this, so it looks like this is approved for
rechartering unless there's an objection now. I'm hearing no objection, so this
recharter is approved and we will send an announcement for it.

 o Software Updates for Internet of Things (suit)

Amy: I have no blocks for approving this, so it looks like this is approved for
rechartering unless there's an objection now. I'm hearing no objection, so this
is approved and we'll send the announcement tomorrow.

Roman: I just wanted to say thank you to the rest of the IESG. You didn't have
any comments this time but the initial review you did on the first versions was
very helpful. Much appreciated.

5. IAB news we can use

Martin V: No specific news, unless Lars wants to raise something.

Lars: I would just briefly mention that the IAB is still discussing how to
review BoFs and how to assign BoF shepherds. It seems they would like to take a
more proactive role, rather than being asked, and if an IAB member wants to
help a BoF along they can just go and do it. I would think that's fine as long
as they let us know, and I cautioned them a little bit that they should make it
clear that doesn't imply any IAB endorsement for the BoF proponents. It might
be a little weird if the proponents of a BoF understand the involvement of an
IAB member as basically leadership approval. So we should make sure we send the
right message as to what that means. The other thing related to that was about
Francesca's proposal of virtual BoFs, which would change the entire way we
review them. Alvaro posted some slides that were discussed a while ago and some
of that is captured there. This is something we want to keep talking about with
the IAB and maybe it's time for another joint meeting next year.

6. Management issues

6.1 [IANA #1216109] Management Item: Acceptance of media type registration from
standards organization Unidata (IANA)

Amy: This was on the agenda last time and the discussion was to hold it over so
that people could look into Unidata a bit more. I'm not sure if that has
happened.

Murray: I did. It led to a thread where I was asking what to do about guidance
with respect to how we decide what is a valid standards organization and should
IANA be asking us for these for every external request or just when that
organization says they want to be so registered. I don't know if that's
resolved, but for this one case, I wouldn't object to this one.

Amy: Does anybody object to accepting the media type registration from Unidata
and adding them to the tree?

Lars: I'm not objecting but we had this broader discussion, the question being
whether we always have to approve the organization making a request when they
make a request, like we're discussing now, or if it's okay to do it as a
one-off.

Murray: The text of 6838 says this is the process and IANA is always supposed
to ask, even if the applicant did not ask for addition to the list. If they
represent an organization, that's the process. I'm wondering if we should turn
it into a thing where it only comes to the IESG for addition to the list if
they ask specifically, and then we should have guidance on what we consider a
bona fide standards organization, because that guidance doesn't exist.

Lars: I agree, it seems like we need to revise these a little bit. Do we have
anybody who wants to think about this more and take an action item?

Murray: I'll do it. I've been involved in media types for a while so I'll take
a look.

Lars: I guess for this one, it means we should decide based on the current
rules. I looked at them and they looked more like a research consortium than a 
standards body.

Murray: I agree with you but in the absence of that guidance, I'm comfortable
saying yes on the basis that this is organized. The last couple we've seen have
been just a person with a website and this is much more established. I wouldn't
complain about this one unless we want to wait until we lay out what we will
and won't allow.

Lars: It's not like there is necessarily a big danger here in terms of
requesting millions of things. I'm sure IANA would get back to us if they did.

Ben: We've already kept them waiting for four or six weeks.

Lars: I'm fine with approving this one, but we should make sure we don't drop
the ball on revising this guidance.

Amy: Okay, so this particular item is approved and I have an action item for
Murray to draft revised guidance from RFC 6838, BCP 13.

6.2 Virtual BoFs (Francesca Palombini)

Francesca: I started a thread a bit late, but thank you Martin and Alvaro for
answering that thread. It was really interesting to see that this had been
discussed before. No idea is new. I looked at the narrative minutes from that
formal telechat.

Alvaro: What we discussed before wasn't having virtual BoFs, it was reviewing
BoFs on an ongoing basis.

Francesca: It's related, right? If we do agree that it would be good to have
interim BoFs or virtual BoFs in between meetings, the next natural question is
how do you make sure you review them. I actually haven't read the discussion in
detail in the minutes but do you remember the conclusion of that discussion?

Alvaro: We discussed that at about this time during the cycle, because one of
the other items in today's agenda is to figure out the important dates. We were
going to be discussing the BoF dates, and in the end we didn't want to change
the dates right now. In other words we decided to not change the process at
all. There wasn't a specific BoF to go do something. For now, for example, this
cycle I don't think we need to change, or we shouldn't change the BoF process
for the cycle because we're already too late. If we want to change it we can do
it after 113, but not now.

Francesca: So what you're saying is that if we do want to allow for virtual
BoFs, that should happen after the next meeting?

Alvaro: No, if we're going to change the process to consider BoFs more often,
and not just before the meeting, which will probably allow for virtual BoFs,
then we want to do it after 113. I think that's a different question than
should we allow your BoF to happen now?

Francesca: Okay. Martin, you also had a comment, that the BoF should be held in
two meetings if it was possible to have virtual BoFs, to allow for more
participants in different time zones. Right?

Martin D: Yeah, I think that would be a good experiment to see if that
increases engagement. What we're losing going from an in-meeting BoF to a
virtual BoF is having the whole community be together.

Eric V: I fully second you, Martin.

Francesca: That's something that would be highlighted to the chairs who would
be the ones tasked with organizing and finding the right time for the BoF. I
wouldn't force them to do that but I could strongly suggest. There are
different ways to schedule meetings, and one is to get people to answer a
doodle poll and schedule based on that. It could be highlighted for sure.

Eric V: Getting a broad exposure of a BoF is key. We want to gather the advice
and feedback from many people, including perhaps people who are not interested
in the topic. If I see something that interests me, maybe I will wake up at 2
am. But if it's not interesting to me at first sight, I won't wake up, even if
maybe it would have been interesting anyway. I'm supportive of Martin's points.

Francesca: Another thing I realized, and I apologize for not finding this info,
where is the process for approving a BoF defined? I looked briefly and I could
not find it. I would appreciate it if anyone can point to either an RFC or an
IESG statement or something public that details it.

Rob: One issue with holding a BoF twice in two time zones is the risk that you
get two different outcomes. Is that a risk? Or does the chair then have to
consolidate the input from those two together and come to a decision?

Francesca: Yes. It has been done, not for BoFs, but we had a virtual interim
with gendispatch that was very controversial and the chairs had to take all the
input from the first meeting and all the input from the second meeting and
consolidate and summarize.

Warren: That puts a lot of stress and responsibility on the chairs, and no
matter how good a job they do, you run the risk of people feeling that they
weren't consulted and having their noses put out of joint. If the first meeting
is like 'this is the best idea ever' and the second meeting is 'here are the 47
reasons it could never possibly work,' then….

Francesca: That's one of the reasons I would never want to force this to be
done.

Lars: 2418 actually says that a BoF can only be held once.  Two meetings in two
different time slots are not what we mean.

Francesca: There could be part one and part two?

Lars: It's your appeal!

Alvaro: 2418 also says that it has to be at the face to face meeting. So if
we're changing the rules for virtual meetings we can change the rules for
everything.

Lars: It would require us doing something about 2418.

Warren: I still think it makes sense to just have this be a virtual side
meeting sponsored by Francesca, or something. I understand that everyone knows
what a BoF is and it has some standing, but i think the important bit is will
people show up and are they interested in the work? If it's called a
foozlewhatsit instead of a BoF, we can still discuss it. But I understand some
people don't like that.

Martin D: Can the proponents get what they need out of a virtual side meeting
hosted by Francesca, which is the official permission to proceed and get work?

Warren: They can start working on it. They might not get a gold star that says
they're official, but you don't really need a gold star. The only reason you
need an official thing is so you can get time on the agenda. Whether they're an
IETF working group or something, it doesn't actually change whether they can
sit around and discuss stuff and write a document.

Alvaro: I don't know if what I'm going to say is what you meant, Warren, but
I'll give it a go. We don't need a BoF to charter a WG. If you meet at this
side meeting, the official result can be to form a WG.

Warren: That's not what I meant, but that's better.

Alvaro: Then Francesca can take that input and go ahead and charter a WG.

Martin D: It seems to be playing with the definitions to avoid 2418. I would
just say do a process experiment and call it an experiment. If this turns out
to be successful, we rev 2418. Rather than obscure the purpose of this meeting.
Trying to avoid violating policy when we are trying an experiment and therefore
using terms that obscure the purpose of the meeting seems backwards to me.

Roman: I'm with Martin. The reality is we do the BoF and it still has to go to
the community on whether it gets chartered or not. It's not like we're slipping
anything by. We're really just modulating how the conversation happens that
ultimately informs the charter that will go to the community and us multiple
times and everyone's going to have their say.

Martin D: I definitely see that the weak link in this is the chairs. Proponents
are there trying to get their work done, but the chairs have to take two
meetings and synthesize. But they already do have to consolidate input for the
meeting on the list, so it's not like you just take a transcript of a meeting
and you're done. That consolidation effort already exists in the current model.

Roman: I agree. Now that we live in a world where you can go from a secdispatch
pitch to a mailing list to discuss a charter and then get a charter approved
without holding a BoF, a tight grip on how BoFs happen doesn't make sense and
we should be open to experimentation.

Lars: The only downside to the process experiment, which is the cleanest way to
do it, is that it doesn't help Francesca because it would require publishing an
RFC first, which is easily four months. But it might still be worthwhile doing
it so we can do it again in the future.

Warren: Can someone explain what the proponents actually want, other than their
official gold star saying they're recognized?

Francesca: With the BoF instead of a normal side meeting? BoFs reach more
people because they get more attention.

Warren: Is that true? Can't we send emails to all the WGs?

Francesca: in this case it was also the outcome of dispatching, that this
should be a BoF. It's not really the proponents, it's the community who thinks
there needs to be more discussion so we should have a BoF.

Warren: To me the BoF part feels like process stuff, not getting the work done
stuff. Whether they have to have a BoF at 113---

Francesca: If we have a process that is supposed to do exactly what we're
hoping, which is community discussion and IESG being aware, etc, why do a side
meeting? It seems weird to say let's not do a BoF but you can have a side
meeting and then we'll do WG formation. That's what we have BoFs for.

Warren: Yes, except that BoFs were designed in an era where you wanted people
to all show up in a room and hang around to chat with each other. Share the
idea of new work with other people. To me it sounds like the idea of the new
work has already been shared at dispatch, and people have said it's a great
idea.

Francesca: I don't want to question the dispatch outcome. We could go back and
say maybe you don't need a BoF, you need a WG formation. But this is what the
community told me, that they would like a BoF on this topic.

Warren: Okay. It's just hard to get the BoF schedule, because we have an
official definition of a BoF and the process that happens.

Francesca: Before rob jumps in, I just want to say that I quickly read 2418, at
least the section on BoFs, and I don't find the part where it says this should
be submitted to the IESG, and the first round of discussion, and IAB to
discuss, etc. That's more of the process I was thinking about and that I
couldn't find described anywhere except for the usual time schedule by the
Secretariat.

Lars: It's a little bit of a spaghetti thing, the RFCs. There's 2815, which is
the IAB statement of work. That talks about architectural oversight and the
IAB's involvement in review in relation to new work. That's where it comes
from. But you're also right; the details of how we handle it are grown over the
decades and they're not really described anywhere. Those can be changed. But we
have to make sure we don't conflict with the spaghetti rules in RFCs, which
makes this complicated.

Francesca: I think John is next.

John: I just want to respond to Warren's comments, which sound to me a lot like
the process we have is bureaucracy and Lars was saying it's a spaghetti that's
grown over the decades and it's not helping. I'm very sympathetic to that point
of view but I don't think the right way to fix that is by ignoring it. If we
want to sweep it aside we should do the work to sweep it aside. That's all.

Francesca: Agreed. Rob?

Rob: My comment is that the IETF should be encouraging new work and not putting
roadblocks in the way or slowing it down. That's my concern here. It feels like
we're being bureaucratic to say if you make a decision at one IETF, you have to
wait four months for the next step, and then depending on the outcome of that
you might have to have another BoF to do a charter, and it ends up then being
eight months from the point where you sort of started work to when you can
formally get going. I know Warren has made the point that you can do this work
regardless, you don't have to wait, but you do then run the risk of the
community saying the IETF shouldn't be working on this and you spent months
wasting your time. I'm concerned that we should be trying to remove this
process we don't need in some cases, and streamlining and optimizing it. I'm
sympathetic to John's comments though, that I think if we bypass the existing
process that's going to cause us pain. Someone may appeal it just on point of
principle and we should try to look to fix that. I'm not sure whether we don't
just end up adding more spaghetti to the mix by changing it. Pragmatically, I
sort of come back to Warren's idea to hold a meeting to judge consensus, don't
call it a BoF but just to get input, and based on that meeting we'll decide if
we need to do a BoF at 113. That's what I'd do in the short term and then try
to fix it [overall].

Francesca: Thanks.

Warren: I don't know what else I can add other than what Rob said. I don't
think we should ignore the process, it just seems like in this case the process
is actively harming us getting work done. Maybe we can say we'll do this as an
experiment and we'll see how it works. That will inform what we do. Or we want
to try this as a virtual BoF and we'll see how it works and use that to change
the BoF process. I don't want us to be stuck that we can't have people get new
work done because of some rule that was written 30 years ago that no longer
makes sense.

Francesca: Just by reading quickly this section in 2418, except for the part
that says there can only be one or at most two, if the AD approves it, BoF on
the same topic, and they must be during the IETF week, I don't really see a
problem with having virtual BoFs outside of the IETF week. One slot at one IETF
plenary meeting, this is the one parenthesis I see. What practically leaves me
wondering how we do it is more how do we do the BoF review, how do we put it on
the telechat, does that also go to the IAB weekly call, how do we make sure the
usual process is followed? Rob, you said your concern is that some parts of the
community will feel like it's too much hassle to get the work started. Do you
mean if we allow for virtual BoFs?

Rob: The reverse. If we have a four month delay, it just seems like bureaucracy.

Francesca: I agree with that. I'm hearing mostly people wanting to do this. I
also hear people saying let's be careful about advertising it correctly. I
don't think that's an argument against doing it, I just think this is something
we should consider when we do approve a virtual BoF; has this got enough
visibility? Can we foresee this is going to fail because it doesn't have enough
community exposure? And then write that proposal having gone through some
dispatch meeting or list that can help with community exposure. In the end,
yes, it's usually a subjective decision that we usually make as to whether a
BoF can go on or not.

Lars: I suggest we actually do the work of defining this as an experiment.
There's enough in 2418 that we're a little bit conflicting with. I don't like
the idea of calling it a side meeting, because that's already a defined term
for something that isn't organized by the IETF and has no official standard,
and now we're calling something that we think is not that a side meeting. I'd
like to keep the label of BoF because it is a BoF and might make a BoF be
scheduled more flexibly. Francesca, if you want help with writing it up, I can
help you. We need to write something anyway to describe what we are doing.

Francesca: I would love some help, yes. I think I hear a lot of agreement about
maybe trying this, with a virtual BoF, let's be public about it and write it
down and mention it as an experiment, and also see the reaction. Ietf-announce
and ietf@ mailing lists sound good. Anything more?

Martin D: I agree with Warren; the important thing is to have the meeting, not
what we call it. But for clarity it would be better if we called it a BoF. If
for some reason RFC lawyers say we can't do that, we can do something else, but
the important thing is to have the meeting, not not do anything because of the
institutional stuff.

Francesca: I agree with that. So I heard some action points for me to start
this text about this experiment, and Lars, I will take your help, thank you
very much.

Alvaro: I think Lars said we needed maybe an experiment RFC. If this is just
one BoF we're going to try as an experiment, by the time we get feedback for an
RFC, it doesn't matter anymore. We need to tell the community but it might be
better to just send an email.

Francesca: That's what I was thinking, I didn't hear an RFC part.

Lars: It's 3933 which describes process experiments, written by John Klensin.
It basically requires us to publish an I-D, and then with a four week last call
to the community, explain what we're doing. It would basically be saying
there's this text in 2418 about what a BoF is, in these virtual times we want
to run an experiment with virtual BoFs. Here's what they are and here's how we
think they're going to work. That would be the content.

Francesca: Okay.

Alvaro: We've done experiments before, even the plenary experiment, where we
didn't do a draft.

Lars: Yeah, but that wasn't a process experiment.

Warren: That's why I was saying if we do this as an experiment, its proponents
are going to hear "the IETF is big and difficult and moves like an elephant. We
can maybe consider doing this by February and the meeting is in March, so you
might as well wait for 113." I don't know how they hear anything different.

Francesca: These proponents have already submitted a BoF request. It's in the
datatracker.

Lars: This experiment is unrelated to what I think we should be doing with this
particular proposal. For this proposal I'd be okay with finding a creative
solution. But it's already December and holiday break is coming, and March
doesn't feel so far off. It's questionable whether we can really save them a
lot of time by doing something creative. But for the future and for the general
case it would be nice to have a vessel available that lets us have a BoF
without a meeting.

Ben: It's interesting to remember that I think we've heard about virtual BoFs
having happened in the past, five-ish years ago or more. It would be
interesting to know what the past IESG was thinking and if they considered this
question at the time. I don't expect we can answer that question.

Warren: We've had a bunch of previous instances where people basically had a
bar BoF, that was well announced, and anybody who might possibly care about it
showed up, there was a discussion in the bar, and at the end of it people
walked out and said this seems good, someone is going to charter a WG and let's
move on. I don't see how that's different to having a meeting however you call
it. Keep in mind a bar BoF isn't a BoF. But I don't see how having a meeting,
however you call it, and at the end everyone wants to keep discussing it, would
be different.

Martin D: Ultimately as the IESG we can charter whatever weant and the BoF is a
tool to gauge community consensus and interest. It's weird that we've written
this standard we have to follow. If we don't find it useful, we should get it
out of the way. The BoF exists for ADs to make intelligent decisions about
chartering work. And as Warren points out, sometimes we don't need that because
there are other channels and that's fine too.

Mirja: I think Martin just said exactly what I wanted to. There was a question
about what a previous IESG did when they had a virtual BoF and I think it was
exactly what Martin summarized. The BoF serves for the ADs to figure out if a
WG should form, so we try to do the best setup that helps us form that
decision. To Warren's point, i think we shouldn't just have a side meeting, it
should be official so people know about it and they can join. Usually that's
what we call a BoF.

Lars: The other thing I think was done in the past is that various area groups
had meetings that were dedicated to hosting a discussion. That might be better
than having a side meeting. So you'd have ART area schedule an interim and
schedule it there. Then it isn't some side meeting which is confusing, it's an
interim meeting of something existing.

Francesca: For this proposal in particular, the thing is it went through
dispatch and it was dispatched. You could put it as the only item on the agenda
for an ART [interim] meeting, but I think a BoF would reach more people just
because it has the name BoF. The community knows what to expect when a BoF is
scheduled. When it's an ART or Dispatch meeting, people might not pay attention
to the agenda and they might not show up.

Lars: I agree with you. In the long term it would be nice to have a way to
schedule a BoF more flexibly. For this particular proposal, it might be your
way out to give them a slot before 113.

Francesca: Okay. I still feel like we are going around what "should be done."
We can't have a BoF so let's have a side meeting that is basically a BoF.

Warren: I really liked Lars's idea of an area interim meeting. I do agree,
people do understand what a BoF is and it gets more interest, but it doesn't
have to. I'd be perfectly happy to send email to all of my WGs explaining
there's going to be this thing that will largely behave like a BoF, so show up
and let's discuss stuff. I don't really think anyone is going to lose their
cool over that.

Francesca: This would make my life easier, because I wouldn't have to find
chairs for the BoF. I'm not opposing this. Just thinking it's strange to not
use something we have. But I definitely understand the reason and I don't want
to wait another six to eight weeks, or tell the proponents we have to wait
eight weeks just because of the process. I agree with that. I also agree with
what Mirja is saying, let's just call it a BoF then. I also think the IESG
would have to approve the BoF and the IAB would have to approve the BoF, which
is 2-3 weeks delay, and 2-3 weeks to be scheduled and announced. To me maybe
there is enough time to announce this experiment and at the same time do the
process to approve this particular BoF. I don't expect there will be a big
reaction from the IETF community that this will be a bad idea.

Lars: Do you have what you wanted? Or more than you wanted?

Francesca: I think I have what I want. We haven't really gotten to a conclusion
about what to do with this particular BoF. Warren, where did you take this text
from that you posted in the chat?

Warren: 5434. That was just a very quick copy and paste; it's all over the
place.

Francesca: I've been trying to find all the process documents about BoFs. Some
of this text I found, is it really valid if it's outside of the IETF week,
there is no important meeting dates calendar, etc. Anyway, I think we can stop
here. Thank you all for the discussion and I think this was useful.

Amy: I'd sort of heard an action item for Francesca to draft text on a virtual
BoF experiment. Is that still a thing you're going to do?

Francesca: Yes. And I should also have an action point to bring this BoF
proposal to either the IESG for the next telechat or we agree with the
proponents to do something different and not go through the BoF official name.
I'll be back for that.

6.3 [IANA #1217617] Designated experts for RFC-ietf-quic-http (Hypertext
Transfer Protocol Version 3 (HTTP/3))(http3-parameters) (Zahed Sarker)

Amy: Zahed has identified Mike Bishop and Alan Frindell as the designated
experts for these registries. Is there any objection to approving them as
experts? Okay, hearing no objection, so they are approved as experts and we'll
send the official note to IANA.

6.4 [IANA #1218411] Designated experts for RFC 6931, (Additional XML Security
Uniform Resource Identifiers (URIs)) (IANA)

Amy: This is a new action item for Roman.

6.5 An IESG statement on "Handling Ballot Positions" (Warren Kumari)

Warren: I have text. It's basically the original blog post and/or very similar
to the original thing we discussed as an IESG statement. I've changed the tone
and the wording and things so that it is more IESG statement-y and less
conversational. I think people were fairly close to being happy with it as it
was before, so hopefully people are even more happy now. It's hopefully close
to being able to be published. People should read it and provide comments and
feedback. There are a few places where there are dashes, where I need to find
the ideal word, and I don't know what it is. Things like what is the purpose of
the IESG review?To make sure there are no conflicts and to make the document
better. But better wording around that would be helpful. I think the summary
is, I think this is close to done and would appreciate some review so we can
move it along soon. Or maybe, unless there are any objections by a certain
date, let's assume it's good and publish it.

Ben: I opened the document and got halfway through before the meeting. I'll try
to finish looking today.

Warren: Thank you. I haven't seen your bits yet but what did you think so far?

Ben: It's probably okay. There are some playful bits that are probably okay but
may not be what everybody expects in an IESG statement.

Warren: I tried to tone down some of it but I was also trying to make sure that
people are actually willing to read it. RFC or draft authors are willing to
read it and it doesn't just look like a boring process document.

Ben: I agree, we don't want a dry, formal document here.

Warren: I only see a comment from Eric and I'm of course happy to take more
feedback. Thank you.

Amy: Greg Wood might be able to help you with the words you're looking for.

Warren: Thank you. Greg has already done a bunch of really good editing and he
turned it into a blog post. Greg, please, any other changes would be great too.
And not to put you on the spot, but feel free to read it and make edits as well.

Amy: We'll take a look and see if we can come up with any of those words you're
looking for. So we have a next step there.

6.6 IETF 113 Important Dates (Secretariat)

Amy: We added this, and Liz has put together a draft of all the 113 important
dates. We know some of them are still up in the air while we figure out if it's
an online meeting or not.

Liz: These are the standard important dates; the main question for you all is
the BoF dates. It seems like there's general agreement that the dates
themselves are fine but we might want to make some changes to the text of these
dates? That's actually something I can't change myself but I can talk to Robert
about incorporating some of these changes to the text.

Lars: Those are not high-level comments, I just realized we sometimes say
things slightly differently and I wasn't clear why they're different. But if it
can't be changed, that's fine.

Liz: I think it's because they've been added at different times; many of these
have been the same for years on end, but a few of these like the BOF dates have
been put in more recently, so they're artifacts from different times.

Lars: That's fine. Let's focus on the actual dates rather than the text. For
the first two, we're still waiting for scheduling to open, which we'll know
when the venue negotiations have settled. The BoF deadlines look fine to me.

Liz: Great. Anyone else have any other questions, comments, changes? Okay, I'll
go ahead and publish these. Thanks.

6.7 [IANA #1218369] renewing early allocation for
draft-ietf-bess-mvpn-evpn-aggregation-label (IANA)

Amy: This early allocation is set to expire in January. Martin, did you want to
speak to this document and where it is in the process?

Martin V: It's in my queue but I don't expect it to reach IANA by January. It
should be on a telechat in the course of January so it's pretty soon.

Amy: Any objection to approving the extension for this early allocation? I'm
hearing no objection, so we'll call this approved and send that note to IANA.

6.9 [IANA #1217716] Designated experts for RFC 9158 (SMI Security for PKIX CRMF
      Registration Controls for Alternate Certificate Formats)(smi-numbers)
(Roman Danyliw)

Amy: Roman has identified Russ Housley as the expert for this registry. Is
there any objection to naming Russ as this expert? I'm hearing no objection, so
Russ is approved and we'll send note to IANA.

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

Eric V: Some news about Barbara Stark; she has retired from AT&T and she is
also retiring as chair for DNSSD and HOMENET. She has already been replaced by
others. That's all.

Lars: I have one quick thing; we might get a BoF proposal based on the
gendispatch discussion at 112 about term limits for leadership positions. I got
an email from some folks and told them we didn't have dates yet, but they could
expect them to be sometime in January. I haven't gotten any actual proposal yet
though. I'm guessing that's something we don't want to assign an IAB shepherd
to because it's about term limits for leadership and having someone help them
could be misconstrued as taking influence. And these people are very
experienced so I don't expect much need for help. You'll see it when it hits
the datatracker, if it comes.

Martin D: Is that proposal just for the I* or for WG chairs as well?

Lars: Based on the gendispatch discussion, it's just for Nomcom selected
positions. It's basically giving the Nomcom guidance about whether they should
pay attention to how many times someone has been elected to a leadership
position in sequence, or maybe overall. It's not quite clear but those are some
of the things that were discussed with gendispatch.

6.8. Executive Session