Narrative Minutes interim-2022-iesg-09 2022-04-21 14:00
narrative-minutes-interim-2022-iesg-09-202204211400-00

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

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Erik Kline (Aalyria Technologies) / Internet 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
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the official minutes of the April 7
teleconference being approved? I'm hearing no objection, so we will post those
in the archive.

Andrew: While I probably don't object to them, I couldn't read them because
they had a password.

Cindy: Your regular Datatracker password should work; if it doesn't, there's
something else wrong and we can fix it offline.

Andrew: Okay, I'll ping you later.

Cindy: I did send the final narrative minutes and I didn't get any comments, so
unless there's an objection it looks like the final narrative minutes from
April 7 are approved. Thank you.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Murray Kucherawy to find designated experts for RFC 9208, "IMAP
       QUOTA Extension" [IANA #1229081].

Amy: Murray is away today.

     o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
       [IANA #1229681].

Amy: Roman also couldn't be here today; this is a new action item for him.

   * OPEN ACTION ITEMS

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

Amy: This is on hold and we'll look at it again in June or July.

     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.

Amy: This was in progress last time and when Murray gets back he can continue
that.

     o Francesca Palombini to follow up on the public archive of AUTH48
       conversations.

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

     o Murray Kucherawy to review the media type registration request from
       standards organization CWL Project.

Amy: He has done that and he sent a writeup which is on the agenda as a
management item today.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-bier-bar-ipa-12  - IETF stream
   BIER Underlay Path Calculation Algorithm and Constraints (Proposed
   Standard)
   Token: Alvaro Retana

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

Alvaro: I don't think so. There are a couple of emails out on the solutions.
Paul, unless you want to talk about the IANA part today? But I think we're
converging on that part, I don't know if you agree.

Paul: I think we are good.

Alvaro: Okay thanks. We're going to require a revised ID.

 o draft-ietf-sidrops-rpki-has-no-identity-07  - IETF stream
   The I in RPKI does not stand for Identity (Proposed Standard)
   Token: Warren Kumari

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

Warren: Excellent. I did have a discussion with the authors on the document
track and while Standards isn't perfect, it's better than any of the others so
we're sticking with Standards. Thank you very much.

Amy: I have no notes, so this is just going straight to Approved, Announcement
to be Sent.

Warren: Thank you.

 o draft-ietf-cbor-file-magic-11  - IETF stream
   On storing CBOR encoded items on stable storage (Proposed Standard)
   Token: Francesca Palombini

Amy: We do have a Discuss here; unfortunately Roman isn't here to discuss it
with you. Do we need any discussion today?

Francesca: No, I don't think so. The authors have already answered and they're
preparing a new version of it so this will go into Revised ID Needed.

Amy: Thanks; this is staying in IESG Evaluation with Revised ID Needed.

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-lisp-vendor-lcaf-10  - IETF stream
   Vendor Specific LISP Canonical Address Format (LCAF) (Experimental)
   Token: Alvaro Retana

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

Alvaro: Can you please put this in AD Followup?

Amy: Certainly.

 o draft-ietf-raw-ldacs-10  - IETF stream
   L-band Digital Aeronautical Communications System (LDACS)
   (Informational)
   Token: John Scudder

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

John: Let me just cover it quickly. In light of the sea of red, and the fact
that some of them will be easier to resolve and some might be impossible to
resolve, and we've got another way forward anyway with the independent
submission stream, I'm going to work with the authors to move it to independent
submission. Apologies to you all and to the authors for not having thought of
that before I put it on the agenda and wasted people's time, although it wasn't
a total waste because there was a lot of very helpful review. Thank you for
that and thank you to the authors for working constructively to address those.
So it'll be moving to the ISE stream.

Amy: It needs a substate before that happens so I'll just put that in AD
Followup and let you work on moving it.

John: Sounds good, and since this is the first one I will have moved from IETF
stream to ISE stream, I've got to work with Elliot since it doesn't go without
saying that he will accept it, but any advice offline would be appreciated.

Amy: It's not common but it has happened in the past, so maybe folks who have
done it can advise you.

Lars: Can we take a second? It's obviously up to John whether he wants to move
it to the ISE or not, but we have published similar docs on the IETF stream in
the past, and even after the streams got created. In TCP, for example, we've
described a number of proprietary industrial control algorithms or queuing
algorithms in other TSV groups on the informational stream, for the information
of the IETF community. This is maybe a little different because it's surveying
someone else's architecture, but it's not that different that I personally
think it needs to be absolutely moved to the independent stream. Yes, maybe it
didn't get enough review and that's probably an issue, but I don't necessarily
think documents like that need to go to the independent stream.

Andrew: My issue here is that in this particular case even reviewing half the
stuff is difficult because you've got paywalls in front of half of the stuff.
You have a document where I'm not convinced half the WG could have even
reviewed it because if you don't have access to the stuff to review…

Lars: Yes, I get that. For example with the experimental congestion control
algorithm, we can't review the source code of the Windows kernel either. We
have to trust that what the authors are describing is accurate. This seems
similar.

Alvaro: I'm not sure what RFC that was, but was that before we changed that
everything needs to have consensus?

Lars: I think it was after but I need to check. It was the original cubic and
the compound piece is for Microsoft. If you want to keep discussing, I'll take
a minute to look it up.

Mirja: I don't want to comment on this document but for the congestion control
one there was no stable reference. There was no other organization which had
documented it, so there was a clear purpose there.

Zahed: For the congestion control that was one of the biggest reasons that we
wanted to work on it and push it through, because there was no other way of
knowing anything. So we at least have something in the IETF that people can
refer to. This is not the case [here]; it talks about use cases and
requirements and this is all about this LDAC thing, not about what is in it. If
I could, I would propose to talk with the authors to describe LDAC and what it
means to the IETF, and RAW could be a big part of this document and we could
get it through. But when you have statements like LDAC is the pioneer and most
important part of FCI, do we want to have a consensus call on that? I don't
know. That was the complex ask I was doing with myself. So I think this is a
good document to have, but you decide, John.

John: Let me slightly rephrase my previous comment. It seems to me like most of
the Discusses, it's possible to work through them. The question is going to be
two things. One, at least Alvaro's and to some extent Andrew's Discusses are
fundamental process things that can't really be fixed by the authors at all. So
I don't feel great about letting them twist while we work through that. I'm not
sure that we need to elevate that conversation to the telechat level anyway, to
make it a blocking conversation for their document. I'll talk to them again and
maybe the impression I got last time was wrong, but basically the impression I
have from the authors is that they're fairly pragmatic and we'd just like to
get their document stably published. As some of you have pointed out, that's
what the ISE stream is for. We can all continue to work on getting it into a
different form that everyone perceives to be appropriately shaped to fit into
the WG charter, IETF stream and so on, or everyone can do quite a bit less work
and put it into the ISE stream. That's the conversation I will have with the
authors; I suspect they'll say 5x the work and maybe we get a publication in
the IETF stream, or 1x the work and I get a publication in the ISE stream and
either way, it's a publication. So I think it's just a pragmatic choice to
switch it to ISE.

Éric V: You need to be very careful to keep the authors and this team of people
still involved with the IETF. We need to get new work at the IETF and this is
maybe a first step to get new work. We need to be cautious there as well.

John: Right. I would say they have an extremely constructive attitude about
this whole thing. They did have a quite similar reaction to one we saw a few
months ago from another author who felt suddenly attacked, because they hadn't
gone through a lot of last calls or being on the IESG agenda and then suddenly
having this influx of what feels like harsh criticism. I think they understand
what the process is that's going on and it's okay. But yes, I think we need to
keep that in mind in future for other new authors as well. I know we put all
kinds of disclaimers at the top but the lesson I'm taking away is that when
working with new authors, it may be valuable to have a call with them before
putting their document on the agenda just to say here's what you may expect.
Any further discussion on this one?

Rob: Not on this document specifically, but I do think it would be helpful if
we could make the rules easier for people to understand. Even in the discussion
between the IESG about whether this should or shouldn't be allowed, it didn't
seem like there was definitely consensus there and if we can't really know
what's allowed or not, how does anyone in the community have any chance of
doing that? So I think that if what's in 2026 has evolved and changed, we
should somehow be sharing that with the community, whether that's an update to
2026 or some other mechanism, I don't know. I don't like it being ambiguous,
personally

John. I absolutely agree. I started that mail thread but I think I am going to
propose a topic for the retreat. Any opinions on whether that should be IESG or
IESG + IAB?

Zahed: You did a very good job sending out this email thread because this is
confusing and Rob, you read my mind. This is kind of orthogonal to this
document but we need to do something to make sure everyone can understand what
we're talking about.

John: I think we can move on.

 o draft-ietf-quic-applicability-16  - IETF stream
   Applicability of the QUIC Transport Protocol (Informational)
   Token: Zaheduzzaman Sarker

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

Éric V: By the way, you need to change the consensus setting, right? It's
currently Unknown.

Zahed: Not on this one, but I think that is one thing I missed somewhere and I
was questioning myself where and how I missed it. I don't know if I need to
change the boilerplate consensus in the process of putting it in a telechat or
in IETF Last Call or when I should do it.

Amy: I don't actually know when that happens for ADs, so maybe someone can
answer when you click the box or change the consensus to Yes.

Francesca: I think most of the time the WG chairs or the shepherd do it. I've
never had to do it myself so far.

Amy: Great, nobody knows who's doing what! Whenever it comes up as Unknown, we
will change it for you.

Alvaro: Didn't we change it so that the newer documents have it set to Yes by
default? I think it's only a problem with older documents that have been around
for a while.

Amy: I know that's true for protocol action documents. I don't know if that's
true for document action documents; maybe.

John: The LDACS one came up with it as No, as several people pointed out, and I
manually switched it to Yes after those comments.

Alvaro: The other question is that with 8789, that everything requires
consensus; does it even make sense to have an option?

Francesca: We do have it in the shepherd writeup, right? I always assimilated
that field with the shepherd writeup where the shepherd has to discuss the WG
consensus around the document.

Alvaro: I take that as them explaining why there is consensus. Otherwise we
should never see a document that [is Unknown].

Zahed: I'm with Alvaro, I was thinking this is by default IETF consensus.

Éric V: At least it should be by default after the IETF Last Call, though.

John: It seems like a historical artifact that that thing exists; Alvaro is
implying that it came from a time when the IESG would also advance documents
that didn't have consensus.

Zahed: So about this one, can I change it now?

Amy: We'll change it for you if you don't. It's part of the process that
anything coming through us with a consensus Unknown will get changed to Yes,
unless we're otherwise instructed. So it looks like this document is approved.
I have no notes in the tracker, do we need any?

Zahed: I think there are some editorial changes and typos. I suspect the
authors will address that; maybe AD Followup or Revised ID Needed?

Amy: Either one is fine; if you feel very strongly it's going to require a
Revised ID that's probably the one to go with.

Zahed: For this one I think we can do AD Followup.

 o draft-ietf-quic-manageability-16  - IETF stream
   Manageability of the QUIC Transport Protocol (Informational)
   Token: Zaheduzzaman Sarker

Amy: There are no Discusses in the tracker, so unless there's an objection now,
this one is approved. Does this also need a revision?

Zahed: I think this will need a Revised ID; Lars is having some discussions
about the versioning. Lars, do you feel like we are reaching a conclusion on
that thread?

Lars: I Think there will be. Christian replied also, and I haven't heard from
the authors yet; I think there might be an update coming to address that IANA
thing. I think it's totally misleading. Maybe Mirja, who's one of the authors
on the call, has a feeling here too.

Mirja: We'll revise both of them together anyway so that's fine. I'm happy to
take in whatever people decide.

Zahed: Okay, that's great. So we heard from the authors, the revised ID will be
fine.

Éric V: By the way Mirja, it was a good job; very clear and useful.
Congratulations.

Mirja: I'm just a contributor here, but thanks.

Éric V: Well, Brian is not here.

Mirja: There were also a lot of contributors in the WG, but I'm happy to hear
that it's helpful.

Zahed: Thanks for working on it.

 o draft-ietf-v6ops-transition-comparison-03  - IETF stream
   Pros and Cons of IPv6 Transition Technologies for IPv4aaS
   (Informational)
   Token: Warren Kumari

Amy: I have a couple of Discusses; do we have to discuss these today?

Warren: Just quickly. I believe Éric thinks one is going to be easy for the
authors to address and I think they might have responded already. What I was
wondering is Roman, have you heard from the authors at all?

Amy: Roman is not on the call today.

Warren: In that case, never mind. They'll figure it out.

Amy: It sounds like this is going to get a Revised ID?

Warren: Yep.

 o draft-ietf-dots-multihoming-12  - IETF stream
   Multi-homing Deployment Considerations for
   Distributed-Denial-of-Service Open Threat Signaling (DOTS)
   (Informational)
   Token: Roman Danyliw

Amy: We'll change the Consensus to Yes here for Roman. I have one Discuss from
version 11; do we need to discuss this today? Erik, any feeling there?

Erik K: I saw that version 12 showed up but I have not yet reviewed it. I'm
happy to clarify on the list; I don't think I'm asking for any huge alteration
of the text, I just wanted to point out that must use 6724 is not actually
sufficient in these cases; maybe they could just drop some useful warnings for
a reader who's not really experienced with multihoming ipv6 and all of the joy
that will follow from attempting to do something like that.

Amy: I'm going to put this in AD Followup so when Roman is back he can take a
look and help out with that. We'll let him sort that out with you.

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-briscoe-docsis-q-protection-00
   IETF conflict review for draft-briscoe-docsis-q-protection
     draft-briscoe-docsis-q-protection-03
     The DOCSIS(r) Queue Protection Algorithm to Preserve Low Latency
   (ISE: Informational)
   Token: Martin Duke

Amy: I have no Discusses for this conflict review, so unless there's an
objection now it looks like the message in the Datatracker is the correct one
to go back to the ISE. Hearing no objection to this conflict review message, so
we will have this sent on Monday.

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Warren: On the previous call there was some discussion on the interaction with
liaisons and making sure liaisons have the ability to participate fully, and
also recently some discussion on the approval process for liaison statements.
The way it currently works is WG chairs and others can send liaisons without
real review and approval, and some discussion on making that process better
understood and making sure there are some checks and balances and not just any
WG chair can send anything to anyone. That's the high level summary.

Lars: There's a small group Mirja is getting together that's going to discuss
it a little bit more, and I'm on it since obviously how liaisons get sent
matters to the IESG. I'm guessing I'll report back to you guys when there's a
proposal; at the moment, it looks like there will be an approval step required
if WG chairs want to send a liaison and it's probably going to be the AD. There
are some details on who can expedite this or overwrite that if they're not
responsive or something. I guess we'll hear at some point from that small group
and there's also RFC 4052 that talks about how that is handled. It's an older
RFC and it might need a revision; if that is the case, you'll definitely see it.

Mirja: Today as described in 4052, approval is required but it's easy to
circumvent in the tooling. So one question is about how this approval process
in general works, but also about how it's realized in the tooling.

Warren: Currently the datatracker has a box saying "obtained prior approval"
and it's unclear to WG participants and ADs and anyone else what that actually
means, which I think is what Mirja was referring to. At the high level, there's
discussion happening, and once more happens, we'll tell you about it.

6. Management issues

6.1 Follow Up on the Public Archive of AUTH48 Conversations (Francesca
Palombini)

Francesca: I just sent an email to the IESG list and posted a Google document
I've been working on. My goal for today was to summarize the threads that have
been happening on different mailing lists. It took some time. Looking on the
mail archive there were 365 mails but these are also duplicates, because most
people sent to more than one mail list. Maybe we can just go through the
document quickly and then we can discuss the summary and way forward. I
identified the questions raised and these are my summaries, and I included
links to the mails I summarized so people can go and read the details if they
want. These five questions came up. First is what about github, would that be
archived and if so how? I can also say what I think the answer is right now.
For Github I think that's for later, this is not part of this proposal. Someone
brought up why not make this a fixed term experiment and bring the result to
RSWG as a policy proposal? There was some mixed reaction to that and others
were saying no, the RSWG can tweak this when they get to power and we don't
need to wait. Reaction to that was running an experiment is fine but declaring
a policy isn't for the IESG and other stream managers. RSWG will be operational
soon, we should wait for them. Third question, why not CC the WG mailing list
instead of creating this new AUTH48 archive? And trying to make this a send
only address which does not receive emails, so if people try to reply to it,
they could still reply to authors or RFC editors directly but they can do that
now as well. There was a lot of negative reaction to this suggestion. Someone
else suggested there should be a separate AUTH48 list for each WG which also
people responded to negatively. Others didn't care about one per WG or one for
all WGs as long as it cuts the noise on the WG list I actually want to follow.
Someone asked me what's the difference between having one list per WG or one
list and theoretically there's not much of a difference. The response was why
should a lot of people set up mail filters when it would be mirroring
functionalities we already do on the IETF side, setting up several mail lists
and making it possible to subscribe to different lists. I did check with Robert
and he thinks this is a lot more work to set up one archival list per WG than
one list for all AUTH48 conversations. Plus he brought up another good point
which is that it would also require more work from the RPC because they
wouldn't just need to add one mail list, they would have to change the CC based
on the WG. Also there was some positive feedback to this proposal, like it
keeps the authors in check and avoids the "AUTH48 black hole", and allows
someone to see all AUTH48 exchanges. Again, my response to that would be that
you can still do that with filtering. The fourth question was why are we
discussing a new list and not something like an issue tracker? The answer for
me is that this is a simple solution that doesn't require too much work from
the tools team. Another question is what would be the responsibilities and
accountabilities changes; are we requesting more people to check by setting
this up as transparent and allowing people to subscribe? The response to that
from someone else was yes, we let people check, we are not requesting anyone to
check but people who want to are able to, and this should be viewed as a small
additional safety check to the existing mechanisms, which is right now the
responsible AD and the WG chairs and shepherd, which are the people who are
supposed to check right now. These were the questions.

Francesca: Then we got some feedback that was not really questions. I tried to
summarize it. We had several people say this seems reasonable, other people
saying this seems reasonable but with some feedback and counter proposals, some
of which was in the questions above, and the other position was I'm not against
this, but I would defer it until the RSWG is in place. There were negative
reactions to that, why should we stall something that we could be doing right
now? Lars commented if this is supposed to be in the RSWG purview and the
response was that if we ask to change RPC processes, then yes it is under the
RSWG purview, and the public debate during AUTH48 is a policy issue. The way we
deal with that, are we doing mailing lists or issue management, the IESG and
other stream managers can have a say on it but the policies around it should be
in the purview of RSWG. Even there, it wasn't a very strong opinion on either
side, but some people said RSWG should be able to take care of it and others
said they should not be. Some people would be concerned that we would be
pushing too much on RSWG. It's quite split 50/50 and you can look at the mails
in more detail if you want to see what people are saying.

Francesca: There was other feedback I've put into this separate section because
it's not really about this proposal itself but it's spun from it. Things to
think about, let's say. One was to make sure authors can opt out, which I agree
with. Another about being informed in real time; this was not how I had
envisioned it. I had thought this was a mail list for archival purposes, not
necessarily in real time; I wouldn't need to subscribe. I can see how people
would want to subscribe for their own archival reasons but people do see an
interest in being able to follow up and make sure that mistakes are spotted or
that you can see what's happening in real time. Another feedback was in the
bigger picture, there are two different concerns about guaranteeing no ill will
proper review, to avoid changes that are too big, and the other is dishonest
changes that are made during AUTH48. He was saying we should focus on the first
and make sure all AUTH48 changes are properly reviewed and he suggested two
different ways of doing this. He went one step further of our proposal and
suggested some interesting experiments like announcing on the Last Call mailing
list when a document goes into AUTH48, with a link that allows you to subscribe
to the AUTH48 list for that list. Another option would be to add an
announcement to the Last Call mailing list with a link to a diff to the
document before it went into AUTH48 and after it exits AUTH48. This would be a
notice, not a request for comments on the changes that happened during AUTH48,
and the only reason to have that would be so that if people care they can go
in, look at the idff, and possibly follow the existing processes like appeals
or bring it up to the IESG, etc, to say these changes are too big and shouldn't
have happened. This would be an additional step to make sure the AUTH48 changes
are properly reviewed.

Éric V: I'm a little surprised because the auth in AUTH48 is for authors, no?

Francesca: Yes; this would be after AUTH48. I'm explaining this proposal from
John which focuses on a different thing than what I had brought up. It's an
interesting idea we should probably discuss, not necessarily now.

Mirja: It seems like some people want to solve a different problem, which I
don't think is a problem, which is that they want to be involved in the review
of AUTH48 and I think that's a bad idea. The problem we originally wanted to
solve was just providing more transparency so we can look it up later.

Francesca: Exactly. This is why I put it into other feedback. I don't have a
strong opinion if it's a good idea or a bad idea but it's not related to this
proposal. It's something that spun out of this proposal we can discuss if we
want. Lars responded to that and said what you just said, Mirja, that the IESG
proposal is not motivated by dishonesty or improper reviews, just to add
transparency to the process. Thank you Lars for doing that. And John replied to
that saying he understands, this is not a proposal, but these are questions
that will most likely need to be addressed and can be done in conjunction with
RSWG.

Lars: On this one, if that happens, I will push back. Because getting the
community to participate in the AUTH48 reviews is actually changing the
standards process; there's no consensus evaluation at that time anymore. The AD
is supposed to pull the document back into the consensus part of the
organization if changes come up that aren't editorial. The community might have
an interest in seeing that play out but there's no discussion phase. If they
want to push back that's not a RSWG thing either because it's not RFC series
policy.

Francesca: I think maybe I misrepresented John's view. But in his email, it was
pretty clear that this is really not a request for comments or another Last
Call. he did say send it to the last call mail list, probably because that's
what he looks at and he assumes that's where other people look for
announcements on documents. But this is not supposed to be seen as a last call,
just an announcement that this document has finished AUTH48 and this is the
diff between pre-AUTH48 and post-AUTH48 and that's it. And like a timeline when
it will be published. It lets people who have interest in looking at it use the
existing processes like appeals to say i don't think this went through enough
careful consideration from the responsible AD or whoever is needed to approve
it.

Lars: I get it. Maybe we shouldn't be having this discussion now but I think
that's a terrible idea. We've never had a case where somebody appealed because
of something bad that happened in AUTH48 and creating a delay for all RFCs just
on the off chance….they can already appeal it after it's published and say hey,
I looked at the diff and there's clearly something fishy here.

Francesca: That's a valid point.

Warren: It also seems like if you're putting this step in you're basically
telling people 'now you're supposed to review it and raise any major concerns
you have before we publish it' so basically you've asked people to get involved
in doing the editorial review and re-raised all the concerns they were unhappy
with last time. If anybody reads it at all; i suspect nobody would pay
attention, but the people who do might be exactly the sort of people who would
fuss for very little reason.

Francesca: Okay. So that was one of the feedbacks and then another one was
raised by Elliot; we should consider transparency when a draft is not
published. Elliot asked if the IESG had comments about that. This is also a
wider topic.

Lars: Can you say what he means by that? Because either it's not published
because a WG drops it or it's not published because the IESG kills it somehow
and it doesn't get the ballot that it needs, and all of that is public already.

Francesca: Basically if the IESG has suggestions about how, for example, a WG
that drops a document, what the WG should do with regard to that document so it
stays in the history, in a tombstone document or something to improve
transparency about why that document had been dropped.

Lars: I would argue that we have a mail archive and if somebody is interested
they should look at the email, which is easy.

Francesca: He also mentioned that it doesn't happen too often and he can think
of like four cases that go back 20 years or so. He thinks this will be valuable
and asked the IESG to discuss it. I also had a section on Side Conversations. I
didn't copy paste all the emails, just the ones I thought were relevant to the
conversation to make it easier to go back and see what people were saying.
There were a number of side conversations that started from this thread and I
pasted the initial threads. For example, the use of Git as an AUTH48 tool
started a side discussion; we don't need to go into details. The second side
conversation was about different rendering formats for RFCs and who's
responsible for checking those. There was quite a long thread about explaining
the RFC process that also created a diagram and song lyrics. So if you want to
read that you can. A side discussion about what is in purview for the RSWG; i
think that's interesting and will give some insight into what might happen with
that. And another one was this thread about the long time that it takes for
AUTH48 and what can the IESG do about it. I don't know if we want to bring this
as a retreat topic but there it is.

Lars: Since we have an awesome  list here that we should do something with, can
you add this side conversation that people said IANA should look at similar
mechanisms to provide transparency for the communication they have with the
authors. This might be something we want to discuss with IANA but it's not
something that stops us from doing something with AUTH48.

Francesca: Yes, I think I saw something about that. IANA also has started CCing
the WG when they email experts; I think that was something that was discussed
and decided and has improved transparency of communication between IANA and
experts, at least, that was private before. That's a good point. For a summary,
in general I gathered mostly positive reactions with additional thoughts and
feedback to consider like we went over before. This should be discussed with
the tools team and have a clear view of what's the best way to do it. There are
a few things here we should respond to as the IESG so we don't leave them
hanging; but I'm not saying we should do that right now. Given the positive
feedback, the main question is if this effort should be delayed long enough for
the RSWG to discuss it? I think they would just discuss this and then send a
suggestion to the IESG to do it or not do it. Just to have a concrete action
list, we have these three options: set up the mailing list as we proposed, and
RSWG can tweak as needed if they are set up; or, we do the same but run it as
an experiment which is kind of a middle step; or, we wait for the RSWG to be up
and running and bring this as one of their items and wait for their feedback
before setting up. I assume the response will be yes, given the positive
feedback here, so this would end up as just a delay.

Mirja: If we bring it to the RSWG there's an assumption there will be some
policy here, because that's the only thing they are chartered for. Right? So
they are not chartered for making any kind of detailed technical discussions.
If anything they would write a policy document and then it would be published
as an RFC and then it can be implemented, so it's a longer process.

Francesca: Yes. The feedback was split as to whether it was in the purview of
RSWG or not. Someone needs to call it.

Jay: I was going to say the same thing as Mirja, that I don't think the RSWG
can tweak anything. That does leave the question of who can tweak things
though, but I'm still thinking through that.

Francesca: In this case, I think the stream managers are the ones who will then
decide.

Jay: You're right, I agree.

Lars: I was pretty outspoken about this and I've changed my mind now. I don't
think this is for the RSWG because it's not a policy for the series. I think
it's something under control of the stream approving bodies, which is us for
the IETF stream and everybody else. We should just do this, meaning we should
do option 1 in my opinion. I don't see the need to run this as an experiment.
If it fails, and I don't really see how it can fail, we can always stop doing
it even if it's not an experiment.

Francesca: The interest of doing it as an experiment is to have someone who's
looking at how it's working and set a timeline to say here's what's happening
with that thing we started a while ago. I don't see that as a bad thing to have
it as an experiment.

Lars: What's the success criteria?

Francesca: That, for example, people don't disrupt the AUTH48 process too much.
Another thing would be to get feedback from the RPC and RFC editors in general
to tell us if it worked or not, or see how many authors opt out.

Lars: Since we're increasing transparency, we can't really do this as an
experiment and then say, that didn't work, let's become less transparent again.
if it creates disruption for the RPC we have to deal with it some other way.

Francesca: it could increase transparency but make it worse in other ways.

Lars: And these other ways we then need to deal with. Other than hiding the
emails again. We should certainly talk to the RPC about how this works but I
don't think it needs to be an experiment. In the best case nothing will happen;
emails will get sent that will occasionally be found in the mail archive and
that's basically it. If people really start to have discussions then we need to
make the lists read only.

Zahed: I can see doing an experiment to get a pilot project going to get the
tooling done. Then we cover the corner cases. Otherwise I don't see a need for
an experiment.

Lars: The tooling is one mailing list that gets CCed. It's actually an RPC
tooling thing and knowing the state of their tooling they probably do it
manually.

Francesca: John, do you want to expand on how a pilot project is different from
an experiment?

John: A pilot project doesn't have any formal or quasi formal standing. An
experiment does. I think Lars's question about the success criteria indicates
that. If you do an experiment, you're expected to report out whether you
succeeded or not and you are expected to make a decision about whether to
continue or not. Doing a pilot project is just saying we need to get some
tooling going and we don't want to roll it out to everyone right away so we're
going to try it and see. It's strictly an internal mechanical thing.

Francesca: Okay. So a pilot project would go into point 1.

John: Right.

Zahed: I agree with John's definition of pilot project instead of experiment
and we may need a pilot to get things up and running. That's it.

Mirja: Maybe I'm spending too much time on the IAB but the policy viewpoint
here is that i think 1 is the right thing to do, but the only reason for me to
go for 2 is because some people might complain about 1 because people are
overstepping their responsibilities or whatever; the usual complaints. If you
want to circumvent those complaints you might claim it as an experiment. But I
think 1 is still the right thing to do.

Rob: My concern with that is does that mean that everything the IESG does has
to be labeled as an experiment because we're worried about overstepping our
mark? If so, that becomes extra bureaucracy and process that we don't really
need. Whereas for this we've discussed it, we think it's a good idea, we
discussed it with the community and gotten feedback, but we still think this is
the right thing to do so we should just do it.

Mirja: I don't think there's a lot of difference. The only difference is if you
come back in 2 years and say the experiment is over, we're now keeping it.
Either you have to send this email in 2 years or you don't have to send this
email. That's the difference.

Jay: The only way someone can say the IESG are overstepping their mark is
because this is going to happen for all documents in all the streams, is that
right?

Mirja: My thought was people would say we overstepped because there should be
some kind of policy behind it and not just a decision under the hood.

Francesca: I did bring this proposal to the IRSG and ISE, etc, to make sure
everybody is included. We're talking about the IETF stream but other stream
managers have also been included and have decided to be part of this same
experiment, or this same proposal, if we go ahead with it. We'll try to do it
the same way which I think is very good. We don't want to start doing things
differently. No, that's not overstepping. I think it's more like, is this
something that should be discussed in RSWG and let them have a conversation if
this should happen or not.

Lars: One reason we're doing this is transparency because of antitrust, so that
everything related to standardization is in the open. Whether the other streams
do this, I don't care, because they don't do standards. They can, and it would
be great if we applied the same thing, but for the IETF stream one reason we're
doing this is because we want maximum transparency because of antitrust and
other concerns. This is not something the RSWG has a say in. This is us
deciding for our stream, and if other stream approval bodies want to do the
same for their streams, that's great. But this is us doing it for ours.

Mirja: Lars, I fully agree, but I think people will complain anyway that we are
overstepping.

Lars: Sure, but like I said, we're doing it for our stream and if other stream
approval bodies feel inspired to do the same for their stream, we're not
overstepping other than by inspiring them too hard.

Jay: The other answer you can give is that you're doing this because this is
part of the transparency principles already established, etc. if people don't
like it, then they need to get consensus to do something different. It's an
argument I use regularly.

Francesca: I think it would be useful, Lars, if you could help me write an
answer to all the comments about waiting for RSWG.

Lars: I think it's basically going to be that, thanking people for their input
and we know there wasn't unanimous consensus but we believe that the IESG has
seen enough consensus to go ahead with this for the IETF stream because of
transparency reasons and we leave it up to other stream approval bodies to
decide if they want to enact a similar policy for theirs.

Francesca: I will be happy to create a version of this document summary to
summarize the questions we've had and the answers we agree on as the IESG, just
to say we're not ignoring the discussion but we've looked at it and we have
these answers. It's a little bit more work but I think it's worth it.

Zahed: I would not really bother doing that. I think what Lars said, this
discussion is happening on a public mailing list, so if we conclude that we
have positive feedback and some discussions about different things, that's good
enough. We don't need to provide answers to everything because then it will
open up some people who will refer to this document.

Francesca: I don't want this exact document, this is just for us for discussion.

Zahed: Whatever formal document. I think that if we would like to write a
response let's not use the word consensus, let's say we have input, we've
reviewed, and this is our decision. If someone is unhappy with it then we can
deal with that.

Francesca: I think we can talk about consensus on some things, because there
was consensus that it was a good idea.

Zahed: We didn't ask for consensus, so why would we use that?

Francesca: Because there is. You can read through the mail thread and see that
everybody agreed. We don't need [consensus] but it's good that we have it, so
why not highlight that?

Zahed: I don't think we need to highlight it.

Francesca: I think it's polite to answer peoples' questions after we've asked
for feedback. It shows that we care what people think.

Zahed: I think the word consensus might be contentions because we are really
relying on this consensus. I don't think we need to reply to everything. We
reviewed it and this is fine. Those are two different things. But it's up to
you, or up to the rest of us I guess. I just don't like the word consensus to
be overused when it's not necessary.

Francesca: We can nitpick on the words we use once we have draft text, which
I'll be happy to take help with. I had three more points we should discuss. One
thing we should be clear about when we announce whatever conclusion we've
gotten from this, is clarify the responsibility and accountability of checking
a document during AUTH48 do not change with this proposal. The processes do not
change and it's still the same people who are responsible for approving a
document. It's not an ask to review all the changes in AUTH48. The second point
we should decide on is one mailing list vs. many. Robert said anything is
possible but he strongly encourages one list, not one per group. One per group
is much more overhead for the secretariat and RPC and then anyone that wants to
look back later and find all the AUTH48 interactions for a cluster or
particular author across many WGs. Finally, we should have an idea on what to
do, if anything, for the future or if/when we want to start using Github.
Nothing we need to decide now but we can think about it. Thank you for
listening to me talk about this. Going through the mail threads was a lot of
mail, some of which were completely unrelated and some of which were quite
interesting. I just hope now we don't let this die. My personal opinion is I
don't really care when or how we do it or how long it would take the RSWG take
a look. Maybe I don't know why it would be a problem to do that if it doesn't
take too much delay, but I'd rather not have to wait two years and publication
of an RFC to do something so simple. From the mail I read, people who were
saying to wait for RSWG to be set up, it didn't sound like the discussion
happening there would take two years. I would be interested to hear people who
know more than me, if you do know why it would take that long.

Lars: I don't know if it will take long or not, I don't think it's their
decision and that's why I don't want it to go there. It's not because I think
it will take too long.

Mirja:  They might have the discussion and they might find some conclusion but
the only thing they are supposed to do is write RFCs. That means they have to
write it down, find consensus, send it through the process, publish the RFC,
and then you can act on it.

Rob: I find Lars's argument here compelling, that this is something we're doing
for the IETF stream and not the others. It doesn't come into the equation; I
don't see why we would need to [send it to RSWG]. And we've spent a lot of time
discussing this; we came to a conclusion and we should just do it.

Francesca: The answer is in the mail thread, i'm not saying i agree with it,
just trying to bring up the words I read, was that because this changes RPC
processes, it is in scope for RSWG.

Éric V: It's not about processes, it's about tools.

Warren: Some of it is that people don't entirely see this as something that's
on fire so they don't see any urgency to get it done. Some of it is let's wait
and see if anyone else has any good ideas because I don't really want to do
anything now and I'm tired of fighting it and have apathy.

Mirja: Replying to Francesca, that's a completely different interpretation.
Just because it's an RPC project doesn't mean it's in scope for RSWG. Only if
it's a policy that can impact the RPC process. There might be other internal
processes that someone else decides on.

Francesca: To answer Warren, from what I read in the mails, people seemed
pretty strongly opinionated that you shouldn't do it until RSWG is set up, but
again, no strong objection to the proposal itself.

Mirja: Maybe the reason they want to wait is because they have a different
thing they want to do which might impact policy, but this one doesn't. They
want something where they can change the AUTH48 process to where they can
interact more with the process or something. They have a different goal than
just improving transparency. I think that's what they misunderstood from this
proposal and that's why they have strong opinions that it should go to the
RSWG. That's my interpretation.

Francesca: This made me realize there might be more discussion about RSWG
unrelated to this proposal that needs to happen with the community to make sure
everybody is on the same page, because it doesn't seem to be the case right
now. We don't need to solve that right now but it might be good to have it in
mind.

Warren: I still don't understand how we deal with when people start saying you
have to change it this way, no, you have to change it this way. But I've said
that a bunch of times.

Francesca: Do you mean when people outside of current AUTH48 conversations step
in?

Warren: Yep.

Francesca: I think it is up to the authors and chairs and responsible AD and
shepherd. If that happens, which I don't think it would in most of my WGs, it's
up to us to say no.

Warren: I don't see how people aren't going to view this as you're creating two
classes of citizens, those who are the authors and those who aren't. People who
are not the authors involved in AUTH48 have to watch but they cannot
participate.

Francesca: But in the end it's the chairs and the AD who have to make these
calls. Right now the AD does this all in the dark with no transparency about
that. We're always asked to make the call to review these changes. Having
someone outside who can see it wouldn't change that, we would still have to
make the call, and I hope that we can all do the right thing and make the call
correctly. It's just that it's more public now. Do you foresee that happening a
lot, that people will come up and say I don't agree with this change?

Warren: I don't know if it will happen a lot, but I haven't heard any useful
answers for what we do when it does start happening a lot. Or, when we have for
example, the spring document where we had a lot of people who were really
pissed. Every change somebody made, you could see them say, no, you can't make
that change, that comma should be a semicolon instead. Having a bunch of people
who can watch the process happening but cant make any input doesn't seem
particularly helpful and having a set of people who can come along and raise
concerns each time, i don't know if you remember but a couple of years ago
somebody submitted hundreds and hundreds and hundreds of errata for commas and
fonts and spaces. I've said this a bunch of times and I feel like either I'm
not communicating it well or I don't care enough, this isn't a hill I'm willing
to die on. I still don't understand how doing this and not just at the end of
the process, maybe publishing what all happened or saying things happen, this
is what's in the RFC. It feels like this is just opening more avenues for
people to get annoyed and feathers ruffled.

John: Can I try to say part of what I heard from you? I think you're correctly
identifying that radical transparency opens the organization up to certain
kinds of attacks from people acting in bad faith. And that's right. But that's
the organization we have.

Warren: Or in good faith, but with opinions.

John: What I take from that is I think you're right, but it's just a price we
pay in lots of different parts of our process.

Warren: Radical transparency is great as long as you are okay with people
actually interacting. Having radical transparency where you say you can watch
us do things but if you think we're doing the wrong thing you're not supposed
to get involved is my root concern.

Francesca: No, of course.

Warren: So if you're saying that's not it, then it's radical transparency and
people are supposed to be involved, which is what I heard you say exactly is
not what's happening.

Francesca: Are supposed to or are allowed is different. I don't think anyone is
supposed to get involved, but they are allowed because now they can see what's
happening. They have the chance to actually get involved if they want to.

Warren: So if someone thinks there needs to be a comma, and there isn't, and
they think that's a problem, they should report it?

Francesca: I'm going to quote Roman here and say that's why they pay us the big
bucks, right? That's where we will have to step in and say something.

Warren: It feels like we're solving a problem that no one thought was a problem
until we started talking about it. We haven't had people fussing and saying
things changed in AUTH48.

Jay: There are people who think that the lack of transparency is a problem, and
that by showing this transparency, the behavior of certain people will become
visible and hopefully change as a result of peer pressure. So, there is a
genuine concern there and this is solving something. I think you're taking a
slightly one sided view of the way that transparency will have an impact here.
There are certainly some negatives, but the overall start of radical
transparency within the IETF has actually worked out very well, in my limited
knowledge of it. I can't think of an area where radical transparency has led to
a failure. It's generally led to the creation of some mechanism which is
self-healing and fixes things. I expect there will be some issues that come out
of this initially, and they will need to be addressed, but for example, there
may need to be a clearer statement of what authors are empowered to do without
taking it back to the list, or there may be some better way of saying to
people, no, you're out of scope for getting involved in what the authors are
saying. But in the end, I don't think that's going to be problematic. I think
this is going to end up benefiting quite clearly the entire process as well as
those involved in the process.

Warren: The bit that feels weird to me is saying you can watch the sausage
being made, but you're not supposed to raise concerns if you think someone is
putting in too much salt.

Jay: I expect people will say, hold on, the author is now making a change that
is beyond the boundaries of what the author is supposed to do, they're not just
changing a comma. People will see that and will talk about it and will raise
that on the list. To me that;s a benefit, because currently that isn't seen.

Francesca: It relies on us ADs spotting it and putting a stop to these types of
changes. Honestly, all the reactions, it was quite reassuring to see that
nobody had concerns and everyone was quite positive this will create positive
results.

Rob: Is that a choice? If we say people do want to flag something, or raise
something, that they should either raise it through the AD or at least CC the
AD or something like that? Is that worth saying? Because at that stage, isn't
the responsibility of the document with the AD?

Francesca: We could definitely encourage it. Now this goes into the sort of
text we would send to summarize the discussion and announce what is going to
happen next. We can do a lot of polishing on that text. I hope I have answered
your concern, Warren, but I'm not sure I have. Or that Jay has, at least. The
one question you started with was who is supposed to answer whoever comes to
AUTH48 conversations now that these are publicly available? The answer for me
will be us, the responsible AD. and hopefully it doesn't happen too often.

Sandy: Every once in a while now we do get mail from people who are not AUTH48
parties. At that point we just send it to the authors with all the parties CCed
and ask them to please consider whether this is a valid change. The only
concern on my part would be how much more frequently we start to see that, but
I think internally at least we would somewhat treat this as an experiment where
we touch on it regularly to see how things are going and whether tweaks or
adjustments are needed.

Francesca: Yes. I think we need to have some followup anyway, whether we call
it an experiment or a pilot or whatever. We shouldn't set this up and then
forget about it.

Lars: I want to come to a conclusion on this one and I'd like to know if anyone
feels we should not set up the list as discussed. Meaning the single list, not
as an experiment.

Francesca: I've heard people here say why not an experiment.

Lars: That's why I'm asking the question I'm asking. If people think we should
not do this, if we should run it as an experiment, then speak up and we can
have a discussion about whether it should be an experiment or not.

Warren: If you do it as an experiment, how do you ever turn it off?

Francesca: That's what Lars was saying.

Lars: Who thinks if we do this we should do it as an experiment? [long pause] I
don't hear objections against doing number 1 on your list, so let's do it.

Francesca: Before we officially decide I wanted to get peoples' opinions who
are not here. We are missing Roman, Murray, Martin.

Warren: I'm still concerned that it's unclear to me. Maybe it'll be wildly
clear to the participants. But it's unclear how much the rest of the IETF is
supposed to be involved and how much they are expected to be another set of
authors and how much involvement they can have to relitigate. I keep hearing
that we'll figure it out later.

Lars: We did explain this when we asked for comments on the proposal. This is
supposed to be a read-only list that you can subscribe to but if you're not an
author or not RPC, you don't have posting rights or if you do post, you get
ignored.

Jay: You could add, if you think from viewing this list that an author is doing
something beyond the scope of what they're allowed to do as an author, please
raise it with the appropriate AD.

Mirja: Also I think our expectation was not necessarily that you should
subscribe to the list.

Lars: Right. The main expectation was that this is an archive.

[crosstalk]

Mirja: Maybe that's also a good thing to communicate, that there's no
expectation anybody should subscribe to it. Not to stop anyone from doing it,
but that's not the expectation.

Lars: My suggestion would be for Francesca and I to write a community
announcement message and we'll run that by the entire IESG so people who aren't
on the call can yell if they disagree with the high level outcome or the
details. And all of you can agree or disagree.

Francesca: That sounds good. And once we have that agreed in the IESG we should
circulate it with the other stream managers, the tools team, and the RPC, to
make sure everybody agrees.

Lars: We can parallelize it and tell the other stream managers this is what we
intend to do, please consider doing the saem for your stream. Like we did with
the terminology.

Francesca: We do need RPC and tools team agreement.

Lars: Yes, we can also CC them and they're also on the IESG list so they will
see it.

Sandy: I have an implementation question. It sounds like the posting rights are
closed to everyone except the parties that are actively in AUTH48. Does that
mean for each document that moves into AUTH48 those authors would get
permissions and then lose them once it's done?

Lars: No. We discussed this with Robert and basically, it'll be a public list
that anybody can post to but we're not going to say that. We don't want to have
the overhead of you managing the posting rights on a per-document basis, unless
that can be automated.

Sandy: Okay.

Lars: We could put the list in moderation and if anybody ever responds who's
not supposed to you can not approve the post, but that also costs you overhead.
I would leave that up to you to decide whether you want it. Maybe we will keep
that in the back pocket in case we do see posts happening frequently.

Sandy: Makes sense.

Amy: I have an action item for Lars and Francesca to draft text for this and
with that I think we can move on to our next management item.

6.2 [IANA #1229134] Acceptance of media type registration from standards
organization CWL Project (IANA, Murray Kucherawy)

Amy: Murray looked into this and sent email just before he went away. He thinks
this should be approved. Is there any objection to approving this media type
registration? Hearing no objection, so this is approved and we will send the
official note to IANA.

6.3 IETF 114 Important Dates (Secretariat)

Liz: These are standard important dates; I'm not sure if anything needs
explaining.

Amy: This continues the early cutoff for BOF proposals, to give you a couple of
weeks to work with BOF proponents if that's still what you want to do as you've
been doing for the last year. Other than that they're pretty usual.

Lars: If they're usual I'm fine with that.

Liz: We haven't changed anything here from the defaults we usually use.

Lars: I wonder if we want to even announce the second BOF deadline? That's more
like an internal deadline. So those BOFs that got submitted by the first
deadline that we think need revisions, for those BOFs we have that revise
deadline. There's no need to tell the community there's a second deadline
because that just causes confusion about when you have to submit by.

Mirja: The original idea was that for the first deadline you only have to
register your bof but you don't have to provide all the information, you can
still edit and add things before the deadline. That's probably not what's
happening.

Amy: Generally the BOF call will happen the week after the cutoff date for the
proposed bof requests. If you don't have all the information you can't make an
informed decision.

Mirja: Maybe we should be more explicit about which information we need for the
first deadline and what information we need for the second deadline.

Amy: I think the second deadline was there so that ADs and IAB members who are
interested can work with the proponents to refine what the BOF is actually
going to be about. Any information they want considered should be in the
original bof proposal at the early date. Things like who's going to chair and
conflicts and things like that can wait for the second date but everything that
they want the IAB and IESG to consider when making a preliminary approval
should be on that first date.

Lars: My proposal would be that we actually kill the second date because we
have the cutoff date for ADs to approve BOFs, which is by when we need to make
a decision. If the ADs have time to review updates from the bofs that weren't
rejected by the first cutoff, or by the call.

Amy: So you want to keep the May 27 cutoff for proposal requests, kill the June
10 cutoff for revised proposal requests, and keep the June 17 cutoff for ADs to
approve bofs?

Lars: Yes. because all revisions that happen between that first bof cutoff and
approval time are in collaboration with the IAB and under the discretion of the
AD. and we would still have the bof call after the first deadline.

John: I seem to remember that we talked about putting in a date for I-D
submission reopening.

Liz: That's still the plan; it requires some separate fussing in the
Datatracker. It will be listed but we have to do something extra to add it
first.

John: Great, thank you.

6.4 [IANA #1229681] Designated experts for RFC 8809 (WebAuthn) (IANA)

Amy: This is a new action item for Roman. IANA has proposed a potential expert
so once Roman is back he can take a look at that.

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