Skip to main content

Narrative Minutes interim-2023-iesg-17 2023-08-10 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2023-08-10 14:00
Title Narrative Minutes interim-2023-iesg-17 2023-08-10 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

Narrative minutes for the 2023-08-10 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Amy Vezza, Secretariat

1. Administrivia
1.1 Roll call

Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
ƒric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

Roman Danyliw (CERT/SEI) / Security Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Francesca Palombini (Ericsson) / Applications and Real-Time Area
John Scudder (Juniper) / Routing Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

1.3 Approval of the minutes of past telechats

1.4 List of remaining action items from last telechat


  o Rob Wilton to find designated experts for RFC 9390 (Diameter Group
    Signaling) [IANA #1275381].

Amy: Rob is not here today, so we will keep this in progress.

  o Murray Kucherawy to find designated experts for RFC 9122 on IANA
    Registry for Sieve Actions IANA #1275603].

Amy: This is on as a MI to approve the experts Murray found.

  o Roman Danyliw to find designated experts for RFC 9393 on Concise
    Software Identification Tags [IANA #1275658].

Amy: Roman is not here today, so we will keep this in progress.

  o Paul Wouters to find designated experts for RFC 9420 on
    Messaging Layer Security (MLS) [IANA #1276814]

Paul: In progress.

  o Murray Kucherawy to find designated experts for RFC 9457 on Problem
    Details for HTTP APIs [IANA #1277796]

Murray: In progress

  o Murray Kucherawy to find designated experts for RFC 3326 on The
    Reason Header Field for the Session Initiation Protocol (SIP)

Amy: It looks like the expert wants to step down and has suggested a
replacement. We'll look at this in Management Items and possibly mark
this DONE.


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

Amy: In San Francisco you indicated you wanted to mark this item DONE.

ƒric: On the other side I know a bunch of people got COVID in San

Andrew: The latest news about new variants is worrying.

Lars: Let's not discuss that on this call. This is about mailing list
activity decline due to COVID lockdowns and online meetings.

ƒric: We may want to keep the report around.

Amy: Right this is just the mailing list statistics. And I know the
tools team is working on getting some statistics into the datatracker
for more than just mailing list activity.

Warren: We can bring it back if we need to.

Amy: Yes, we can pull this back out if needed, but this on hold action
item you said should be marked complete.

Mirja: Maybe look at it once a year, before the March IETF? Not just
these statistics but others as well.

Andrew: We want to keep an eye on the statistics, but I agree we don't
need to hold the action item open.

Mirja: So look at it for the Sunday agenda before the March IETF. A
general understanding of how things are, and looking at this would be

Amy: So the action item for Rob and Warren is done and we'll mark it
as such.

  o Warren Kumari to follow up on a bis document for RFC 8126
    regarding designated experts.

Warren: This is in progress.

  o Lars Eggert to send email to the LLC about Letters of Invitation
    for Interim Meetings and Retreats

Lars: This is done.

  o Lars Eggert and Martin Duke to rewrite IESG statement to give more
    guidance about issuing LOIs for interim meetings.

Lars: We have text we're going to look at later. This is also done.

  o One AD from each area to diagram their Area topology and send it
    to Martin Duke for collation.

Martin: This is done.

  o Roman Danyliw to open a Datatracker issue suggesting a feature to
    better signal individual contributions

Amy: Roman is not here today, we will keep this in progress for him.

  o Lars Eggert to ask the LLC to come up with a proposal on how we
    support a pre-configured remote participation option inside
    meeting rooms.

Amy: The Secretariat set up in-room Webex sessions for each side
meeting room, but we were not sure what it was going to look like or
if it would work until the Saturday of the meeting. We will see what
we can do to improve user experience in Prague. I don't know if we've
gotten any feedback on it, but I know people were using it.

Lars: They told me it went well. The intent is this would continue.

Amy: I believe that is right. We've now done it once and worked out
some of the bugs, we'll try to improve for next time.

Mirja: People didn't know about it. The laptop only used the Webex
interface over the browser and if someone closed the browser how to
get it back. So if you could install the Webex app.

Amy: I am sure we have some things to improve. We didn't know how it
would work or if it would work when we got onsite in San Francisco. So
it was a lot of experimenting with the in-room audio.

  o Lars Eggert to write an update to the Support Documents in IETF
    Working Groups statement.

Lars: This is in progress. I'll circulate the statement and we'll
bring it back for discussion.

  o Murray Kucherawy to respond to the email "RFC 1952: Any plan for a
    new extra field registry."

Murray: Yeah, I responded to this, so done.

  o John Scudder to collect AD qualifications for NomCom.

Amy: John sent email that this was sent to the NomCom Chair so we'll
mark this as done for him.

  o Andrew Alston, Murray Kucherawy, Zahed Sarker, Martin Duke, John
Scudder, and Jim Guichard to draft text regarding document
authorship/editorship with regards to the number of authors listed.

Andrew: There has been no progress yet here. I'll start an email
thread, this is in progress.

ƒric: I saw the upcoming TEAS document has seven authors listed and I 
do not mind that since there is a good reason.

Andrew: I agree. There are exceptions.

  o Lars Eggert to facilitate a community discussion on priorities for
IESG processes.

Lars: We're starting the discussion today. This is in progress.

2 . Protocol actions
2.1 WG submissions
2.1.1 New items

o draft-ietf-bess-evpn-pref-df-11
(Preference-based EVPN DF Election)
Intended status: Proposed Standard
Token: Andrew Alston

Amy: A couple of discusses.

Andrew: Nothing in particular to discuss.

Amy: Moves to substate Revised ID Needed. Thank you.

o draft-ietf-nvo3-bfd-geneve-12
(BFD for Geneve)
Intended status: Proposed Standard
Token: Andrew Alston

Andrew: This needs a revised ID. I want to see what the late discuss
contains, but John's should be fairly straightforward. I'll follow up
with the authors.

o draft-ietf-idr-long-lived-gr-06
(Support for Long-lived BGP Graceful Restart)
Intended status: Proposed Standard
Token: Andrew Alston

Amy: No objections, looks like this is approved.

Andrew: Nothing else required.

Amy: Approved, announcement to be sent. It will be sent on Monday as

o draft-ietf-uta-rfc6125bis-14
(Service Identity in TLS)
Intended status: Proposed Standard
Token: Paul Wouters

Amy: Has a discuss.

Paul: No need to discuss.

Amy: Okay, so we'll add a substate of Revised ID Needed and move on.

o draft-ietf-bess-pbb-evpn-isid-cmacflush-08
(PBB-EVPN ISID-based C-MAC-Flush)
Intended status: Proposed Standard
Token: Andrew Alston

Amy: No discusses here.

Andrew: I want a revised I-D for the comments.

Amy: So approved, announcement to be sent, revised I-D needed.

o draft-ietf-dnssd-update-lease-08
(An EDNS(0) option to negotiate Leases on DNS Updates)
Intended status: Proposed Standard
Token: ƒric Vyncke

Amy: No discusses.

ƒric: We need a revised I-D.

Amy: Approved, announcement to be sent, revised I-D needed.

o draft-ietf-dnssd-srp-23
(Service Registration Protocol for DNS-Based Service Discovery)
Intended status: Proposed Standard
Token: ƒric Vyncke

Amy: This one has discusses, but one of the discuss holders is not
here. Do you need to discuss with the other?

ƒric: I see the author has replied, do you need to discuss it?

Paul: I only just got the reply. I think we're mostly in agreement,
but I want to read it more carefully, because it feels like a hand
wave, I'm right kind of response.

ƒric: But the dialog is started. So we can say revised I-D needed.

o draft-ietf-lamps-caa-issuemail-06
(Certification Authority Authorization (CAA) Processing for Email
Intended status: Proposed Standard
Token: Roman Danyliw

Amy: The discuss was cleared, so this will go into approved,
announcement to be sent, and since Roman is not here today we'll add
the substate of AD Follow-up so he can make sure anything outstanding
is addressed before we send the announcement.

3 . Document actions
3.1 WG submissions
3.1.1 New items

o draft-ietf-teas-rfc3272bis-26
(Overview and Principles of Internet Traffic Engineering)
Intended status: Informational
Token: John Scudder

Amy: There are no more discusses on this document so it will go into
approved. John also couldn't be here today so we're going to add the
AD Follow-up so he can do final checks.

o draft-ietf-teas-ietf-network-slices-22
(A Framework for IETF Network Slices)
Intended status: Informational
Token: John Scudder

Amy: This has discusses. John isn't here to discuss it.

Paul: This is pretty straightforward. I just want to see if everyone
was okay with the document calling it an "IETF network slice." I guess
it is to distinguish it from a vendor network slice. Are we okay with
something being termed an "IETF" something? It's sort of weird. I'm a
little concerned here, but we're also very late in the process, I'm
not sure.

Warren: I'm also fairly concerned about it. I don't think it's just
saying we don't mean other people's network slices. It might seem like
we're pushing to supporting this.

Paul: There is also a VPN document that is a draft that says we mean
slices but we'll call it network slice in the document so it sort of

Andrew: I think the wording may be wrong, but the sentiment is not. We
saw it with the QUIC stuff where you started to see the Google version
vs. the X version, and it needed to be differentiated between the two.
So I see your point, but I also think we need to distinguish between

Warren: For QUIC, Google version of the protocol was first and Google
brought it to the IETF and said "go take this over and do whatever."
And we worked on it, there were a bunch of proponents who came along
and pushed really hard for it, too. For Network Slicing, I think this
had four or five side meetings, and their scope was incredibly broad.
They may have had a BoF or even two where there was a strong push for
a WG, so there is a lot of sensitivity here.

Andrew: There is a need to differentiate so people know what they are
talking about. I think it needs a wording update, I'm just not sure.

Erik: I don't agree. This is a network slice, and it's definition is
basically looking at only IETF-related technologies. The document is
just saying these are our technologies and we think that constitutes
us to define it for the IETF.

Mirja: In the QUIC example, it doesn't differentiate between IETF QUIC
and Google QUIC in the document.

Lars: Thinking about this now, I think there is a way forward for it
to give a definition of network slices and when other documents was to
refer to the IETF definition they just cite it.

Erik: Others may have a different definition of a network slice.

Lars: Yes, but they would refer to their own definition and not the
IETF one.

Paul: I'm also concerned that there are different IETF technologies
that could be considered a network slice because we have so many
different ways of doing things.

Zahed: QUIC we didn't use Google QUIC or IETF QUIC, so I'm not sure
this is a good analogy. For network slices everyone has their own
definition. Other SDOs have their own definitions, so calling it an IETF
Network Slice makes sense to me. So Lars' suggestion to give a
definition and refer to it makes sense to me.

Warren: I am also surprised to see this here. Does this fall within
the charter for TEAS? It feels like it just popped up here, and maybe
that is fine. It just made me blink.

Andrew: I feel like we should discuss this when John is here. And
maybe the chairs.

ƒric: We can defer it two weeks to make sure it is on the agenda.

Warren: The term IETF Network Slice shows up something like 326 times
in the document.

Paul: It would be so much shorter if we remove 325 words.

Warren: They are defining what an IETF network slice is.

ƒric: I think both the authors and chairs should be there.

Amy: I will put in revised I-D needed.

ƒric: Can you hit the defer?

Amy: One of you can, sure. But it seems weird to defer it after all of
this discussion. I can just move it to the next agenda for John so it
will come back as a returning item.

Andrew: I think moving it and having it come back as a returning item
is the more sane option.

Amy: Okay, this will come back on August 24. Hopefully John will be
okay with the move. He could remove it from the telechat at anytime.

3.2 Individual submissions via AD
3.2.1 New items

o draft-gutmann-testkeys-04
(Standard PKC Test Keys)
Intended status: Informational
Token: Paul Wouters

Amy: No discusses, and I hear no objections, so this one is approved.

Paul: Please put it in AD Follow-up. I want to make sure there are no
minor changes needed.

Lars: After the document, we got a vulnerability report because
someone found an RFC that had private keys in it as test cases. So I
wonder if some text is needed to state this is an example only.

Warren: Many of those are automated alert things.

Paul: Okay, I'll look at that.

Amy: Okay, approved announcement to be sent, AD follow-up.

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

o conflict-review-irtf-icnrg-icntraceroute-00
(IETF conflict review for draft-irtf-icnrg-icntraceroute)
(ICN Traceroute Protocol Specification)
Intended status: Experimental
Token: Roman Danyliw

Amy: Roman did the RFC 5742 review for this document but I have a

Lars: Martin seems to want to synchronize the responses.

Martin: Right, the two ICNRG documents were reviewed by two different
people. The documents are so similar, I think the review response
should be the same. I prefer ƒric's review naming the IPPM and

Zahed: I think I also prefer ƒric's review.

Lars: I can change Roman's review. I can also just take the conflict
review and change it that way. I don't think Roman will mind.

Amy: Okay, so with the cleared discuss, this is approved for the no
problem message to go back to the IRSG.

3.4.2 Returning items

o conflict-review-irtf-icnrg-icnping-00
(IETF conflict review for draft-irtf-icnrg-icnping)
(ICN Ping Protocol Specification)
Intended status: Experimental
Token: ƒric Vyncke

Amy: And for this one, it is also approved and the no problem message
can go back to the IRSG. We'll move on.

4 . Working Group actions
4.1 WG creation
4.1.1 Proposed for IETF review (1 of 1)

o WG name: Key Transparency (KEYTRANS)
Charter: charter-ietf-keytrans-(00-11)
Area: SEC (Roman Danyliw)

Amy: I have a block in the tracker that seems like it is for some
editorial nits?

ƒric: Right. It's for the work items and what status they will be,
that's it.

Amy: We will wait for instructions from Roman for KEYTRANS.

5 . IAB news we can use

Amy: Any news?

Mirja: We talked about two IAB statements really just very new so not
much to report. We discussed the two proposed programs, Identity
Management and the Impact programs in case you are interested. And one
important news, we got accepted to the session for the IGF.

Lars: Anyone from the IESG going to be there?

Warren: What are we going to say there?

Lars: Its an overview of the IETF, since no one there knows what we

Mirja: I got feedback that we need to make it more fancy than just a
bland overview so maybe with a technical topic to draw people in and
introduce the IETF and our process. A couple from IAB, Colin will be
there. Maybe Andrew can join remotely. So a general panel discussion
and then a Q&A at the end.

Warren: They are used to a formal system, that the IETF sounds loosey
goosey. Having people take away that the IETF process has worked for
forty years.

Mirja: That is exactly the message we want to bring there. Not that
rough consensus is difficult, but that we do have processes we follow.

Lars: We need to see draft slides to review on an informal call. Here
is how it works, here is how it works, and here is the work we've done
for a long time. I don't think it needs a technical topic.

Mirja: We want something more than let's introduce you to the IETF.

Warren: We want to have something to respond when people ask why we
keep encrypting everything which breaks their national security.

Mirja: We want to align on what we say.

Warren: Yes. I think the whole point is to get the messaging very
carefully worked out.

Lars: Do you know if Vint is going?

Warren: Yes, he will be there.

Lars: If he were on the panel he would draw a crowd.

Mirja: Yes, Mallory has reached out to him already.

Lars: We'll put it on an informal to look at the slide deck.

Mirja: Andrew we reached out to participate, right?

Andrew: Yes.

Lars: I don't know if we mentioned this is the Statement Mallory and
Paul are crafting, it's going to be circulated with the IESG before it
goes out?

Mirja: It needs a lot more work. We'll bring it to the IESG if it
needs to be a joint statement.

6 . Management issues
6.1 [IANA #1276814] Designated experts for RFC 9420 (Messaging Layer
Security (MLS)) (IANA)

Amy: We've assigned this action item for Paul, a whole bunch of
registries for the one document.

6.2 [IANA #1275603] Designated experts for RFC 9122 on IANA Registry
for Sieve Actions (Murray Kucherawy)

Amy: Murray has identified two people - Alexey Melnikov and Ken
Murchison to be the designated experts for IANA. I hear no objections.

6.3 management item for DTN registry statement (Erik Kline and Zahed

Zahed: We don't need to discuss today. We're still discussing this on
the DTN mailing list. Maybe next time when the document is on the

Amy: We'll keep this on for next time, August 24.

6.4 Starting a Community Discussion on Priorities for IESG Processes
(Lars Eggert)

Lars: This is a follow up to the discussion that happened in
GENDISPATCH. Two different discussions, one on Rich's and Adrian's
document for making less work for the IESG and Mark had a draft on
taking our IESG Statement on discuss criteria and making that an I-D.
They're sort of similar in that they indicate the community wants to
express more concretely what the IESG should be doing internally. I'm
not planning to take any of these documents forward, and I'm not
planning to charter a WG for it yet either. But I think a discussion
on what they actually expect area directors to prioritize would be
helpful. We may find the community wants us to prioritize document
review over anything else, or that we should do something else other
than working with management or what have you. My expectation is they
will realize they don't have any consensus on what we should be doing.
I think for the moment we have a very few people who have not
overlapping ideas of what the IESG should be doing and I don't think
we've heard from the vast majority of the community. Some may even
think we're doing a good job. So I'm trying to figure out a forum to
have the discussion. I think it would be a good non-WG forming BoF,
but getting the right person to craft the bulk of the proposal that is
acceptable to us is a big hurdle. Anny feedback is welcome.

Mirja: Did you just say you wanted to start a BoF proposal?

Lars: No, I'm not going to draft the proposal, it should come from
someone else.

Andrew: I like the idea of telling them to propose a non-WG BoF,
because it means if they want to have the discussion, they need to do
the work.

Lars: I briefly talked to Jari and he wouldn't be opposed to being one
of the facilitators of that BoF. He has long experience on the IESG
but is no longer on a leadership body. But someone else would have to
write this description. None of the three presenters have talked to me
about this, but if they talked to any of you, please let me know. My
fear is that we're going to get some last minute thing we can't get
into shape and then it will get rejected and people will yell at us
for it.

Andrew: I talked to Adrian quite a bit so I can can have a chat with
him and see where he is here.

Lars: That would be good. Do some thinking abd come up with a
proposal. It'll be a pain to schedule, but that's a given. Long
document queues seems to be an Adrian aspect, Rich is more like we
don't have enough candidates for AD positions and that is because it
is so much work. There are all sorts of differeing opinions on what the
problem is.

Andrew: Recently Adrian said something strange to me that we are
spending too much time on the small issues. If we're reading a
document and get two pages in and it is garbage we should send it back
to the working group and move on. Do more exercising the right to
return thn making them sit with us trying to resolve the issues.

Amy: Please note that the BoF submission deadline is September 8th, so
one month. I know it seems very early, but we have one or two fewer
weeks between 117 and 118 than we usually get. We have only just
opened session requests.

6.5 Appeal Discussion and updated Statement (Martin Duke and Lars

Lars: This updated statement basically came out of a discussion with
Ted and Alan about their appeal while we were in San Francisco. They
consider their appeal addressed. I propose we approve this, and Greg
puts it up on the Web site and we announce it and I will send a reply
to the appeal saying that this addresses the appeal.

[Discussion of document points, and small edits to the text were made]

Amy: So it sounds as if the IESG has approved this revised Statement
and it will be posted and announced.

6.6 Friday Afternoon Sessions for IETF 118 (IESG)

Amy: This began as a discussion at 117.

Lars: I think the proposal was we'd use the Friday afternoon session
for groups that want more than two sessions?

Amy: The discussion centered on using the Friday afternoon as a
regular session for anybody.

Lars: We will get the backlash that no one wants Friday afternoon. I
thought we wanted to do an experiment with overflow time.

Warren: I don't see giving a Friday afternoon slot to someone who
requested one session. I think the experiment can be for those who
request more than one.

Lars: Do we know how many groups ask for three sessions or more?

Amy: Liz would know, but she is on PTO this week.

Lars: Lets give ourselves an action item to figure out what the
experiment is, and we will use Friday afternoon for the experiment.
Whether it is open scheduling or if we want to restrict it in some

Warren: We can try to front load with all the sessions that want more
than two and if we have to put others there we can.

Mirja: I think the point is we can add a third session to Friday
afternoon but it should try to deconflict if possible.

Warren: We should let the community know as soon as possible. So they
don't make early flights.

ƒric: We can put a warning on the Web page as well.

Jay: We can tell people when we open registration which will be any
day now.

ƒric: Yes.

Andrew: We need to clarify if we're going to tell people we've got
meetings on a Friday afternoon. Also will the post review happen
Saturday morning?

Lars: No after sessions Friday at 5.

Amy: One of the things you discussed was having the Friday IAB/IESG
wrap-up during the 90 minute lunch break, before the last sessions.
You seemed to be leaning in that direction the last time this was
discussed, so I don't know if that is still on the table or if you
definitely want to do it after sessions would end.

ƒric: We'd miss reviewing half the day.

Amy: So it sounds like the discussion for this is ongoing. We don't
know what the time will look like but it sounds like Friday afternoon
sessions are a go, so we'll make sure Liz and the NOC know this. We'll
make sure it gets into the messages about 118 as well. I think we're
on track to open registration the week of the 14th, so next week.

6.7 [IANA #1277796] Designated experts for RFC 9457 on Problem Details

Amy: This was just assigning this action item to Murray to find experts
for IANA.

6.8 Downref in the Extra Last Call for draft-ietf-ohai-ohttp (Murray

Amy: When the document came back from the RFC Editor and went into
another, extra Last Call, it went out with a brand new normative
downref. I believe the downref it to an IRTF document.

Murray: Ther eis no contention of the issue that pulled this back from
the RFC Editor, but we have to process the downref to say whether it
should be added to the registry. I think it should be added.

Amy: So when this document goes back to the RFC Editor, we will add
RFC 9180 to the downref registry.

Paul: I think there is an MLS document that has a downref to that as

6.9 [IANA #1278422] Designated expert for RFC 3326 (The Reason Header
Field for the Session Initiation Protocol (SIP)) (IANA)

Amy: So it looks like IANA and Gonzalo have done all the work for
Murray here. Gonzalo would like to step down, and Christer is willing
to step up, and all it needs is an okay from you, Murray, and no
objection from the IESG. Any objection to replacing the current expert
with the suggested expert? [no objections] Okay, we'll let IANA know,
and mark that action item as done for you, Murray.

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

Amy: Another reminder the BoF deadline is September 8. Also anyone on
the interview team for the RSWG chair, if you have not already please
fill out the strawpoll so we can get these scheduled.

Warren: Something Wes and I are planning on doing the DNSSEC list of
what algorithms are recommended are in an RFC, and we're going to
write a document to move that to an IANA registry. So the canonical
place for something should be in a registry instead of an RFC. I am
mentioning it as an idea.

Paul: I tried to put it there initially, but people were against it in
the DNS community. But we do it in TLS and do it IPSEC, we should do
it in DNS.

Warren: We'll work on a draft.

Mirja: The support document statement, should go on the next informal?

Lars: I think the next formal to minute approval. I mean, it's short.
It's also not super critical.

Amy: Thanks all! Have a good rest of your day.