Skip to main content

Narrative Minutes interim-2024-iesg-09: Thu 14:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2024-04-18 14:00
Title Narrative Minutes interim-2024-iesg-09: Thu 14:00
State Active
Other versions plain text
Last updated 2024-05-02

Narrative minutes for the 2024-04-18 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Jenny Bui, Secretariat

1. Administrivia
1.1 Roll call

Jenny Bui (AMS) / IETF Secretariat
Deb Cooley / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
David Schinazi (Google) / IAB Liaison
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Applications and Real-Time Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

Jay Daley / IETF Executive Director
Warren Kumari (Google) / Operations and Management Area
Tommy Pauly (Apple) / IAB Chair

Greg Wood

1.2 Bash the agenda

Liz: Does anyone want to add anything new to today's agenda? I know we had a
couple of late designated experts to approve, so we've got those at the end.
Any other changes?

Paul: If we have time at the end, I wouldn't mind talking briefly about
reviewing mailing lists.

Liz: Ok. We can get that at the end.

1.3 Approval of the minutes of past telechats

Liz: Any objections to the minutes of the April 4 teleconference being approved?

Hearing no objections so we'll call those approved and put them in the public

Does anyone have any objection to the narrative minute of the April 4th being

Hearing no objections there either so we'll also get those posted.

