Narrative Minutes interim-2023-iesg-09 2023-04-27 14:00
narrative-minutes-interim-2023-iesg-09-202304271400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-04-27 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Martin Duke (Google) / Transport Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Ooonduke
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Éric V: Quick reminder about the SWOT/PEST survey for the retreat. Please fill
out the survey.

Lars: You also saw my email about the visit to the University of Washington. If
you want to go, add yourself to the list. They're preparing two or three talks
from their side so we shouldn't come with 20.

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes from April 18? I'm hearing
no objections, so we'll post those. I also saw final narrative minutes from
April 18; any objection to approving those? I'm hearing no objections, so we'll
post those as well.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

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

Amy: Roman isn't on the call yet so we'll keep this in progress for him.

     o Murray Kucherawy to find designated experts for RFC 7462 (URNs for
       the Alert-Info Header Field of the Session Initiation Protocol
       [SIP])[IANA #1266696].
     o Murray Kucherawy to find designated experts for RFC-ietf-jmap-
       blob-18 (JMAP Blob management extension) [IANA #1267309].
     o Murray Kucherawy to find designated experts for Structured Syntax
       Suffixes (RFC 6838) IANA #1270651]

Amy: Murray is on PTO and we'll keep these all in progress for him.

   * OPEN ACTION ITEMS

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

     o Éric Vyncke to follow-up with the tools team on auto-populating the
       approval announcement text in the "ballot text" section (document
       abstract, responsible AD, document shepherd).

Éric V: This one is started but not yet complete.

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

Warren: I believe that Murray was working on that already and I was going to
chase them, but I can't actually remember who it was. I guess mark this in
progress.

     o Rob Wilton to draft a proposal to the tools team for what the
       requested information regarding mail statistics should look like.

Rob: This is slowly in progress. I found out we already have a lot of
statistics so it's just figuring out what to use.

Mirja: I'm also working to get some numbers to review during the retreat so if
you're interested in joining that, let me know.

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

Lars: I think we can put this on hold until after the retreat because we're
going to talk about it there.

     o Lars Eggert and Mirja Kuehlewind to figure out the start and stop
       times each day for the 2023 retreat in Seattle.

Amy: This is done.

Lars: I also added a parking lot for topics that came up after we did the
agenda so if you have more topics, add them there.

     o The IESG and IAB to write feedback for the ICANN listening session.

Amy: This is on the agenda as a management item to discuss; should we mark this
action item done?

Lars: This is mostly done; I'll send it right after the call. The IAB looked at
it yesterday. Nothing major changed, but if you have a minute during the call
take a look.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ace-cmpv2-coap-transport-09  - IETF stream
   CoAP Transfer for the Certificate Management Protocol (Proposed
   Standard)
   Token: Paul Wouters

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

Paul: Let's put it in AD Followup to fix the comments, please.

Amy: This will go into Approved, Announcement to be sent, AD Followup.

 o draft-ietf-spring-nsh-sr-12  - IETF stream
   Integration of Network Service Header (NSH) and Segment Routing for
   Service Function Chaining (SFC) (Proposed Standard)
   Token: Andrew Alston

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

Andrew: I think that would probably be a good idea. The comment says the IESG
should consider this. John, do you want to expand?

John: Basically Stewart pointed out that you're asking for an IP protocol
number and it's a small field, we don't have an infinite number of them.
Essentially you're optimizing a case where you already have headers this big to
begin with so if you use a UDP encap the header gets that big instead of this
big. I'm ok with moving it forward but I think we should at least be able to
say that yes we considered this and we're ok with assigning a protocol number.
It's not like there aren't a large number of fairly useless things in the IP
protocol numbers anyway.

Andrew: Jim, do you want to weigh in since you're the author on the call?

Jim: Technically speaking we could do an encapsulation, as Stewart mentioned,
but my feeling was the scope of the work in terms of the protocol is reasonably
large. We've had a WG working on lots of aspects of this protocol for a number
of years. In my mind if we can get a protocol number it makes things cleaner
from an architecture standpoint. As John points out, they are limited and
there's a way to do it without using a protocol number. I would prefer to get
one, because of the size of the work, but I don't have a strong opinion either
way.

Warren: How widely deployed do we think this protocol is likely to be? I know
that's hard to guesstimate.

Jim: I think that's a great question and the main thing John and I discussed.
The truth from what I've seen is that there are deployments and implementations
of this. I know for example Cisco, Huawei, Nokia, Ericsson have
implementations. There's quite a bit out there. Deployment wise, it got the
wind taken out of its sails by segment routing and that's kind of scuppered the
amount of deployment in the real world. If you do enough searches you'll find
some deployments out there but I don't think I could say it's widely deployed
and it's almost superseded by the segment routing work.

Andrew: If we do say you have to do another encap I'll have to send this back
to the WG because it's a massive change. John, are you ok with the IP protocol
or would you prefer…

John: No, I'm fine. Like I said in the Discuss, I will clear it at the end of
the telechat no matter what, I just wanted to make sure we had a chance to talk
about it.

Éric V: If you'll allow me to chime in, the space is limited indeed, but having
a clean protocol is also interesting. No hard feelings either way. If UDP
encapsulation is easy, let's do it. In some cases we can't use UDP
encapsulation so we need to save the space. We did it two months ago for
IPSECME and we could do it here as well. Basically my point is I don't care.

Andrew: I'm just trying to see how utilized that registry is at the moment.

Jim: That was one of the things I was thinking. It's not every month we get
asked for a protocol number, so this should be a limited request. I don't know
if it's worth the pain of the WG, especially that the SFC WG is closing down so
a lot of the expertise that worked on this were on the SFC WG. I know this is a
SPRING document. I don't know if it's worth the pain of going through sending
it back to the SPRING WG to get it to be UDP encap just for the sake of this
protocol number.

Andrew: My feeling is we should proceed as it is but if anyone does have strong
feelings, speak now.

Éric V: It looks like this year we'll be using at least three IP protocol
numbers. One is already used for IPSECME, which is already implemented and
approved. The second one would be this one, and the next one coming is to
transport the compression protocol directly over IP, just to give you an idea.
And there are still more than 100 left. All of us will be retired when we
exhaust [the numbers].

Jim: John made the point as well that a lot of the numbers already allocated
are 20 or 30 years old and probably not even relevant anymore, so maybe
sometime in the future we could discuss a cleanup.

Andrew: When you have protocol numbers that haven't been seen in the wild in
decades, what's the process for recycling those? Anyone know?

Lars: Painful. Someone writes a draft proposing that and we do our best to
reach out to anyone we can to find out if it's still deployed. We do this for
transport ports once in a while but it's really painful. Typically we just
ignore the problem until it becomes urgent.

Andrew: For things that are already marked as deprecated, what does that mean?

Lars: It just means you shouldn't make new deployments, but there might be old
stuff still using them. Since nobody needs to ask us to use them, it's
difficult to reclaim things. I'd wait and not bother at this time.

Warren: The other option is like we did with some of the ports a while back, we
slowly chipped away at the low hanging fruit ones. When one's bored in one's
copious free time, ask if people are using things.

John: As I said in slack earlier, if you want low hanging fruit, things that
are already classified as historic seem like a good place to start.

Roman: Do we need to solve the big question right now?

Andrew: I don't think so. What I'm hearing is that no one has strong objections
to the protocol number, and we did discuss it, so John will clear his Discuss.
It will need a revision because there are more comments in there.

John: I've cleared my Discuss and I have one other question I want to discuss
with Jim as author. I assume you don't really think you're going to need the
nat traversal properties of a UDP encap for this particular technology, right?
Thank you.

Jim: I think a lot of the comments in here I need to go through and update the
document. I'm not sure if there's anything left that wasn't responded to, is
there?

Andrew: I don't think so, but I'll work with you offline on that. If you've
cleared the Discuss, John, then I'll just take this back.

Amy: Okay, since Jim recused, this passes with the nine positions you have.
This will go into Approved, Announcement to be Sent, Revised I-D Needed.

 o draft-ietf-bess-evpn-lsp-ping-09  - IETF stream
   LSP-Ping Mechanisms for EVPN and PBB-EVPN (Proposed Standard)
   Token: Andrew Alston

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

Andrew: I've gone through most of these and a lot of them have been responded
to. This document needs a lot of work though. At this point I'll work with the
authors comment by comment and we can take it from there. Unless anyone has
something specific they want to discuss.

Lars: I don't think I've seen responses to my stuff, but I might have missed it
in the flood of emails.

Andrew: I'll make sure everything gets responded to. I apologize for not
catching a lot of the grammatical stuff, I was busy trying to understand EVPN.

Lars: That's fine, it's just my pet peeve. I don't expect everyone else to care
about this stuff.

Andrew: This will definitely be Revised I-D Needed and I'll work to get those
Discusses cleared with the authors.

 o draft-ietf-opsawg-sbom-access-15  - IETF stream
   Discovering and Retrieving Software Transparency and Vulnerability
   Information (Proposed Standard)
   Token: Robert Wilton

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

Rob: Thank you everyone for your reviews.

Roman: I re-balloted to clear my Discuss and put another comment in. There's
still an issue with one of the examples.

Rob: Can you leave it in AD Followup then, and I'll make sure that gets
addressed? Thank you for flagging that, Roman.

Amy: Great, this will be Approved, Announcement to be Sent, AD Followup and you
can let us know when it's ready to go.

 o draft-ietf-ipsecme-add-ike-11  - IETF stream
   Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for
   Encrypted DNS (Proposed Standard)
   Token: Roman Danyliw

Amy: I have a couple of Discusses; do we need to discuss these today?

Roman: No, I don't think so. The authors have started responding. I appreciate
the deep reviews from all of the ADs.

Paul: My issues will mostly be resolved, that's not a problem, but I think it's
worth bringing up the update clause here to see what the IESG thinks about it.
The discussion there is IPSEC doesn't do an update clause even though it
updates the core document if the only changes to the core document are inside
that updating RFC. the question is is that a correct use of the update clause
or not? There seems to be some discrepancy.

Lars: You said they're not doing an update?

Roman: They are not.

Lars: Mirja is the expert on this clause. My simple thinking is that if you're
implementing this spec, do you need to read this document or not? The spec
being IPSEC. I see it as a pointer that you should really read this too. If
that's the case that should be an update in my view.

Zahed: I had the same Discuss point. It's having that RFC informative not
normative. I understand we shouldn't talk about what's an update and what's not
an update on this call, but it didn't feel right to me to actually do that. I
also think the reference there should be normative. You need to read that RFC
and this one. That's not addressed by the comment I got from the authors.

Roman: I agree with you, Zahed. That's a good catch. Normative behavior is
getting changed on another PS. That's a Revised I-D Needed, absolutely.

Paul: Do we get to hear from Mirja about this if she's the expert?

Mirja: there's really no definition or agreement of it. Some WGs refuse to use
it in this way and they feel if they put an update you're obligated to
implement it, which it doesn't. We really don't have a unified use.

Paul: So the expert opinion is it depends.

Roman: Let me be concrete here with the author and Zahed and split the
difference. If the culture in IPSEC was that that's how they preferred to use
the update tag, would you be comfortable with just having the normative
reference?

Zahed: That would be fine for me. As I said, the update thing is very it
depends. If this WG has a particular notion and they're following it, I don't
have a problem with it, but the reference should be normative.

Paul: Same here, it's not a dealbreaker for me.

Roman: Minimally I was going to ask for the normative reference and I think the
rest is a discussion. Thanks.

Amy: So this will stay in IESG Evaluation with Revised I-D Needed.

 o draft-ietf-ipsecme-labeled-ipsec-11  - IETF stream
   Labeled IPsec Traffic Selector support for IKEv2 (Proposed Standard)
   Token: Roman Danyliw

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

Paul: Can we also please put it in AD Followup? Speaking with my author hat on,
I'll have my coauthor fix the comments and do a new revision.

Roman: Thanks. Can we just put it in Revised I-D Needed? AD Followup means I
have to look at it.

Paul: That's what I meant, yeah.

Amy: So this will go into Approved, announcement to be sent, Revised I-D Needed.

 o draft-ietf-dnsop-alt-tld-23  - IETF stream
   The ALT Special Use Top Level Domain (Proposed Standard)
   Token: Robert Wilton

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

Rob: Thanks for all the reviews. I haven't checked whether any comments need
text changes; Warren may know if a further update needs to be posted.

Warren: The editors have a pull request sitting in Github, so I think this
should be Revised I-D Needed. They're all fairly editorial so it could be sent
to the RFC Editor now or fold them in now, whichever you prefer.

Rob: I'd prefer to fold them in now, so let's do Revised I-D. Thanks everyone
for your reviews.

Warren: Yes, thanks very much everyone.

Éric V: And thank you Warren for doing it.

Amy: So this will be Approved, Announcement to be Sent, Revised I-D Needed to
fold in those changes. I do have a downref; will we be adding 8244 to the
downref registry when this approval gets sent?

Warren: I personally think we should, as the author of the number you just
said. I think it's the sort of thing a number of things will reference in this
manner.

Amy: Okay, we'll make sure to add that to the downref registry. Thank you all.

2.1.2 Returning items

 o draft-ietf-add-dnr-16 (Has RFC Editor Note)  - IETF stream
   DHCP and Router Advertisement Options for the Discovery of
   Network-designated Resolvers (DNR) (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Thank you for all the reviews again. I'll put it in AD Followup so I
can check that it's actually addressing all the comments.

Zahed: I can confirm it addresses mine. Thanks to Matt for responding so
quickly.

Éric V: Let's do AD Followup anyway, please. Thank you, Zahed.

Amy: Great, this will be Approved, Announcement to be Sent, AD Followup.

 o draft-ietf-add-svcb-dns-08 (Has RFC Editor Note)  - IETF stream
   Service Binding Mapping for DNS Servers (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Thank you again for reviewing this for the second time. I see there is
a comment from Roman that I should check for follow up. Let's put this in AD
Followup, please.

Amy: Great, this will be Approved, Announcement to be Sent, AD Followup.

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

 o draft-ietf-nvo3-evpn-applicability-05  - IETF stream
   Applicability of EVPN to NVO3 Networks (Informational)
   Token: Andrew Alston

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

Andrew: Let's put this in Revised I-D Needed. There are a number of references
that need to be updated.

Amy: Thanks; you can let us know when that's been updated.

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-panrg-path-properties-00
   IETF conflict review for draft-irtf-panrg-path-properties
     draft-irtf-panrg-path-properties-08
     A Vocabulary of Path Properties (IRTF: Informational)
   Token: Zaheduzzaman Sarker

Amy: I have no Discusses for this conflict review, so unless there's an
objection now this can go back to the IRSG with the writeup that's in the
tracker.

Éric V: I don't know whether you've seen my comment on this; I think it's
related to a couple of WGs.

Zahed: I saw it. I've looked into everything I thought could be related to
this. When I started to list all the WGs I knew I would still be missing some.
So that's why I thought not to list all the WGs there. But your suggestion is a
valid one; I don't have any strong opinion so if you want me to change it to
say it's related to those we can do that. But I don't think it actually makes
much difference.

Roman: I think you're exactly right in principle, Eric, but the practical
result is there's no conflict whether or not it's related. You put a lot of
work into this already, Zahed, and I'd say you don't need to do more. Thank you
for doing the deep review.

Zahed: I think we're fine with this.

Éric V: No problem. My only point was that you don't need to write all of them,
but I suggested several. But as Roman said, I really don't care.

Zahed: Then let's go with the current comments. Thank you.

Amy: Okay, we'll send this with the current note in the tracker.

3.4.2 Returning items

 NONE

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

 o Network Inventory Modeling Base YANG (nimby)

Amy: I know the name and acronym may change for this, but I don't have any
blocking comments for the charter as a whole. I would suggest you choose a new
name and acronym before this goes out for external review.

Rob: Yes. This is meant to be a short lived WG anyway. Thank you for all the
comments. I also have some review feedback to go through as well. I'll go
through that with the proponents; I may bring it back to next week's telechat
if there's time. Thanks for all the reviews; I'm not sure what state that
should be so it doesn't go out.

Amy: We'll just wait for instructions from you. It's probably just going to sit
here until you've made a decision on the name and acronym.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Lightweight Authenticated Key Exchange (lake)

Amy: I have no blocking comments so unless there's an objection, external
review is approved. I see a lot of comments; do any of those need to be
addressed before the external review goes out?

Paul: Let me read through them. Roman also had a question but wasn't sure if
there was enough momentum to recharter for the deployment of the protocols. Let
me get back to this, I don't know what state you can put it in to let me read
through the charter.

Amy: We can do approved pending changes.

Paul: Sure, let's do that. Thanks.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Roman: The IAB has been thinking about prep for RIPE 86. A couple of things the
IAB is also working on: a response to an EU exploratory consultation on the
future of electronic communication and there are going to be some technical
discussions on censorship circumvention. They're also exploring a possible
identity management workshop.

Mirja: I'd like to add something. This isn't news but we're still desperately
looking for candidates for the ICANN Nomcom. If you have anyone in mind whose
arm you can twist, please do. The technical presentation on censorship will be
at the end of May and next week there will be one about fragmentation.

Rob: What will the identity management one be?

Mirja: We had a discussion a few weeks back where we had one of the OAUTH
chairs and another expert talking about the whole space, and it seems like
there's a lot of work. It's not clear. We'll discuss during the retreat if
there's more to explore in a workshop.

6. Management issues

6.1 To Approve the tools team use of static.ietf.org (Lars Eggert)

Amy: I know there's been discussion on this and it doesn't sound like anyone is
dissenting. Did we lose Lars?

Paul: I did not see anybody object to it.

John: Please, go ahead.

Amy: I'm not sure if we just tell Robert that it's okay or if we need to send
something official?

Jay: I'll pick it up and do it, thank you.

6.2 Updating the IESG statement on IEEE EtherTypes (Éric Vyncke)

Éric V: It was mainly the IEEE people that were changing minor things like
references, nothing of substance. If nobody objects we can accept the document
as it is right now and I will contact Greg to update the statement on the web.

Amy: What goes along with updating a statement is we generally send an
announcement out, is that okay to do?

Éric V: Yes, that's perfectly fine.

Amy: So just like any other, we'll deprecate the old one and put the new one
in. Just let us know when that's ready.

6.3 Moderation of  tls-reg-review@ietf.org (Paul Wouters)

Cindy: This list only has four people on it (Ben Kaduk, Nick Sullivan, Rich
Salz, and Yoav Nir). Michelle Cotton was originally the admin for it; I don't
know if she was subscribed under her IANA address but of course that doesn't
work anymore, so I don't know if somebody else from IANA should be on this list?

Sabrina: Not that I know of, as far as anyone else from IANA. I was going to
ask you if we needed to be on there; I don't want to imply that IANA is
monitoring the list. It sounds like the experts are also on there too. But if
we need to be there, it could be either me or Amanda.

Paul: If it's not common for IANA to be on these lists, you don't need to be
added specifically for this one. I think this was originally triggered by me
trying to figure out whether a message was lost, but I think the person
actually sent it to a different list, so I'll have to follow up. From my point
of view this is all resolved.

Cindy: It's not resolved, because the address that was listed as a moderator no
longer exists. Maybe one of the people who are subscribed can be moderator, or
two of them, or all of them? We just need to know.

Paul: I see. I guess make all of them moderators. It's a super low traffic list
anyway.

Cindy: Okay, I'll reset passwords and send that to them. Thank you.

6.4 ICANN Board Listening Session (Lars Eggert)

Lars: This is basically minuting our agreement to send this out. I'll send it
after the call. I don't think there are any more comments.

Mirja: I did one last edit because I didn't understand a sentence but that
shouldn't change anything.

Lars: I'll send this to ietf-announce and include a paragraph on what this is
and why we're sending it, and I'll also include the link to the listen-only way
to participate in that session tomorrow, and then I'll send it to ICANN.

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

Amy: The next formal telechat is next Thursday and the package will go out
tomorrow. There's some room if you want to add documents. We'll also have a
poll soon to find a time for the 117 BOF coordination call.