Narrative Minutes interim-2023-iesg-05 2023-02-16 15:00
narrative-minutes-interim-2023-iesg-05-202302161500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-02-16 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Incoming Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Cindy Morgan (AMS) / IETF Secretariat
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
Eric 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
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Warren Kumari (Google) / Operations and Management Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Luigi Iannone
Lee-Berkeley Shaw
Atsushi Takahashi
Greg Wood

1.2 Bash the agenda

Amy: Anyone have anything new to add? Any other changes?

Eric V: I have to leave after one hour; can we make sure to discuss RADEXT
before I go, because I have a block.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes from the February 2
teleconference being approved? I'm hearing no objection. Does anyone have an
objection to the narrative minutes from February 2 being approved? I'm hearing
no objection there either. We will get those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Francesca Palombini to find designated experts for RFC 8141 (Formal
       URN Namespaces, Informal URN Namespaces) [IANA #1263515]

Amy: I believe we have this on the agenda later as a management item to approve.

     o Roman Danyliw to find designated experts for RFC 9347, ESP
       AGGFRAG_PAYLOAD registry [IANA #1265971]

Roman: Action caught, thank you.

     o John Scudder to find designated experts for draft-ietf-lsr-flex-
       algo-25 (IGP Flexible Algorithm) [IANA #1266560].

John: Same as what Roman said.

   * 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 March 2023.
       - On hold

     o Lars Eggert, Warren Kumari, Eric Vyncke, and Rob Wilton to discuss
       whether to reconstruct the document approval announcements to be
       more meaningful.

Lars: I think it's on the agenda for next week's informal. If not, I'm going to
put it there.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-lisp-pubsub-13  - IETF stream
   Publish/Subscribe Functionality for the Locator/ID Separation
   Protocol (LISP) (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: I don't think we do. The authors are aware of the Discuss, and they're
working on some text for it. They've been pretty responsive to comments so that
should be handled shortly. I also want to say that I'll wait to make sure all
the transport directorate comments are addressed before we approve the
document, so even if Roman's Discuss clears, I'll wait until that's done.

Amy: We'll put this in Revised I-D needed.

 o draft-ietf-secevent-subject-identifiers-16  - IETF stream
   Subject Identifiers for Security Event Tokens (Proposed Standard)
   Token: Roman Danyliw

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

Roman: No, I think these are best handled by the authors and WG talking it out.
What's needed is clear.

Amy: Okay. If both of those Discusses move to No Objection you still need one
more position, so hopefully some of the folks who are absent today can review
it as well.

Lars: Feel free to ping them. We've had a few absences lately and that doesn't
mean you still shouldn't get your ballot in.

 o draft-ietf-tcpm-hystartplusplus-13  - IETF stream
   HyStart++: Modified Slow Start for TCP (Proposed Standard)
   Token: Martin Duke

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

Martin: Revised I-D Needed, please.

Lars: Are you going to do something about the algorithm presentation? What
changes do you think they're going to make?

Martin: There are a lot of nits and so on in the comments. I've not looked at
the responses they made about the presentation of the algorithm.

Lars: They'll probably respond to the reviews and we'll take it from there.

Martin: They're relatively slow to respond. Is this a not-quite-Discuss comment?

Lars: They say it's pseudocode but it really isn't, it's chunks of pseudocode
mixed with prose and it's not very clear. It's clear if you're a TCP expert but
if you're a casual reader it's confusing.

Martin: Ok, I'll make sure that's addressed.

 o draft-ietf-ace-extend-dtls-authorize-06  - IETF stream
   Extension of the CoAP-DTLS Profile for ACE to TLS (Proposed
   Standard)
   Token: Roman Danyliw

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

Roman: Super, thank you for everyone's review. Can you please put it in AD
followup? I haven't had a chance to look at all the comments.

Amy: Okay, this will be approved, announcement to be sent, AD followup and you
can let us know when that's ready.

 o draft-ietf-httpapi-rfc7807bis-05  - IETF stream
   Problem Details for HTTP APIs (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: Can I get AD followup so I can check on everything?

Amy: Absolutely. Approved, announcement to be sent, AD followup.

Lars: There's one thing with a little discussion between Mark and me about the
IANA stuff. You'll find it in the thread on my comments.

Murray: I'll keep an eye out.

 o draft-ietf-emu-tls-eap-types-12  - IETF stream
   TLS-based EAP types and TLS 1.3 (Proposed Standard)
   Token: Paul Wouters

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

Paul: AD follow up please, so I can look at all the comments.

Murray:  I'm currently haggling with them over some SHOULD vs MUST language but
I don't know if it needs to hold up the document. You can decide when it goes.

Amy: Approved, announcement to be sent, AD followup for this one.

 o draft-ietf-httpbis-origin-h3-03  - IETF stream
   The ORIGIN Extension in HTTP/3 (Proposed Standard)
   Token: Francesca Palombini

Amy: There are no Discusses for this document, so unless there's an objection
now, this is approved. Since Francesca is not here, I'll put this in AD
Followup so she can do a final check and let us know when it's ready.

 o draft-ietf-avtcore-rfc7983bis-08  - IETF stream
   Multiplexing Scheme Updates for QUIC (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: This one doesn't need to wait, you can send it.

Zahed: I had one comment. The reason QUIC getting everything. There were a
couple of questions on that one. I think we had a good discussion between
AVTCORE and QUIC. maybe a couple of lines might make it clearer. But I don't
have a strong opinion. I know what's going on but maybe for the readers you
want to add something there.

Murray: Was this in your comment thread somewhere?

Zahed: I think so. Our TSVART reviewer also had that comment and Éric.

Murray: Okay. AD Followup please, and I'll check in with them about what they
want to do about this.

Eric V: I think we really need to think about it, because we burned all the
code points. Not even reserving one for any extensions.

Murray: I appreciate you saying you trust the responsible AD, but in this case
you shouldn't. If you want to put in a Discuss, you should go ahead.

Eric V: No, I trust you. I know you're following up on all the IANA things as
well.

Murray: AD Followup please and I'll chase this down.

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

 NONE

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-irtf-nwcrg-bats-00
   IETF conflict review for draft-irtf-nwcrg-bats
     draft-irtf-nwcrg-bats-07
     BATS Coding Scheme for Multi-hop Data Transport (IRTF:
   Informational)
   Token: Erik Kline

Amy: I have no Discusses in the tracker, so unless there's an objection now
this can go back to the IRSG. Great, we will get that no-problem message sent.

3.4.2 Returning items

 NONE

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

 o RADIUS EXTensions (radext)

Paul: There's a version 2 with the changes John put in his ballot.

Amy: I have one blocking position here. Do we need to discuss that?

Eric V: It's up to you, Paul. I think it's very obvious and both Alan and
Margaret have agreed.

Paul: I think it was removed from the text.

Eric V: It was removed already? Ah, let me check. If it has already been
removed I will remove my block. No, 'if possible' is still here three times.
This part of the text was not changed.

Paul: I will take a look at it.

Eric V: I proposed some text. 'If possible' is not like SHOULD. It should be
pretty trivial to fix.

Amy: It sounds like external review is not approved yet but it's pretty close.
We'll wait for instructions from you, Paul, when this is ready to go.

 o Computing-Aware Networking (can)

Amy: I have one blocking position here. Do we need to discuss that?

John: I'd like to. Zahed, I replied to your email but I don't know if you have
had a chance to look at my reply yet.

Zahed: I was looking at it. I prepared a reply so i can just tell you here.
This is not something I'm blocking on a technical ground but just for
clarification. The first one, I'm confused about the expert advice. You pointed
out that yes, this is supposed to be when we expose things to the network edge
overlay. I think that was not clear to me. One line above it says "the
characteristics that may distinguish CAN from other work include the desire to
integrate both network and compute conditions in the optimization function." I
think in the author's mind this optimization function only stays on the overlay
edge, but this could be in the server, in the client, or whatever. Maybe we
should just be precise that we're talking about a function that CAN wants to
work with and this is on the overlay edge. That would not create any confusion
in my mind.

John: So maybe we insert the optimization function at the overlay edge so the
words "at the overlay edge" in there?

Zahed: Yeah, something like that. You can look at my reply for that. The other
one is basically the multi domain thing. If you just remove the "initially"
from the charter then we're fine.

John: Cut that one word? Fine.

Zahed: I'm going to send you the email so you have my proposals. When that's
done my block will be addressed.

John: We'll try to have that finished today, then.

Zahed: I trust you to just remove my block right now.

John: That works for me.

Amy: If you remove the block, this will be approved. We can make it Approved,
Pending Edits?

John: Sure, let's do that.

Zahed: I'll just remove my block.

John: I'll get the edits done and send you an email.

4.1.2 Proposed for approval

 o Time-Variant Routing (tvr)

Amy: I have no blocks, so unless there's an objection now it looks like this is
approved and we have a new WG.

Alvaro: The charter text is ready to go.

Eric V: You keep the focus on non-terrestrial, right?

Alvaro: Yes.

Amy: This is approved and we will get that sent.

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

Mirja: We will appoint 2 new liaison managers, which will be announced very
soon. We also discussed that the IAB will provide feedback to a consultation
call from the UN on human rights in the standards setting process. I'll share
the link in slack. The third thing we discussed was again related to Rob's
ballot position. I provided a little bit of feedback about the discussion that
happened in the IESG and my understanding was that Rob was going to update his
ballot position so the IAB is interested to see that, and is also interested in
having a longer discussion either in Yokohama or at the retreat.

Rob: Just to confirm, yes, I haven't done it yet but my intention is to change
it. I'll probably send text to you and a few other people before I do.

6. Management issues

6.1 Final BoF Approvals for IETF 116

Amy: I know we had a brand new one drop this morning, and I'm not sure if
that's going to be able to go anywhere. Let's start with the ones we talked
about on the BOF call, structured email. Murray, 50 people for 2 hours?

Roman: My recommendation is 100 people, 2 hours. Don't cut yourself short.

Murray: Okay, let's go with that.

Amy: Next is BPF, is that an okay acronym for this?

Erik K: Yes, that's fine.

Murray: I'd say go up to 100 because that side meeting room was packed.

Amy: Next up is Computing-Aware Networking.

John: Let's make this 100 people and I have an email to the chairs to get any
last minute changes in today.

Eric V: It'll be a WG instead of a BOF then, right?

John: Yes, but right now it's in this funny gray area because the WG isn't
formed yet. If we can just schedule it as a WG meeting that's fine.

Amy: Next up is keytrans.

Roman: Last time it was a little bit up in the air and we structured it to be
non-WG forming. I think we should approve it to proceed.

Amy: Next is VCON. 30 people for 1 hour; is that right? Has this come far
enough for it to be a BOF?

Murray: I think it's come far enough, pausing on the numbers. Where's the
boundary in the number of people to go up in room size?

Liz: Room sizes for Yokohama are 50, 80, 100, 100, 175, 175, 175, 225.

Murray: For VCON let's do 50 people for 2 hours.

Amy: We also have to talk about the acronym for DBOUND. That's a concluded WG
so you're going to have the same problem RADEXT / RADEXTRA has. Do you want to
do DBOUND2?

Murray: Sure, that's fine. Since this is a reconstituting WG I don't think we
need 2 hours. Let's go for 80 people for 1 hour.

Eric V: Are the DNS WGs, like add, dnsop, dprive, in the conflict list?

Murray: I think they are but let me check. I'll add some.

Amy: We'll pull straight from the BOF requests in the Datatracker later today
or tomorrow for the session requests, so please check your conflict lists. Do
we want to discuss this new one before we move on?

Lars: My suggestion is that I take this to gendispatch. I don't think we can
get this in shape for a BOF but it's a discussion the community can have. I'd
prefer it if gendispatch would be given a presentation on what the perceived
issues are and maybe have a side meeting to brainstorm and talk about it more
if they want, so that will basically be my response.

Murray: If I were writing this BOF proposal, I'd say conflicts are all areas.
It'll be interesting to schedule if it gets that far.

Eric V: You mean a plenary discussion?

Lars: That might be where some of it lands, especially if gendispatch happens
to be before the plenary. I would like to see this laid out a little more in
depth than we have in this proposal.

Rob: I think taking this to gendispatch is a good starting point. I also don't
see any urgency here so we don't need to rush to do anything.

Lars: Maybe I'm biased here but a bunch of the community has rotated through
the IESG over the years and nobody has come in with better ideas than this.
We've arrived at some kind of local minimum or maximum and I find it difficult
to believe the broader community will come up with something that will work
better for us, but they can try.

Alvaro: For the record, I think it's very dangerous to let the community try.
They're not doing the job. It's very easy for them to say things like one AD
per area has to ballot on everything. That's easy to implement but the effect
of that on the documents might be who knows what.

Lars: Yeah I agree. But I don't think we should stop the discussion and I'd
like to see it in gendispatch and have the gendispatch chair hopefully give it
some structure.

Rob: Isn't some of this under the remit of the IAB? I know he's trying to focus
it on both but isn't the IAB's remit to have oversight to the process? If so,
wouldn't they also be a good body to have some of this initial conversation
with? This is tricky to unpick.

Lars: It's written hastily and I think it glosses over a bunch of stuff like
that. The IESG and IAB are actually very different and it makes no sense to
talk about them together. But that's just me. Anyway, I'll send an email and cc
the IESG list and you can follow along.

6.2 [IANA #1265971] Designated experts for RFC 9347, ESP AGGFRAG_PAYLOAD
registry (IANA)

Amy: This is just to assign this action item to Roman.

6.3 [IANA #1263515] Designated experts for RFC 8141 (Uniform Resource Names
(URNs)) (Francesca Palombini)

Amy: Francesca has identified Stephanie Palek. Is there any objection to naming
Stephanie as the designated expert for these registries? I'm hearing no
objection, so we'll send an official note to IANA.

6.4 Important Dates for IETF 117 and 118 (Secretariat)

Amy: Liz has sent out a document with proposed important dates for the next two
meetings.

Liz: These are pretty straightforward; it's keeping the same cadence of dates
as we've had for the last few meetings. If you want to change something about
the BOF deadlines, we can talk about changing those; otherwise they're standard.

Lars: They look straightforward to me. I wouldn't complain.

Amy: Any other comments? Okay, we'll put those in the Datatracker. Thanks.

6.5 [IANA #1266560] Designated experts for draft-ietf-lsr-flex-algo-25 (IGP
Flexible Algorithm) (IANA)

Amy: This is to assign an action item to John to find these experts.

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

Lars: You've seen an email Jay sent to the tools list. The Trust has realized
the IETF has wikis. I think they might have been alerted that we've done this
wiki migration to the new platform. The old wikis had no access control at all
and they also had no copyright statement on them. The new wiki has what the
previous Trust told us we should put there, CC BY 4.0 and a note well pointer.
Now they have more concerns like that the note well needed to apply and we also
need to be able to track contributions, which Jay has summarized has some
issues since we have content that we have no attribution for from the old wiki.
There are some things we're going to try to work out. The main point is that
the Trust really needs to have this conversation with the community. The LLC is
trying to stay out of it and the Trust should embrace the community here. That
was my first thing. Second one, Jay has gotten an action item from the LLC to
do a revision of the venue selection RFC, 8718. He checked with Eliot Lear
who's been the editor of that document and they're going to take it to
gendispatch. Sean Turner is there to lay out the financials as the treasurer of
the LLC. Frankly, we're losing money by fulfilling these requirements we don't
actually need. As one example, 8718 requires us to have a help desk person in
the terminal room during all opening hours, and that person is basically bored
to death all week because nobody ever comes, but we still pay for it. There are
a bunch of things in there like that that we would like to get rid of that
doesnt change the quality of the experience all that much. There's one item
where I think some IESG guidance would be helpful and that is when it comes to
what level of filtering are we comfortable with when it comes to the network?
At the moment we're pulling our own fiber, and while we do that, we don't
filter that unless the local regulations force us to. If we rely on more
infrastructure that's already there to reduce costs, we might end up in a place
where some level of filtering is involved. I think the LLC and the NOC would
like to have some guidance in this space, so anyone who's interested maybe
think about it. It might be a good retreat topic. Related to that, the LLC is
going to go to the community and talk about reviewing the meeting fees.
Inflation is a thing and everything has gotten more expensive for us. We
haven't adjusted the revenue side in years, I think the latest was 2015.
There's a proposal to raise some of the meeting fees so that's a heads up.
That's also probably going to be in gendispatch.

Mirja: Is someone from the LLC making a proposal in draft format, or just a
presentation and discussion?

Lars: I think it's going to be on the website. There's a longer google document
that has a bunch of the rationale and financial calculations and a proposal in
the end. I don't know what format it's going to be presented in but it'll
probably be a blog post or something longer. I'm not sure if the plan is to do
it at the meeting or afterwards.

Rob: On the network topic, I'd be interested in having that discussion at the
retreat. I was surprised to learn that the IETF network is basically an
unfiltered view of the internet. I'm not sure whether a lot of people realize
their phones have no firewall protection at the network layer which they
normally would. I do appreciate there's a need in some cases to have some
direct access, but for the majority of people I'm not sure that's what they
need.

Lars: That's a tangential point. This is should we provide a firewall for
people? The conversation we're going to have related to 8718 is: are we
comfortable with using hotel infrastructure that has filtering in place because
the local government requires it? For example in some countries you can't go to
porn sites. If we relied on the local infrastructure that filtering would apply
to us. The question is are we comfortable with that and where is the level.

Rob: I think both conversations are related.

Lars: They're definitely related but different. We'll stick some of these onto
the joint agenda. Which brings me to the last thing: there's an upcoming
meetings wiki page. Feel free to stick topics onto that generously. Mirja and I
will triage those and come up with a schedule and punt some to the retreat.
Finally the retreat, we have a week (May 8-10) in Seattle and Martin is looking
into venues. The one thing to figure out is if it's okay to start Monday
morning or if people are traveling then and wont' have arrived. And do we want
to have dinner with the IAB on Tuesday when they might not be there yet or on
Wednesday when some of us might have flown out. Is anybody not planning to be
there Monday morning? Okay, nobody said they can't be there Monday morning, so
let's start then.

John: I might have a conflict, I'll follow up this afternoon.

Lars: If nobody cares, I guess we'll see what the IAB thinks about dinner.
You'll probably want Wednesday. Another heads up, this AMS social event the
Secretariat hosts on Sunday nights; this time due to availability of stuff it's
going to be Saturday.

Amy: It's also going to be earlier than normal. I think they were looking at a
happy hour type of time but i don't have any other details yet.