Narrative Minutes interim-2022-iesg-24 2022-10-27 14:00
narrative-minutes-interim-2022-iesg-24-202210271400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-10-27 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
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
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Sandy Ginoza (AMS) / RFC Editor Liaison

OBSERVERS
---------------------------------
Lee-Berkeley Shaw

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? As a reminder, you
have an executive session to discuss at least one subject. Any other changes?

John: I have a question about the executive session; Erik K said he had to drop
early. Should we do the executive session first?

Amy: We'd have to excuse all the liaisons and then have some way of calling
everyone back…

John: I guess that wouldn't work.

Erik K: I approve of the documents that I have seen.

1.3 Approval of the minutes of past telechats

Amy: These have only been out a week since we have back to back telechats, so
we're going to keep these until the next telechat after IETF 115.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Paul Wouters to find designated experts for RFC 9200 (ACE-OAuth)
       [IANA #1239251].
     o Paul Wouters to find designated experts for RFC 9203 (The (OSCORE)
       Profile of the (ACE) Framework) [IANA #1239258].
     o Paul Wouters to find designated experts for RFC 9237 (An
       Authorization Information Format (AIF) for Authentication and
       Authorization for Constrained Environments (ACE))[IANA #1239259]].

Paul: Still in progress.

     o Lars Eggert and Colin Perkins to find designated experts for RFC
       8609 (Content-Centric Networking (CCNx) Messages in TLV Format)
       [IANA #1239154].

Amy: Lars has not joined us yet so we'll keep this in progress for them.

     o Roman Danyliw to find designated experts for RFC-ietf-lamps-cmp-
       updates-23 (Certificate Management Protocol (CMP) Updates) [IANA
       #1241372]

Amy: This is brand-new for you, Roman.

Roman: Action caught, thank you.

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

Amy: This is on today's agenda as a management item to take a look at the
graphs.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ippm-ioam-conf-state-07  - IETF stream
   Echo Request/Reply for Enabled In-situ OAM Capabilities (Proposed
   Standard)
   Token: Martin Duke

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

Martin: The Discusses were gracious enough to provide suggested text, in most
cases, and if there has been a reply I haven't seen it.

Warren: Quick update, it seems that many of the people who had Discusses
provided helpful text, authors have replied, and I think they're going to fold
them in. I was happy enough that I have cleared my Discuss but I do think at
some point there is a concern we need to address which is it feels like
increasingly documents say the security solution for this is operators will
filter these at their borders, or must filter all of these types of things at
their borers, and in many many cases, this one as an example, there is no real
way to filter this at your border with any current network device. It's a meta
issue. It was one of my concerns but I don't feel reasonable holding a Discuss
on a meta problem.

Martin: I think we had a problem where people thought when they had a design
with these sorts of concerns, the first magic incantation was limited domain.
Then we pushed back and said no, you actually need a strategy for enforcing
that. Now the magic incantation is you will filter the packets. That is a
systemic problem, I agree. I would say that in the particular case of IOAM, it
relies on encapsulation to do its magic and so if you're setting up
encapsulating tunnels that are not being encapsulated, you have bigger problems.

Andrew: To echo what Warren said, the classic example of this is when they tell
you to filter this at the edge and the edge happens to be every port, and then
you start looking at the TCAMs on the devices and if you actually do that you'd
blow up the TCAM on the device and the device would cease to function. This is
something I've run into a lot, this whole filter thing not being possible. I
don't know how we deal with it, but it is a problem.

Martin: I don't remember from the shepherd writeup if this has been deployed or
not. But obviously some of this IOAM stuff has been deployed. Anyway, revised
ID needed. Good Discusses, thanks everyone; I don't know that we need to
discuss the details of these today.

Amy: Okay, I have this as Revised ID Needed and we'll move on.

 o draft-ietf-lpwan-schc-over-nbiot-12  - IETF stream
   SCHC over NBIoT (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Thank you for the review, as usual. THe main author was unable to join
the call because she is on vacation. All of you have seen this document is
partly normative and partly informative. I think Lars, you suggested moving the
informative part to the appendix. Personally, I don't mind. The shepherd and
the authors do not like it too much. How do you think we can solve this?

Lars: I almost don't care whether it's in the appendix or not. I think it would
be a little bit nicer in terms of the structure. The main point is that I still
haven't gotten an answer to the question is 3GPP aware of this and are they
expecting us to do this, or will we get email from them saying what the hell
are you doing talking about this thing in our architecture? I know liaisons
were sent, but that's all I saw in the tracker. I don't know whether 3GPP will
be surprised by us publishing this document. And running it over, I think they
couldn't really be surprised because we're taking their thing and putting
something on top, but the other part, I think I would like to avoid us causing
surprise on the 3GPP side.

Zahed: I was reading the shepherd writeup which said we need to send a strong
signal to 3GPP that we can do this. This is kind of a stance. That's why I kind
of agree with Lars. This sounds more like a contest rather than trying to help
each other. Having clarification would be good. That's why I put it in my
ballot. Wanting to know more about what is the thought process here; why we are
doing it in the IETF. I think this is worth discussing. I also feel like this
is not a well written document and has a lot of information I care less about.
We need to discuss those things.

Éric V: Basically, normally the informative parts are more about tuning some
parameters. They're not really adding anything. I guess we will stay in IESG
evaluation here. Lars and Zahed, I got your points. Let's do Revised ID Needed.

Lars: I think we need to find out what's going on with 3GPP too, right?

Éric V: Yes.

Lars: It almost looks like the ITU-T sending us a message on New IP saying the
IETF made up New IP to improve their architecture. It's not really how these
things are supposed to go.

Éric V: At the extreme, I can send this back to the WG to break this document
into two parts.  One which can go forward, providing we fix the details, and
one that can wait until we hear back from 3GPP.

Lars: Or they can make it Informational, and say here is how some IETF experts
have thought about how something like this might be realized in 3GPP.

Éric V: On the other hand, the part -- [crosstalk]

Lars: We had this ICNRG document that talked in the IRTF about how 3GPP could
use ICN and it was a similar thing. We told them to talk about it as an
investigation into what it could look like but don't say we want to give advice
to 3GPP. Thank you.

Zahed: I'm all for looking into 3GPP and looking at a protocol extension or
something. But giving them a configuration from nowhere….it's a strong signal.
Or is it a strong signal? I don't know.

Lars: Do you know if that spreadsheet still exists? A long time ago we had a
spreadsheet where we tracked all the IETF work that 3GPP had dependencies on
for various releases. Is that still being maintained? I think it was Gonzalo
who made it.

Zahed: Yeah, that's Gonzalo. I don't think it's maintained but that's a good
tool. THis is one thing we could bring into this coordination meeting. Don't
get me wrong, this is good work, and we are doing it with good intentions, but
the other receiving party needs to palate it. Having it come through with our
liaison managers would be great.

Éric V: I agree. By the way, Gonzalo was in the group.

Zahed: This document came this far; it should have been picked up by somebody
and there should be a proper answer. Maybe it's there in the WG and just not in
front of us.

Warren: We sent a liaison; I don't know how quickly 3GPP usually responds to
stuff like that and how friendly discussions are. Could some of this be solved
by, in the abstract, removing stuff like "to improve their capabilities" or
just say 3GPP might choose to adopt this if they wish. So it sounds less like
we're telling them what we think they should do and more that here's something
to do if you want to use it.

Éric V: I think that's the intent, so we can change it.

Zahed: That sounds good and partly what I am asking [for]. Try to write it like
here's a use case on your system with this configuration. That should be fine.

Éric V: Okay, so in the short term, it says in IESG EValuation with Revised ID
Needed. On Tuesday lunchtime we are meeting with 3GPP to see if we can do
something better. Or at least, easier for the relationship between the SDOs.
Thank you.

 o draft-ietf-quic-version-negotiation-12  - IETF stream
   Compatible Version Negotiation for QUIC (Proposed Standard)
   Token: Zaheduzzaman Sarker

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

Zahed: There were some really good comments and the authors are addressing
them. Most of them are editorial in nature. I think this will be Revised ID
Needed.

Amy: This will go into Approved, Announcement to be Sent, Revised ID Needed and
as we are in the I-D blackout period, if they do revise it and they want it
posted, Zahed you'll have to let us know that it's okay to post.

 o draft-ietf-quic-v2-06  - IETF stream
   QUIC Version 2 (Proposed Standard)
   Token: Zaheduzzaman Sarker

Amy: I have no Discusses in the tracker, so unless there's an objection now,
this one is approved. It has nine yes or no objections, but we also do have a
recusal, so that brings our two-thirds vote down one. So nine will, if I did
the math correctly, that will bring it to the two-thirds.

Zahed: That's also what I was thinking. Maybe some of you can--

Andrew: Sorry, I've been away. If you need me to go through it this evening and
put in a ballot, I can do that.

Paul: Same here; I've been sick but I'm feeling well enough I can probably do
it today.

Martin: The math is right. You only need nine if there are 13 potential ballots.

Andrew: It says there are enough positions to pass there, so I think it's
approved.

Zahed: There were some changes to normative language so I would ask Martin to
run it through the WG before we go forward. Even if it's approved I'll put this
in AD Followup.

Martin: Sorry, are there more reviews coming, and if so, when can I expect them
by?

Andrew: I can look at it this evening in which case you'll get something by
tomorrow morning.

Paul: I'll do one today too.

Martin: Okay, thanks. That way I can roll up all the normative changes for the
group. Thanks.

Roman: This is actually not related to the document itself, but it's about the
balloting process. Did we say we're changing the denominator of necessary
ballots by removing the recusal from it?

Warren: It's not changing; that's how it is.

Amy: That's how it's always been. Yes, or No Objection, of the non-recused
number. You have to have a reason to recuse, otherwise you'd be an abstain and
you'd still be counted.

Warren: Note that it's recused, not abstain.

Roman: I didn't realize there was a normative guidance on recuse.

Warren: We could presumably spend a huge amount of time discussing processes
and tinkering with stuff but does this ever cause a problem?

Roman: I'm just poking that there's security considerations here, that's all.

Amy: So what I'm hearing is that this document is Approved, Announcement to be
Sent, AD Follow Up and those who have said they can review will do so. Again,
as that revision comes in, let us know so we can get it posted in the blackout
period.

Zahed: Thanks for the reviews.

 o draft-ietf-sipcore-multiple-reasons-01  - IETF stream
   Multiple SIP Reason Header Field Values (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: No, I don't think so. I understand what this is and I can let the
authors answer. This is my first time seeing it; I was on vacation until last
night. I don't have anything specific here for Paul.

Paul: I talked to Robert and there is some slight disagreement but we're in
touch on email and it's okay.

Murray: Cool, thanks.

Amy: Is this going to require a revision?

Murray: Put it in AD Followup and I'll put it in Revised ID Needed if that's
what's needed, please.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-kucherawy-bcp97bis-04  - IETF stream
   Procedures for Standards Track Documents to Refer Normatively to
   Documents at a Lower Level (Best Current Practice)
   Note: AD-sponsored update to BCP97 documents.
   Token: Erik Kline

Amy: I have several Discusses in the tracker; do we need to discuss any of
these today?

Erik K: If Murray wants to have this discussion now, we can do it.

Murray: I'm going to whine quietly that nobody participated in the discussion
until it got to the IESG. It would have been great to attack some of this ahead
of time. I haven't seen most of this yet, but I've skimmed it all and I kind of
get it. Is there anything anyone wants to use the time to talk about, or do you
want to let me digest it and come back around possibly to see you in London and
deal with it?

Warren: I'll just point back to my earlier foreshadowing of fixing process when
I'm not sure there's a problem. But let's chat in London.

Murray: I don't think this was so much of a problem. The purpose of this was to
highlight something that keeps coming up to the IESG, which is that if you make
a normative reference to something nobody has access to, that's a problem. That
was the whole impetus to this work. The only change is that if you're going to
do that, these are the things you should think about. There's no process
change, as far as I'm aware, this is just otherwise a merger of those three
docs that are being replaced.

Warren: It sounded to me like there is a whole bunch more work put on the
authors and IESG, etc, with the need to explain why you have downrefs. Yes, I
understand it's mentioned buried somewhere in some document no one ever reads,
but that can be deprecating a bunch of existing documents, is what made me
twitch. We can chat in London.

Murray: It may be the case that lots of people didn't know this was already a
part of other existing BCPs and this is just highlighting it by bringing it all
together.

Warren: I think that's it, the highlighting of it.

Murray: None of this is a new process, it's just a reminder that this is all
previously approved process. If we want to pare it down, and just say there is
too much process, that's a different piece of the discussion.

Alvaro: We never used that process. I just wanted to say two more things. One
that I found interesting is that RFC 47-whatever that has the annotation, if
you look at the history, it came to the IESG 20 years ago or whatever as an
experiment. Somehow, the IESG moved it into a BCP. It's clear to me that the
experiment failed, because no one ever used it. The other thing that this IESG
had talked about was in general bis documents, and how to get bis documents
that don't touch everything. Like maybe in this case. I didn't see anywhere,
maybe I missed it, where it was called out that the scope of the review was
only going to be one change. That's in general the risk with doing only limited
changes, once we open a document, how do we limit the comments?

John: I was going to say something generally similar. Several times I've said
that a clean bis is better than a patch, but this might be a case where we
would have been better off with a patch to just make the clarification you
named, Murray, and not the rest of it. Then we wouldn't have had to actually
look at the  fact that these process documents exist and we ignore them all the
time. Now we've looked.

Alvaro: But at the same time, it's better that we look at them so we can clean
up the process. No one is expecting us to annotate stuff no one ever does.
We're clearly not following it.

Murray: It's funny that you mentioned this because also on my list of stuff to
do is an IESG statement about patch documents. We still have not converged on
text about what we want it to say so it's an open item. If I remember
correctly, the  BCP that contained the downref stuff in the first place, I
couldn't avoid doing what I did because those things are all so intertwined
that a patch would have made it worse. It made more sense to combine them into
this one thing. I think I just need to figure out what the path out of this is.

Rob: I think doing an extra patch document would have made it worse. It's hard
for people to understand what the process is, so I'm actually supportive of
getting rid of three BCPs and replacing them with one. I think that's a good
thing. The fact that we've got some process we're not following is just a clue
to delete it since it's not needed and do some cleanup. I think this is a good
thing.

Murray: I agree. The interesting thing about doing the cleanup Alvaro suggested
and it sounds like we kind of like, we're going to have to Last Call it again.
That's a pretty big change so we'll have to go around again on this one.

Rob: That's okay. The process is working.

Murray: So definitely Revised ID Needed, although that's really Erik's call.

Erik K: I guess we might need to take it back to pre-IESG review if we're going
to send it to Last Call. Let's just do Revised ID Needed for now and we'll
downgrade later on.

Amy: So this will stay in IESG Evaluation and go into Revised ID Needed, and
once it's revised you can take it back or move it on as needed.

Murray: This didn't go through a WG, so I guess it would just go back to I-D
Exists state?

Lars: If you feel strongly about a process here, maybe volunteer to help Murray
write it so that there are more text contributions going into and hopefully
next time we see more green.

Erik K: There really should be no Discusses next time.

Alvaro: That was part of the concerns people brought up, ADs writing process
documents that are AD-sponsored and the IESG may be colluding to do stuff. On
the one hand, I think it's good that we see so many Discusses, because it
proves we did not collude on anything.

Erik K: On the other hand, this is a discussion that should have happened
during Last Call. Either way, let's leave it here. Thanks.

Amy: The next step wouldn't be going all the way back to I-D Exists, it would
be Publication Requested or Last Call requested. You don't have to go all the
way back. With that, let's move on.

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-v6ops-ipv6-deployment-08  - IETF stream
   IPv6 Deployment Status (Informational)
   Token: Warren Kumari

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

Warren: I don't really think so, other than I'd like to thank Éric V for having
read it this closely and I think it's a very useful and valid Discuss.
Hopefully we can get the authors to internalize the concern and new document
expected.

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

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

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: Nothing I think is particularly actionable. There was a fascinating
discussion by Robin on Different or Same, IP for Internet and Limited Domains
where the IAB was discussing the concept of limited domains; what one is and
some of the more interesting parts were the discussions afterwards on the
implications of fail-open limited domains vs fail-closed ones. If one creates
something like a limited domain, does one have to deploy filters all around the
edge of your network to make it be limited or not. A number of IESG people were
in the IAB meeting as well so there may be other comments. I think this was
interesting, worth reviewing, but not really news you can use. There is also
some more stuff on the additional BOF coverage and I will put a link in the
chat.

Andrew: Do you know if there were any notes made from yesterday's meeting? If
there are notes I'd like to go through those.

Warren: I'll see if I can find Robin's slides but I don't know if it was
recorded.

Mirja: There's no recording but I'm sure Cindy took great minutes that she has
probably already posted to the mailing list.

Lars: I think there will be a follow on discussion later. I have a feeling it
will probably cover that information again in slightly more concise form. I
don't think  you missed anything you can't recover.

Andrew: That's a hot topic in my world.

Warren: As usual, Cindy's minutes will probably be really helpful. There will
be more discussion.

Amy: Anything else from the IAB?

Mirja: Warren, did you tell the IESG there will be a discussion about DNS at
the Thursday morning meeting and that everyone is invited to it?

Warren: I think I did a while back, but it can't hurt to remind people of it.
There will be a discussion on DNS primarily done by Suzanne Wolff, likely with
comments from myself and Wes Hardaker. The current plan is that Eliot Lear, the
ISE, is also invited because he's moving the DNS document along. This is going
to be a high-level overview of the potential issues with alternative name
resolution systems, collisions with the DNS, relationship between IETF and
ICANN, blockchain domains, etc. That's Thursday morning London time.

Éric V: I wrote in the slack that I'd be interested in being part of the
discussion.

Warren: Hopefully we can make everyone fit in the room.

Cindy: It's a fairly large room and we're going to have some chairs around the
back so it should be okay for both the IESG and IAB, it may just be that not
everyone is sitting at a table.

Alvaro: Is there any time left in the joint meetings to do it there instead?

Warren: This is likely to be a fairly long and vigorous conversation, so it
would require a fair bit of time.

Mirja: We scheduled a whole meeting slot just for this so I'm not sure it could
fit somewhere else.

Amy: Okay, thank you Warren and Mirja.

6. Management issues

6.1 Impact of COVID-19 on the IETF (Robert Wilton, Alvaro Retana, and Warren
Kumari)

The IESG looked at graphs of recent mail messages, drafts published, and RFC
editor submissions.

Warren: What we might want to do is include a little of this information
somewhere in the plenary. We presented something similar when Covid started,
and it looked potentially scary. It looks as though things might be getting
better so maybe Lars can flip through them.

Lars: You can give me a slide and a message. If it looks like we're ticking up
again, we'll want to share that. The plenary will be full because we'll have
the Postel award speech, Alexis Rossi saying hi, and other things that are
one-offs, so I don't want to take too much time.

Alvaro: The bright green line is this year, so it's up or at least around the
same as other years. The one that I think is better is the -00 drafts. You can
see towards the end there it dipped in June but then it's going up, which is
not only really good, it's different from other curves. This curve was the one
that really concerned us before, that we were seeing it lower in 2020 and 2021.
It did start lower this year but now it's going up. I'm not sure we can say
we're doing great, but we can say we're getting past some of what we thought
was the effect of Covid.

Éric V: It also takes time to go from a BOF to getting a -00 as well.

Warren: I think the summary is that it looks as though things are getting
better. If we do present this we should adjust the colors or make the lines
easier to distinguish.

Rob: There's also a question of whether we can continue tracking this
information. I think we should. I don't know how much effort it takes but I
think it would be useful to continue.,

Lars: How much work is it for the secretariat? Is it a tall ask to keep doing
this?

Amy: I'm not sure how long it takes Ryan to run his report, but he gives me all
the numbers and I put them in the graph. Figuring out the graph is the most
time consuming part and it doesn't take very long.

Lars: Great. Because I find it very useful and I think we should keep tracking
this on an ongoing basis.

Alvaro: We also have a new graph of RFC Editor submissions. These are numbers
per quarter made into a line. This year, the bright green line you see from Q1
to Q2 goes down but it does that every year so that seems kind of normal. When
I looked at this the only thing that worried me is that the lines for 2020 and
2021 which are the lower lines, I would have assumed that RFC Editor
submissions are more of a lagging. Meaning that we did the work for the -00s
and all that stuff, for things processed in 2020 we probably did the work in
2019, and it also goes down. It just surprised me that those lines were too low
if we assume this is a lagging indicator of the work we already did.

Lars: This is documents going from the IESG to the RFC Editor, right?

Amy: These are documents that leave your hands as approved and go to the RFC.

Lars: Is this just the IETF stream or all of them?

Amy: I'd have to check but I believe it's just the IETF.

Lars: Can we also make the y axis go down to 0? The other suggestion is that
the point is to compare the current year to previous years, and these plots are
getting busy. I wonder if it would make sense to compare the current trend line
to an average of the last two or three years. It really only matters if we're
better or not than the recent past.

Alvaro: I agree. If we're looking at the effects of Covid, we want to at least
get rid of the ones before 2020. Or two sets, before Covid and after.

Warren: Having the lines helps provide a baseline, even though they're hard to
see. I guess that's not really something we need to discuss right now.

Lars: It might also be that we can do something with the colors to make it
easier to see which are old and which are new. We can play with the google
sheet.

Alvaro: Thank you Amy for doing all the work for us.

Amy: We'll look at this again before 116 and see what's changed, so we'll keep
the action item.

6.2 [IANA #1241372] Designated experts for RFC-ietf-lamps-cmp-updates-23
(Certificate Management Protocol (CMP) Updates) (IANA)

Amy: This is just to assign the action item to Roman that he took on at the
beginning of the call.

6.3 Approval of the IESG Statement on Restricting Access (Lars Eggert)

Lars: I think we're agreed on the wording. There was some addition made on the
bottom because Colin pointed out that if the IESG decides some participants are
excluded from accessing our IT systems that might impact the IRTF as well so we
came up with some text that said we would do this in coordination with the IRTF
chair as needed. I think otherwise we're good to publish this.

Mirja: The new text I don't have any concerns with, but I also don't understand
because the IRTF is not a legal entity so if the IETF decides to do something
it's independent of the IRTF.

Lars: No it's not, because they use our IT systems.

Mirja: Yeah, but if we have the legal obligation to do something, we have to do
it no matter if the IRTF wants to or not.

Lars: Correct, but we'd still talk to Colin.

Mirja: We list people that should be consulted and we can put the IRTF chair in
here, but there would probably be no legal obligation on the IRTF chair because
that's not a legal entity. So I don't see the point. But we can keep the text,
I don't think it hurts .

Lars: There are 2 cases. One is that counsel might tell us we need to exclude
somebody for their behavior over on the IRTF. Then there's the case that if we
exclude somebody that has an impact on their ability to participate in the
IRTF. It doesn't really say anything other than we are aware this is the case.
IT's the last two paragraphs.

Mirja: The one concern I have is that we should be clear about the obligation.
If legal counsel says we ended up excluding this person from the IRTF because
it's only an IRTF participant, I think it still needs to be the IESG to decide
this because it's to protect the IETF.

Lars: We wouldn't slice it and dice it. Counsel would say we need to exclude
this person from accessing our IT systems period. This is not a PR action, this
is something that puts us at legal risk.

Mirja: Other than consulting with the IRTF chair, I don't see their role. I'm
not sure why we need this text.

Lars: We need it to make the IRTF chair happy. You can discuss it with him but
I'd very much like to publish this now. I'll point out that IESG statements can
be changed, but I think it would be good to publish something soon. Anybody
object to publishing this current text as an IESG statement? I hear silence.
Okay, we've approved this. I'll give it one final read and I'll send the
secretariat an email probably tomorrow to put it up on the website. Thank you.

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

Roman: I wanted to mention a good news story. Scheduled for IETF 115 was a plan
to do another JWP BOF. Based on how this system works, I scheduled that
defensively not knowing how the discussion at the interim BOF would go. The
good news is that we had an interim BOF, great discussion, and the end result
is that we have consensus to go ahead with the WG charter. I've put it on the
ballot for the first December agenda and as a result we do not need to convene
that BOF [at 115]. It's going to disappear from the agenda, FYI.

Andrew: There have been a lot of IESG members who've supported me in the last
few weeks with what I've been going through with my family the last few weeks
and it's very appreciated.

Amy: Safe travels for those who are traveling to London, and we'll see you soon.

6.4 Executive Session Discussions (Lars, Rob, Roman)