1.4 List of remaining action items from last telechat


        Last updated: April 16, 2024


     o Murray Kucherawy to find designated experts for RFC 9422 (SMTP Server
       Limits) [IANA #1358457].

     o Murray Kucherawy to find designated experts for RFC 9530 (Digest
       Fields) [IANA #1359278].

     o Murray Kucherawy to find designated experts for RFC 9535 (JSONPath:
       Query Expressions for JSON)[IANA #1359744].

Liz: Murray, you have three of them here, and I know we have approvals for two
of them already and this morning you sent one more, did you want to actually
approve the names for the Digest Fields or are we still waiting?

Murray: That working group hasn't answered me. The shepherd write up suggested
using the authors of the document and I want to confirm that they're prepared
to do that. I have no action on that one, but the other two are resolved.

Liz: Ok great, so we're not ready to approve anyone yet for the middle one, but
we've got items at the end of the agenda for the first and third to be approved.

Roman: Can we do an executive session on the third one? I sent an email before
we decide.

Murray: Sure, let me go find your email. I didn't see it yet.

Roman: Because I said it like 45 seconds ago.

Murray: Sure, let's do that.

     o Orie Steele to find designated experts for RFC-ietf-calext-jscontact-16
       (JSContact Properties)[IANA #1361734]

Orie: In progress, i'm just now understanding what finding designated experts
mean in terms of the list processing.

     o Eric Vyncke to find designated experts for RFC 9508 (Information-
       Centric Networking (ICN) Ping Protocol Specification) [IANA

Liz: We have an management item at the end of the agenda to approve a couple of
experts so this one is provisionally done.

     o Orie Steele to find designated experts for RFC 9536 (Registration
       Data Access Protocol (RDAP) Reverse Search) [IANA #1363176].

Liz: You have a brand new one today to find experts for 9536, so just you know
you have two action items here now.


     o Roman Danyliw and Warren Kumari to 1) draft a revision of RFC 4858,
       2) draft a revised IESG Statement on Document Shepherds (original
       statement October 2010), and 3) update the WG Chairs wiki to point
       to the new IESG Statement.

Roman: Warren and I are still in progress.

     o Jay Daley, Dhruv Dhody, Éric Vyncke, Orie Steele, Mahesh
       Jethanandani, Gunter Van de Velde to form a design team to gather
       community feedback about meeting in China.

Eric: Still in progress, we got a very fruitful meeting at least in my opinion,
probably in two weeks or something that we will come back to you with the

     o Francesca Palombini to come up with a v2 proposal for trying
       ALLDISPATCH again at IETF 120.

Francesca: In progress, there was a meeting with the ALLDISPATCH chairs and I
need to go through the feedback.

     o Paul Wouters to open up an issue with the Tools Team asking for
       IANA to be notified about document state changes.

Paul: In progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ipsecme-ikev2-auth-announce-09  - IETF stream
   Announcing Supported Authentication Methods in IKEv2 (Proposed
   Token: Roman Danyliw

Liz: We don't have any discusses so unless there's an objection now, this
document is approved.

Roman: I want to thank everyone for their reviews. I think, Paul, you were
going back and forth and have some changes that I promised for you.

Paul: I just okay the changes, actually. So one is that had to be done with
this IANA registry was renamed so the document needs to update that. There was
one other sentence on the next part which Valerie found a good one. Put it in
revised ID needed.

Roman: Did anyone else want to comment? I have not gone through everyone's
feedback and did not have see whether Valerie had worked them. Sorry, I
interrupted the are there any objections part.

Liz: There was a pause, I didn't hear any objections so I think we're good to
go. So this is approved with a revised ID needed?

Roman: Approved announcement to be sent, revised ID needed. Thanks.

 o draft-ietf-rtgwg-segment-routing-ti-lfa-13  - IETF stream
   Topology Independent Fast Reroute using Segment Routing (Proposed
   Token: Jim Guichard

Liz: We got a couple of discusses, do we want to discuss it now?

Jim: No, I don't think so, there's a lot of comments from both Gunter and John
which we need to some some responses from the authors so nothing really to
discuss unless John or Gunter have anything they want to bring up.

John: I'm good.

Jim: Revised ID needed.

Liz: This is staying where it is in IESG evaluation: revised ID needed.

Jim: There's quite a few changes needed.

 o draft-ietf-sidrops-cms-signing-time-07  - IETF stream
   On the use of the CMS signing-time attribute in RPKI Signed Objects
   (Proposed Standard)
   Token: Warren Kumari

Liz: There's no discusses in the Tracker so unless there's an objection now,
this document is approved.

I'm hearing no objections so this is approved.

Warren is not here so we'll move it to approved announcement to sent: AD
follow-up, in case Warren had anything else he wanted to do with it before

 o draft-ietf-jmap-sharing-09  - IETF stream
   JMAP Sharing (Proposed Standard)
   Token: Murray Kucherawy

Liz: We did have a discuss, but we don't have one anymore so unless there's an
objection now, this document is approved.

Murray: No, we're good to go here unless someone wants to talk about it, but
please give me AD follow up on this one.

Liz: Approved announcement to be sent: AD follow up.

 o draft-ietf-lamps-rfc5019bis-08  - IETF stream
   Updates to Lightweight OCSP Profile for High Volume Environments
   (Proposed Standard)
   Token: Roman Danyliw

Liz: We do have a discuss here, do we want to discuss it now?

Roman: No, it makes sense. I was relying on IDNITS to catch that with the
metadata were set right so we should get the right boilerplate there.

Erik: That depends on whether or not the Trust thinks the rights have already
been assigned or not.

Roman: Yes, I did not see any discussion on that in the shepherd write up. I
will dig into that.

Erik: I had this come up in some of my documents and had to email Glenn.

Paul: Sorry, does that mean you ask the authors of the original document if
they are basically giving their rights to the IETF and is there a paper trail
for that?

Erik: The IETF LLC maintains that paper trail.

Paul: I didn't know you could do that.

Roman: We should check, so keep your discuss. Can we keep it in revised ID
needed? Regardless of whether we change the boilerplate or not. There's
somethings in the comments that would benefit from the emerge.

Liz: This will stay in IESG evaluation: revised ID needed and Roman, just a
heads up for you we are going to ask if you want to add this to the down ref
registry. If you already know the answer now, this is for RFC 9500 Standard
Public Key Cryptography Test Keys.

Roman: Let me take a look at that offline.

2.1.2 Returning items

 o draft-ietf-mediaman-toplevel-05  - IETF stream
   Guidelines for the Definition of New Top-Level Media Types (Best
   Current Practice)
   Token: Murray Kucherawy

Liz: Unless there's an objection now, it looks like this one is approved.

Sandy: I don't have an objection, but I do have a quick question. This one in
the references, there's an information reference to Media Man Haptics, but it
looks like they want a placeholder. It says RFC YYYY.  Do you know if this
should be published with that document?

Murray: That one has been approved and i've been holding it waiting for this
one, so yes, we should do them as a cluster. That was what I was emailing you
about, actually, this is the one.

AD follow up, please and i'll make the appropriate notation so that's all clear
when it goes through.

Liz: This will be approved announcement to be sent, AD follow-up.

 o draft-ietf-taps-interface-26  - IETF stream
   An Abstract Application Layer Interface to Transport Services
   (Proposed Standard)
   Token: Zaheduzzaman Sarker

Liz: There are no discusses so unless there's an objection now, it looks like
this is approved.

Ok, we'll call that approved. Zahed, is this ready to go or do you want to do
anymore updates?

Zahed, are you still with us?

(Zahed audio wasn't working)

Francesca: He doesn't seem connected to audio or at least I don't see the
microphone muted.

Roman: If we don't have him, we should just put it in AD follow-up.

Liz: This one will be approved announcement to be sent, AD follow-up.

(few minutes later)

Zahed: Can you hear me now? On my returning document, I have some questions if
we have time. I'm waiting for this is going to get approved with AD follow up
because there are other two documents that go along with that. All of them are
ready and approved by me? What do I do? Can we do all three documents together?
I have two other documents, Architecture and Interface that are also ready so
we can approve and send that out. I want them to be sent out together.

Paul: What are the status of the other documents?

Eric: I had the same thing for two DNSSD documents and one was waiting for 6
months on my queue before everything was approved, I simply waited to put them
together because they were a cluster.

Zahed: So do I need to do the documents separately or can just an approval
notice together?

Cindy: If the other ones are in some sort of approve AD follow-up state, if you
change the state in the Datatracker to be approve announcement to be send, that
will notify us to send the announcement for it. Just make sure the state in the
Datatracker is approved announcement to be sent for all of them with no
substate and then we'll get them sent.

Zahed: I'll do that now.

Eric: You want to send an email with the RFC editor that those three should be
read together.

Roman: That's exciting news. When they are approved and with the RFC editor, 
are you shutting down TAPS?

Zahed: I'm not shutting down TAPS right now, TAPS will be there until they're
all cleared out. When this process of AUTH48 is done, i'll shut them down.

2.2 Individual submissions
2.2.1 New items


2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items


3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items


3.4.2 Returning items


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

 o Secure Patterns for Internet CrEdentials (spice)

Liz: Is this ready for external review? We don't have any blocking comments.

Paul: I think so, in the beginning there were a few minor word changes that
people agreed to during the BoF but then we did a call of charter version 3+1
and those kind of changed from those few keywords were dropped so there was
some talk between some people on that, but I think I convinced them that those
words are not very important and we should stick to the voting result or the
consensus results we had at the end of the BoF meeting. They still have a
chance to comment in the public period so we should be fine. I think we're good
to go ahead.

Liz: Is this ready to go as is or do you want to review one more time?

Paul: I'll look over the comments.

Liz: We'll leave this for you and you can let us know when it's ready to be

 o Mail Maintenance (mailmaint)

Liz: Does anyone have any objections for this one being sent for external

Murray: Deb, I replied to your comment. I hope that satisfies your questions I
have wanted it to make based on Eric'd comment then this will be ready.

Deb: So mine is fine, feel free to call me an idiot if you want to.

Murray: Not in front of everybody.

Liz: This is approved, but Murray you'll take a little time with it?

Murray: You'll get it later this morning.

4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Roman: John, wasn't able to rely to join the meeting so i'll rely on Paul,
Tommy, and David to help me out. A couple of things I remember hearing and the
SEC ADs kind of know this, we had conversation on how the ISE is going to
engage the community on less reviewed crypto and we got his attention was
called to an FCC. I'm not sure what the right legal term is for a filing kind
of notice that's related to BGP and net neutrality kinds of topics.

John: Proposed rulemaking or before the proposal rulemaking anyway?

David: It's in the early days of them regulating Internet things and they're
talking about if we mandate BGP SEC and DNS SEC and all sorts of broken ways.
ISOC wrote a very good document on why it's a bad idea. The ADs in the loop,
we're not going to do anything at this stage but later in the process if they
end up continuing in this direction, we'll probably write an IAB letter. I
think that's all I remember that will be relevant to the IESG from yesterday's

Roman: I think that's the news we could use.

6. Management issues

6.1 [IANA #1358457] Designated experts for SMTP Server Limits registry (RFC
9422) (Murray Kucherawy)

Liz: Any objections to approving these two designated experts? Hearing no
objections so we'll call these approved and get that official note to IANA.

6.2 Executive Session: [IANA #1359744] Designated experts for [RFC 9535
(JSONPath: Query Expressions for JSON)] (Murray Kucherawy)

Liz: We wanted to take this is executive session so we'll take it at the end.

Roman: Murray and I have been chatting.

Murray: Can we split this one? This is backwards actually, it's Glyn as primary
and Carsten as backup. Can we approve Glyn first and we'll do the rest in
executive session?

Liz: Ok, this is to just approve Glyn Normington as the designated expert for
this registry. Any objections?

I'm hearing no objections so we'll approve Glyn and send that official note to
IANA and we'll come back to this at the end.

6.3 Additional Designated Expert for OAUTH Registries (Paul Wouters)

Liz: Paul has designated Mike Jones as the designated expert for this registry,
are there any objections?

I'm hearing no objections so we'll call this as approve and we'll send that
official notice sent to IANA.

6.4 [IANA #1360711] renewing early allocations for draft-ietf-pce-multipath

Liz: John, do you have a comment here?

John: The PCE chair told me that the document is going to be going into WGLC
soon so I would like to renew.

Liz: Ok, any objections?

I'm not hearing any objections so we'll call this approved and send that
official note to IANA.

Roman: Thanks for checking in with the working group chair, John.

6.5 approving Important Dates for IETF 122 (Liz)

Liz: We have the proposed important dates here, pretty much all standard except
to avoid the end of year holidays. We need to move registration and scheduling
a little earlier into December and we could make working group scheduling
probably one week sooner. If you guys want. Any comments, objections, questions?

Ok, i'm not hearing any objections so we'll just approve these are they are and
we can always choose to move this earlier, if we want after they're published.

6.6 [IANA #1362761] renewing early allocations for draft-ietf-6man-comp-rtg-hdr

Liz: This is one of Erik Kline's documents. I think this document is already in
Last Call now, is there anything you want to talk about?

Erik: No, I was going to say that this is the document that people might now as
CRH, if you remember from a long time ago. It's in WGLC now and I haven't been
paying attention to see how pretentious it is or what's happening but if
there's not too many comments then it'll be coming to a telechat to you soon.
Possibly even before the date expires depending on how it takes.

Liz: Any objection to approving this early allocation renewal?

Hearing no objections so we'll call it approve and send that official note to

6.7 [IANA #1362759] renewing early allocations for

Liz: This is another one of John's documents.

John: This is kind of funky in that the reference is to an expired draft. The
reason for that is the working group decided to refactor that into two other
drafts but I guess the reference didn't get updated. The two other drafts have
passed WGLC. The chair tells me that it should be in my queue soon so we should

Liz: Any objections to renewing?

Francesca: No objections, but can we update the reference to not point to an
expired draft?

John: Yeah, for sure.

Liz: Sabrina, do you need anything for us about updating the reference?

Sabrina: No, we'll update that.

Liz: Great. This early allocation renewal is approved and we'll send that
official note to IANA.

6.8 Approving designated experts for RFC 9508 (Information-Centric Networking
(ICN) Ping Protocol Specification) [IANA #1361078] (Éric Vyncke)

Liz: Eric has identified Hitoshi Asaeda and David R. Oran as experts for this
registry, any objections to approving them?

Ok, hearing no objections so they are approved. Thank you again, Eric for
volunteering to take this action item.

6.9 [IANA #1363176] Designated experts for RFC 9536 (Registration Data Access
Protocol (RDAP) Reverse Search) (IANA)

Liz: This is the new item for Orie, just make sure you got all the details for
this. These are details of your new action item.

6.10 Add IANA experts to IDNA Derived Properties registry (Francesca Palombini)

Liz: This is adding Takahiro Nemoto and Peter Saint-Andre to this registry, any

I'm hearing no objections, so they are approved and we'll send that official
note to IANA.

6.11 Review Mailing Lists (Paul Wouters)

Paul: We had an issues coming up where one of the RFCs was supposed to create
the SSH registry review list and it didn't happen. Nobody noticed for
a while until some people tried to register or try to submit something to the
delegated experts and they couldn't find it so we got that point fixed but
while doing that, I figured, we have seen in the past some of these review
registry addresses only have old email addresses that no longer work. So avoid
that with the SSH1, what I did was added SEC ADs to the membership list and
actually removed myself because whoever created the list added me personally so
I just made it the experts plus the ADs of the area. I was wondering if that
would make sense to do as a standard practice to avoid these issues in the
future and maybe review all the current designated expert review list to make
them in sync with a policy like this.

Francesca: My question is, is there an easy way to find all this review mailing
lists? I know there is at least the IETF non-working group mailing list, but
how to filter?

Paul: I don't know, don't they all end with -review? Is that happy thinking?

Francesca: I think that's happy thinking.

Paul: It's a tooling problem, let's put the implementation separate from the

Francesca: Otherwise, yes. It sounds like a good idea.

Zahed: Is this a problem? Because as a reviewer I can just not assign anything
to me.

Paul: There's more to know that the Security AD knows that, for instance,
there's no one taking action on it. They at least get the initial submission as
well so they can ping the delegated expert and then maybe find out that the
email addresses don't work anymore because we don't have no other good way to
finding this out. This is just the latest occurrence of this project, we've had
in the past people said "i've mailed the designated experts" and no one was on
it because we had one empty list, there was no one on the mailing list.

Orie: Wearing an AD hat, I love to have the AD email added to any list i'm
responsible for so that I can see things when they come in and decide if
there's any need to follow up. I wouldn't want to be added as an individual
because that would persist beyond.

Paul: Exactly, that's why I fixed my answer. The only thing that has to be
cleared is that the AD do not have a say about the delegated expert review,
right? They're not there as review members, they're there as managers.

Zahed: I agree, I think AD should be added there instead of personal.

John: It seems kind of reasonable, but I have a question fro Sabrina probably,
how much of a problem is this is in reality and is it kind of self correcting
but with a little extra latency? Like I would have imagined that the process
would be, you request the expert to do something, they don't do something, they
don't do something. Eventually, you time out and ask the AD to fix it. Am I
wrong? Is this not how it works already?

Paul: I can answer that in one occurrence where that definitely did not work
because some not familiar with the IETF reads the RFCs and sees the email
addresses mails it and gets no response and thinks that the IETF doesn't care
about me.

John: They directly contact the experts instead of putting the request through
IANA and then having IANA to contact the experts.

Paul: Yeah, the RFC says to mail to this list.

John: That seems like a bug, seems like the real solution here is having the
request go to IANA and have IANA ask the experts.

Sabrina: For a lot of these registries there is a little note section there for
assistance, they can contact us. If they do come to us then of course, we would
reach out and copy the AD or whoever, if it's been awhile if they haven't
received a response. The only thing we have in the registries is that
additional sentence itself, please contact us.

John: I wonder if the problem is people is not going through IANA and not
noticing that they should contact IANA. You can also stick an auto responder to
each of these lists that says 'by the way you can ask IANA for help'. My
concern about trying to fix everything by adding the ADs is, I don't know about
you guys, but I don't always catch every email that comes to me either so using
me as the way to fix the fact that email sucks is not a great solution.

Paul: That's why all the ADs are on the list, we count that some of you are
working. The auto-sender is fine too, i'm a little afraid that it will get
lost, we migrate to mailman 3 and all of sudden that is disabled or something
like that.

John: I'm OK adding the ADs, but another corner case is that some registries
don't have an area anymore.

Paul: Then we give them to the GEN AD, obviously.

Eric: So everyone agrees right, so that's fine?

Roman: INT

Eric: I hear nothing.

Roman: Paul, you want to write up a proposal for us to poke at?

Paul: Sure.

Roman: That way we have something concrete to try to improve and polish.

Paul: That sounds good. I'll bring it to the retreat.

Roman: Or the informal, we don't have to put everything to the retreat.

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

Roman: I heard that some folks can't stay for the whole day on retreat Friday,
i'm trying to understand how late the critical mass can kind of stay so are we
running the day to 5 or 2? I know some folks want to either get a train or
flight out a little bit earlier? There's a poll in Slack so you can let me know
and we can use that as decision support to start framing the agenda. I think
for a number of folks, you haven't booked travel yet and that will be important
decision support for how long to stay or whether you stay an extra night.

Another thing to mention that the week after next, the Tools retreat is
happening in Montreal so if you have bigger wants or needs on what the tooling
should be doing for you, or what you think it should be doing for the
community, if you want to talk to me or give a short write up. I have a list of
things for myself that i'll share with you guys as well so we can ge that into
the mix of what the Tool's team is thinking about.

The next informal, just to explain why things are appearing on the agenda
again, I pulled the milestone discussion and what to do with certain quiet
groups off the agenda because I couldn't make it. I'm going to bring it back
and then other thing i'm going to bring back is a more long standing item that
previous GEN ADs used to do which is the mythical document swap so i'm going to
take a quick look at where we stand with out public queues across the IESG and
i'm not sure what the numerical threshold should be but if things are in there
for a while, I wanna have the conversation on how we can get things out or how
we can have more resources on long standing things.

Liz: Any other business before we pop back to our executive session?

Ok, we'll go into our executive session.

6.12 Executive Session

An executive session was held.