Skip to main content

Narrative Minutes interim-2024-iesg-10: Thu 14:00
narrative-minutes-interim-2024-iesg-10-202405021400-00

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

narrative-minutes-interim-2024-iesg-10-202405021400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-05-02 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
Deb Cooley / Security Area
Jay Daley / IETF Executive Director
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
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Tommy Pauly (Apple) / IAB Chair
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport 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

REGRETS
---------------------------------
David Schinazi (Google) / IAB Liaison
John Scudder (Juniper) / Routing Area

OBSERVERS
---------------------------------
Gary Coppeler
Greg Wood

1.2 Bash the agenda

Liz: Anything to add to today's agenda? Any other changes?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes from the April 18
teleconference being approved? I'm hearing no objection, so we'll get those
posted to the Datatracker. Does anyone have an objection to the narrative
minutes from April 18 being approved? I'm hearing no objection, so we'll also
get those posted to the Datatracker.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Murray Kucherawy to find designated experts for RFC 9530 (Digest
       Fields) [IANA #1359278].
       - Added 2024-02-21 (4 telechats ago)

Murray: I still have it. I haven't seen any replies from my inquiries so I'll
check again. In progress.

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

Orie: I have names for this one. I think both of the authors have agreed to be
experts for this.

Liz: Okay, if you can send us their names and email addresses by the end of the
telechat then we can add a management item to approve them.

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

Orie: I have these too. I'll send you their names and email addresses as well.

     o Francesca Palombini to find designated experts for RFC 9557
       (Timestamp Suffix Tag Keys registry)[IANA #1363801]

Liz: Francesca, this is a new one for you this week.

Francesca: Action caught.

     o Murray Kucherawy to find designated experts for RFC 9560
       (Registration Data Access Protocol (RDAP) Query Purpose Values)

Liz: This is another new one this week. It was assigned to Murray; should we
leave this with you, Murray, or give it to Orie? It's another RDAP one.

Orie: I'll take it.

Murray: Thanks.

Liz: Okay, we'll update this to be for Orie.

   * OPEN ACTION ITEMS

     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.

Warren: 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.

Roman: We should pull this item off. We're doing it, we're a bunch of meetings
into doing it, and we're getting close to having a recommendation. We don't
need an action item for it.

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

Francesca: In progress. I hope to have something either for the next informal
or the next telechat.

     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.

     o Paul Wouters to write a proposal for handling IANA review
       mailing lists.

Paul: In progress.

     o All IESG to review Non-WG List Review spreadsheet and note
       which lists may be ready for closure and any needed AD Actions.

Roman: To reiterate the thinking based on Francesca's question, it was a little
unclear. Do you take ownership, what if you know something about a list but you
haven't listed yourself? My advice here is this is all best effort. If you know
what should happen to a particular list, tag yourself as a decider. When in
doubt, do not assume ownership if you're not sure. And put some explanatory
text in the notes column.

Francesca: I've done one pass and I know for a bunch of the ART lists. For now
I've put "FP: Comment" in the comments column. I guess I will go through now
and mark them to keep. Most of them were just to keep it, anyway. If Orie or
Murray don't agree with me, go ahead and change it if you want.

Roman: I was going to do the same thing for SEC myself. That makes sense.
Thanks. Are there any questions as folks are reviewing it? We'll just keep
going.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-rift-rift-23  - IETF stream
   RIFT: Routing in Fat Trees (Proposed Standard)
   Token: Jim Guichard

Liz: We have a Discuss in the tracker; do we need to discuss this today?

Jim: I don't think so. Roman, I saw Tony had sent a long response to you which
I think takes care of your comments, but I was waiting on you. The other two
Discusses have been taken care of. I want to say thank you everyone for
reviewing this; it was a beast of a document. Some great reviews and I
appreciate it very much, thank you.

Roman: If I got a response I didn't read it; I was traveling yesterday. I'll
take a look.

Jim: I think he responded to everything he needed but obviously that's your
decision, so I'll leave it with you.

Francesca: I was looking at Roman's Discuss point about IANA and the expert
guidance.

Jim: There was a big throwdown and Tony responded, and IANA said okay, so I
think that's taken care of but I do want to take another look at it.

FrancescA: I'm looking at the response from Tony yesterday. The weird thing is
that IANA has done a review of version 20, and this is version 23. In version
20, there was this expert guidance, and it seems to have been removed for
version 23. I don't know the whole conversation but it's strange that Tony said
he doesn't know what it is because it was in the document before.

Jim: I'm not sure either but I did see there was a thread between him and IANA
that went back and forth a few times and they said okay. It seemed as if
whatever they were concerned about was resolved but I do need to check that and
I will.

Francesca: Sounds good.

Liz: So this document will stay in IESG Evaluation. For a substate, Revised I-D
Needed or AD Followup?

Jim: I think it's going to need a revised I-D.

 o draft-ietf-ccamp-otn-topo-yang-18  - IETF stream
   A YANG Data Model for Optical Transport Network Topology (Proposed
   Standard)
   Token: John Scudder

Liz: We do have a Discuss here but John isn't with us. Does anyone want to
discuss this now or should we just leave it in AD Followup for John?

Mahesh: I haven't received any response from the authors yet.

Roman: I think we can just put it in AD Followup for him.

Liz: Okay, so this stays in IESG Evaluation :: AD Followup and John can figure
out how to proceed.

 o draft-ietf-6lo-multicast-registration-18  - IETF stream
   IPv6 Neighbor Discovery Multicast and Anycast Address Listener
   Subscription (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Approved but Revised I-D Needed to address the comments. John made a
very detailed review as well as Roman and Mirja so we need to take that in
account.

Liz: Great. Eric, there is a downref in this document; if you know the answer
now, let us know if you want to add RFC 9030 to the downref registry.

Éric V: Let me check and come back to you.

Liz: This will be Approved, Announcement to be Sent :: Revised I-D Needed.

 o draft-ietf-uta-ciphersuites-in-sec-syslog-05  - IETF stream
   Updates to the Cipher Suites in Secure Syslog (Proposed Standard)
   Token: Francesca Palombini

Liz: We have a Discuss; do we want to discuss this now?

Francesca: Paul, do you want to discuss now? I'm still waiting for the authors
to get back to me.

Paul: The weird thing is that they're saying this algorithm is weak or
insecure, which it's not really either of them. It's aging but it's not
insecure. I find SHOULD NOT a little weird because it gives you no migration
path. Anything that's running this as the mandatory to implement algorithm and
hasn't updated yet, the server will have to have at least support both, and the
way they're phrasing it with the SHOULD NOT is that you should upgrade all your
syslogging nodes at the same time because otherwise you won't get a TLS
connection working. That was a bit of my problem. We'll see if they can phrase
it a little better. I'd prefer if it said something like 'if you know everybody
has upgraded, you should not allow this algorithm, but otherwise you should
allow both the new and the existing one and prefer the new one.' I guess
they'll come back to me and we can take it from there.

Francesca: So I guess we stay in IESG Evaluation, AD Followup. Thank you for
the reviews.

 o draft-ietf-ipsecme-multi-sa-performance-08  - IETF stream
   IKEv2 support for per-resource Child SAs (Proposed Standard)
   Token: Roman Danyliw

Liz: We have no Discusses, so unless there's an objection now, this one is
approved.

Paul: It's going to be Revised I-D Needed. I'm sitting on an update (as the
author).

Liz: Okay great, so this will be Approved, Announcement to be Sent :: Revised
I-D Needed and Roman, you can let us know when it's ready.

Roman: Thanks, Paul, you have an -09 ready to go, right?

Paul: Yes, I have something staged I need to submit to the Datatracker.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 o draft-murchison-rfc8536bis-13  - IETF stream
   The Time Zone Information Format (TZif) (Proposed Standard)
   Token: Murray Kucherawy

Liz: We have a couple of Discusses; do we want to discuss these now?

Murray: A quick one on Zahed's point, needs an internationalization
considerations section; is that a standard thing? Or you'd just like to see it
in the document somewhere? I've never heard of an internationalization
considerations section.

Zahed: There's an internationalization requirement for the IETF, right? So from
that point of view I think my view is if we have a section that would be really
good. When I was reading I said okay, this is about changing information, and
it might have this problem with different kinds of encoding. Then I saw there
was some discussion in the ART-ART review. Going through the discussion I
thought it makes more sense to have this kind of considerations section to be
sure we're doing the right thing and some backwards compatibility and we have
considered all these things. It would be good to have it in a separate section
and make it more clear. Right now I'm basically bypassing my original comment
and saying it's problematic, but I saw there's already a conversation going on
so we can just capture all these things into it. I want to make sure this
happens because it's not about a new rule they will create, just a
consideration section.

Murray: My question was not exactly that, but we have formalized security
considerations sections, formalized implementation status, I think we've
formalized privacy considerations. Is this a thing we have formalized that I
didn't know about? Is there an RFC that describes how you should write these
sections, or are you basically making a freeform suggestion?

Zahed: I don't think it's a freeform suggestion. There's an RFC on it. I'm not
sure about the number, maybe Orie can help?

Orie: There's 6365. I had the same comment but as a comment, not a Discuss. My
Discuss point has more to do with the actual UTF-8 guidance and the ASCII
encoding pieces they have in the security considerations.

Murray: 6365 doesn't formalize that section. It talks about what it could
include. I could refer them to this, thanks.

Orie: As far as I'm aware there isn't an RFC that explicitly says how to write
an internationalization considerations section but I should know if it exists.

Murray: No, that's exactly what gave me pause here. Thanks. Revised I-D Needed,
please.

Warren: You also want to have a look at RFC 7322, which says "All RFCs that
deal with internationalization issues should have a section describing those
issues; see "IETF Policy on Character Sets and Languages" [BCP18], Section 6,
for more information."

Zahed: I was thinking about this one. There's one RFC saying what to consider
and another that says what to put in the section.

Murray: The two of these things together are what I was looking for.

Zahed: I've had three recently where we were dealing with this so that's
brought me this internationalization knowledge. I thought it's a good idea to
have this section separated out.

Murray: Thanks. So yeah, Revised I-D Needed.

Liz: This is staying in IESG Evaluation :: Revised I-D Needed.

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-mpls-bfd-directed-30  - IETF stream
   Bidirectional Forwarding Detection (BFD) Directed Return Path for
   MPLS Label Switched Paths (LSPs) (Experimental)
   Token: Jim Guichard

Liz: The consensus here is Unknown, so we'll set this to Yes for you. There are
no Discusses, so unless there's an objection now, this one is approved.

Jim: Can we put this one in Revised I-D Needed? I know Murray and Paul, there
are some responses from Greg that I think address your comments. If you could
take a look at that and once you're comfortable, I'm fine.

Liz: Okay perfect, so this one is Approved, Announcement to be Sent :: Revised
I-D 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

 o Mail Maintenance (mailmaint)

Liz: There are no blocking comments in the tracker, so unless there's an
objection now, I think this WG is approved. Does anyone have any final
objections? I'm not hearing any, so we can call this charter approved.

Murray: I have a couple of minor tweaks to make, and then I can ship it over to
you.

Liz: Great, so this is approved and we will wait for Murray to let us know when
to send the announcements.

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

Roman: I was not on the IAB call. John mentioned in email that the IAB has been
working on a document about limited domains that would help clarify something
we talk about, and that's getting a little more energy.

Tommy: Yesterday we worked on our retreat agenda for IAB items as well as some
joint items, so we do have those in our wiki. I think Roman, I popped that over
to you. If we can make sure some of the items that were proposed for the joint
look good, we can go forward.

Roman: We need to tighten up our own agenda items, so kudos to the IAB for
being on top of that. Maybe we can make that a topic at the next informal.

6. Management issues

6.1 [IANA #1363748] Management item: media type application/stratum (IESG)

Liz: Does anyone want to speak to this? Has anyone reviewed it?

Éric V: Alexey has approved this, so it's simply asking to rubber stamp his
decision.

Murray: I did read this and didn't have any problem with it.

Francesca: I also read it and also have no objections.

Liz: We've got two No Objections, does anyone want more time to look at this or
go with the NoObjs?

Paul: I trust Murray.

Liz: Okay, we'll call this approved and send an official note to IANA.

6.2 [IANA #1363801] Designated experts for RFC 9557 (Timestamp Suffix Tag Keys
registry)

Liz: This is the item to assign an action item to Francesca we discussed at the
top of the call.

6.3 [IANA #1363815] Designated experts for RFC 9560 (Registration Data Access
Protocol (RDAP) Query Purpose Values registry)

Liz: This is our other new item which we will reassign from Murray to Orie as
we discussed earlier.

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

Liz: Orie has identified Andy Newton and Scott Hollenbeck as the designated
experts for this registry; any objection to approving them? Okay, they are
approved and we will send the official note to IANA.

6.5 Designated experts for RFC-ietf-calext-jscontact-16 (JSContact Properties)
[IANA #1361734]

Liz: Orie has identified  Robert Stepanek and Mario Loffredo as the designated
experts for this registry; any objection to approving them? Okay, they are
approved and we will send the official note to IANA.

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

Francesca: For the mailing lists, I'm closing a WG and wondering when the
mailing list closes, if it's possible, if necessary, to reopen it with the
subscribers that it used to have before it was closed? Or once it's closed,
it's closed forever?

Cindy: Once it's closed we retain the archives but not the membership.

Francesca: Okay, so it's kind of a final decision. I guess that's why a lot of
lists stay open. My other question is, we have a lot of information in the wiki
for opening WGs but I didn't find anything about closing WGS. Did I miss
anything or do we just not have it?

Roman: I've never used any wiki-based directions to close a WG. When you click
that button to close a WG, you have that text box with guidance on closing and
there's a checklist in there.

Francesca: I just saw a message to the Secretariat.

Roman: Above that where it asks what to do with the mailing list, etc.

Cindy: It's important to note that when you click that button, nothing happens
immediately. It just sends a message to the Secretariat to have us double check
and make sure we know what to do with any remaining documents, mailing list,
etc. You guys have been pretty good about giving us that information, and if
you don't, then we ask you for it. Once we have all of that we change the
status in the Datatracker and send a message manually.

Francesca: I just don't know what part of my message in that text box will be
visible, or if you'll copy paste that into the main page of the WG, or is it
just a message to the Secretariat? Maybe if I have time I'll document this and
put it into the wiki.

Roman: If anyone needs help closing a WG I'm happy to spend time with you on it.

Gunter: I think I might make you happy, Roman; I'm working on closing 3 WGs so
I'll be out of work soon. On a more serious note, one of the WGs I'm looking
into for a recharter and I'm planning to make the charter more strict and close
to the focus of the WG. That being said, there will be some drafts which don't
have any other home. What to do with them? If I change the charter to be more
strict some things snuck in before and were already there that should have
never been adopted.

Roman: If they're already adopted in the WG but you want to recharter the WG to
make sure that doesn't happen again, you can include an explicit sentence that
says "We will work on the following 3 drafts" etc. So you can do the narrow
scope you wanted and then just cover those specific drafts to keep working on.

Gunter: Okay, that works. Thanks.

Roman: In the spirit of AOB, I was at the Tools team retreat earlier this week
and I learned all sorts of things about how the tools team works. What I wanted
to bring up was the existence of something I didn't know existed, which is the
timeline of the major features that the tools team is working on. I just wanted
to highlight that. So here it is; if you've never seen it and are curious about
what they're working on in broad strokes, you can look at this roadmap. Between
now and Vancouver, they're going to work on some of the dashboarding we've
talked about. You can see by some of the titles there are other things being
worked on. The thing to point out that was new to me is a substantial project
to revamp how things work at the RFC Editor on the back end to modernize and
ideally improve processing. Greg is also reminding us that the tools team holds
monthly meetings and you can always join. That's all for me.

Liz: And a reminder from me: yesterday we sent around a Doodle for a BOF
coordination call for IETF 120. Please fill that out so we can get that time
set.