Narrative Minutes interim-2024-iesg-01 2024-01-04 15:00
narrative-minutes-interim-2024-iesg-01-202401041500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-01-04 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
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (Mozilla) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Incoming Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Incoming Applications and Real-Time Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Incoming Routing Area
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area

OBSERVERS
---------------------------------
Deb Cooley
David Millman
Greg Wood

1.2 Bash the agenda

Liz: Any changes to today's agenda?

Roman: I had put on a management item for the public I-D staging directory but
there wasn't much time for people to read the document, so let's remove it from
today's agenda and discuss at the informal next week.

Lars: Soon we should also talk about Brisbane and things like when we will meet
on the Sunday.

Liz: Let's also do some introductions for the new people. [Everyone introduced
themselves.]

1.3 Approval of the minutes of past telechats

Liz: Is there any objection to approving the minutes from December 14? I'm
hearing no objection, so we'll get those posted in the public archive. We also
have narrative minutes from December 14; the final version just came out this
morning but they're unchanged from the draft version sent on December 14. Any
objections to approving those? Okay, we'll get those posted in the public
archive as well.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 9447, ACME
       Authority Token Challenge Types" [IANA #1281679].
     o Roman Danyliw to find designated experts for RFC 9493 (Subject
       Identifiers for Security Event Tokens)

Roman: For both of these, I've found one and want to find another. I'm waiting
for the second to respond; these are in progress.

     o Robert Wilton to find designated experts for RFC 9487 (Export of
       Segment Routing over IPv6 Information in IP Flow Information Export
       (IPFIX))[IANA #1287238].
     o Robert Wilton to find designated experts for RFC 9456 (Updates to
       the TLS Transport Model for SNMP)[IANA #1287239].

Rob: Both of these are in progress.

   * OPEN ACTION ITEMS

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

Murray: I can say something on this. I spoke to Barry and he still wants to do
this, he's just not able to get the time to do this. I asked if he needed help
or if there was a part I could take over and he still resisted. He'd like to
get it past the point where there is a first draft and then he'll invite others
in to help. So that's an update.

     o Andrew Alston to email the RSWG regarding document authorship/
       editorship with regards to the number of authors listed.

Andrew: Still in progress.

     o Lars Eggert 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.

Lars: In progress.

     o Francesca Palombini to review and merge updates to the wiki page
       "Getting a Document on the Agenda."

Liz: Francesca isn't here today so we'll mark this in progress for her.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-detnet-mpls-oam-14  - IETF stream
   Operations, Administration and Maintenance (OAM) for Deterministic
   Networks (DetNet) with MPLS Data Plane (Proposed Standard)
   Token: John Scudder

Liz: It needs more positions overall but it also has a few Discusses. Do we
need to discuss any of these today?

John: I don't think so, unless anyone holding a Discuss wants to. I'm not too
concerned about what I've seen so far.

Martin: There's this whole sequence number gap thing. This is one of those
things that's maybe a little tenuous. Maybe a bad design, I don't know. I don't
know anything about the use case. If you tell me it's cool and it's just that
if there's a POF it's going to hit the delay every time because of XYZ, that's
fine with me, but if you want them to fix it I can hold this until they fix it.

John: Why don't you not clear it yet. I still need to…your comments were the
hardest for me to digest so I need to dig through that properly. Most of that
stuff makes my head hurt anyway. It sounded like he was saying that's the way
we've always done it, in which case it's how they've always done it. But let me
dig through it.

Martin: There are some other specs that explain how these code word things
work. It has a format where they have sequence numbers reserved and then the
last sixteen bits are whatever the last sixteen bits are. They're fitting that
template for whatever reason but it doesn't seem like…I think they were
reserving that for this and they can always just update it, as far as I can
tell. I'm happy to chat with you offline if you want.

John: That sounds good. Thanks.

Lars: The other technicality is that we should be okay with that downref that
was listed in the Last Call, and I think we are. There's a normative reference
to the framework which is informational. They can change it but I don't see a
need for this to be a normative reference. If they want it to be a normative
reference though I think we can agree it's okay.

John: Right. Seems to me like instead of having us bless the downref, why don't
I just ask them to move it. Have you gotten an answer to that?

Lars: I haven't looked.

John: My guess is that they would just move it to informational. Anything else
on this one?

Liz: I'm guessing this might require a Revised I-D?

John: I'm sure it will.

Liz: Great, then we will leave this where it is and mark it as Revised I-D
Needed.

 o draft-ietf-dnsop-avoid-fragmentation-16  - IETF stream
   IP Fragmentation Avoidance in DNS (Best Current Practice)
   Token: Warren Kumari

Liz: We also have a few Discusses on this. Warren isn't here, but do any of the
Discuss-holders want to have a discussion now?

Rob: I'm just waiting for the authors to get back to me on my comments.

Lars: This one will certainly need a revised I-D but I think it might also need
to come to an informal to have some discussion. It's an important document but
it seems pretty sloppily written. Almost every paragraph got at least a comment
or a Discuss. It will take some sorting through but we'll need Warren.

Liz: We'll leave this where it is with Revised I-D Needed then, and wait for
Warren.

 o draft-ietf-rtgwg-vrrp-rfc5798bis-17  - IETF stream
   Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and
   IPv6 (Proposed Standard)
   Token: Jim Guichard

Liz: This document has enough positions to pass, and doesn't have any
Discusses, so unless there's an objection now it looks like this one is
approved.

Jim: There are a few comments I just need to double check were resolved. I
think they were. Just let me follow up with that and then we should be fine.

Liz: Okay, so we'll put this into Approved, Announcement to be Sent, AD
Followup, and you can let us know when it's ready to go.

 o draft-ietf-pce-pceps-tls13-03  - IETF stream
   Updates for PCEPS: TLS Connection Establishment Restrictions
   (Proposed Standard)
   Token: John Scudder

Liz: There are no Discusses for this document, so unless there's an objection
now, this one can also be approved. John, is this ready to go or do you want to
take another look?

John: AD Followup, please.

Liz: Perfect; then you can let us know when that's ready to move forward.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 o status-change-gost-dnssec-to-historic-03  - IETF stream
   Change the status of GOST Signature Algorithms in DNSSEC in the
   IETF stream to Historic (None)
   Token: Warren Kumari

Liz: This needs more positions so it can't go anywhere today, and it has some
Discusses, but do we want to discuss these today without Warren?

Lars: I support Roman's issue. This should really be clarified and I'm pretty
sure Warren will do it when he's back. I wouldn't want to approve it without
the text being changed.

Andrew: I didn't get around to this document so I will get to it and ballot.

Liz: Okay, then let's just leave it where it is in IESG Evaluation with AD
Followup until Warren is back, and those of you who haven't balloted yet will
have a little more time to do so.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-detnet-oam-framework-10  - IETF stream
   Framework of Operations, Administration and Maintenance (OAM) for
   Deterministic Networking (DetNet) (Informational)
   Token: John Scudder

Liz: There are no Discusses so unless there's an objection now, this document
is approved. John, is this one ready to go or would you like it in AD Followup
as well?

John: You can put it in AD Followup.

Liz: Okay, so we'll put this into Approved, Announcement to be Sent, AD
Followup, and you can let us know when it's ready to go.

 o draft-ietf-lsr-isis-area-proxy-10  - IETF stream
   Area Proxy for IS-IS (Experimental)
   Token: John Scudder

Liz: We do have a couple of Discusses here. Do we need to discuss these today?

John: I don't. Paul and Roman, either of you want to talk about anything?
Otherwise we can just move forward.

Roman: No, I'm good.

Paul: No, go ahead.

Liz: Okay, so we'll leave this in IESG Evaluation. Will this need a revised
I-D, or should we put it in AD Followup?

John: You can put it in Revised I-D, I'm pretty sure it will need some updates.

Liz: Okay, we'll give this Revised I-D Needed.

 o draft-ietf-detnet-pof-08  - IETF stream
   Deterministic Networking (DetNet): Packet Ordering Function
   (Informational)
   Token: Roman Danyliw

Liz: We have a Discuss here; do we want to discuss that today?

Roman: No, I think there is mailing list conversation happening. Martin, thank
you for the insightful Discuss and thank you everyone for the reviews. This
will need a revised I-D.

Martin: I think most of the Discuss points are going toward a satisfactory
conclusion but there is this number 2, the requirements for ordering thing. I
think this is a really bad design but if John and Roman are fine with it, I'll
relent. If you read the spec, if a packet comes in that's old, it will forward
it to avoid a drop. I don't know the use case for Detnet really but I'm a fan
of things doing what they say on the tin. If this packet ordering function is
sort of doing things in order but sometimes not because it wants to avoid a
drop, that seems bad. But again, I'm not a use case knower, maybe dropping is
the biggest sin in this environment.

Roman: I have to unpack that feedback a little more. I did not read all the
back and forth.

John: I did read it, but very quickly. I feel like Balazs is probably the best
equipped to justify himself.

Martin: I said it seems really bad to me but if you and the ADs think this is
really the way to go I'm not going to die on the hill, and he said ack, so my
current read is that he's not going to do anything about it. Which is, you
know, okay. Whoever is responsible for Detnet in the long run it seems like
this will make it confusing for people.

John: I also had some back and forth with him about stuff and my takeaway in
the end was that this is an exemplary algorithm, it's probably not what anyone
is going to end up implementing, so to that extent it seems like they're more
interested in keeping it simple than something you'd actually want to ship and
deploy.

Martin: My change would be to change a less than or equal sign to an equal
sign. Not really adding a ton of text there.

John: Fair point.

Martin: I'm not really sure where we're at with that.

Roman: Maybe I misunderstood. This is an informational document, obviously, but
this is one of the potentially several algorithms proposed. This is maybe the
first one out of the gate, right?

John: Right, that's what I meant by exemplary. I think at the very least
someone probably needs to poke Balazs to say an ack is nice, but please provide
a more fulsome reply to that particular point.

Roman: And maybe if we continue with the text as-is that there's more
cautionary language.

Martin: I'd be satisfied with that. I'd be comfortable if they just said a
warning that this ordering function does not ensure order. Thanks.

Roman: Thank you for the feedback. I think we're still in Revised I-D Needed
because there are already other changes that need to get merged. Thanks for the
review.

Liz: Thanks everyone, so this will stay in IESG Evaluation with a substrate of
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

3.4.3 For action

 o conflict-review-spinosa-urn-lex-00
   IETF conflict review for draft-spinosa-urn-lex
     draft-spinosa-urn-lex-21
     A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
   (ISE: Informational)
   Token: Lars Eggert

Liz: We have two conflict reviews that need to be assigned. Do we have any
volunteers for this?

Lars: This one looks like ART, with URN in the title, so Murray or Francesca?

Murray: Give me a second here to search some stuff. I can take care of the
conflict review, let's do that rather than wait for Francesca.

 o conflict-review-farinacci-lisp-lispers-net-nat-00
   IETF conflict review for draft-farinacci-lisp-lispers-net-nat
     draft-farinacci-lisp-lispers-net-nat-07
     lispers.net LISP NAT-Traversal Implementation Report (ISE:
   Informational)
   Token: Lars Eggert

Lars: This one is INT.

Éric V: I wouldn't mind taking it, or maybe a Routing AD. Lisp is rechartering
and there might be overlap there. I'll take this one.

Liz: Thank you Murray and Éric for volunteering.

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

 NONE

4.1.2 Proposed for approval

 o Network Management Operations (nmop)

Liz: We have quite a few colors here, three blocks and an Abstain. Do we want
to discuss this now?

Rob: Briefly, I'll give you an update. I haven't really updated this since
before Christmas. I'm having some discussion with Adrian and a lot of comments
are fairly minor, but there are still some points to resolve with him. My
expectation is that we'll update the text and I'll bring this back maybe for
the next telechat or the one after. Roman, I don't know if you want to discuss
any of yours? Anyone else want to discuss?

Roman: The other thing I mentioned was around anonymity. Maybe I'm conflating
it with the Lisp one.

Rob: Your comments were about process nits about milestones and things. I can
potentially do that initially. The other one was more clarity on what protocol
work this group might do. Initially the charter is nothing but I wanted to keep
some text in there that we could do some protocol work.

Roman: The other was this notion of experiments. I guess I'm not sure what that
means. Is it that the WG sets up experiments and the experiments are done on
the outside, or are the experiments done as IETF work? I was trying to
understand if that's the case, I don't know how much precedent there is, but
what does that look like.

Rob: I think this is where operators are doing experiments on how to solve
these problems and then reporting back to the WG for discussion and feedback.
That's what I had more in mind, that it's not the WG doing experiments but it's
more reporting or discussion of those. I can change the text to make that
clearer. Would that work?

Roman: Yeah, that's great. If they're reporting experimental results back
that's almost akin to any other operator feedback and that makes sense.

Rob: We've got the idea of how to solve this problem and getting feedback on
the approach and things. Any other comments? From a process perspective, I
don't necessarily want to bring this back next time. Can we keep it in its
current state and we can bring it back when it's ready?

Liz: We can leave it where it is and you can let us know when you want to bring
it back.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Messaging Layer Security (mls)

Liz: We don't have any blocking comments on this one. Any objection to sending
this to external review?

John: No objection. If you want to wait I have a few minor comments that I just
didn't have time to type up before the meeting.

Éric V: Same for my comments, I don't know if you had time to read them.

Paul: I did. Sean also responded when our meeting started that he rewrote it a
bit.

Éric V: Do you know whether this MLS architecture document will be moving?
We've been waiting for a revised I-D for a year.

Paul: That was promised to me a number of times. I'll ping them again. That was
very close.

John: That's kind of a good point, until you publish all the work from the
previous incarnation do you really want to [recharter]?

Éric V: That's kind of my point.

Paul: That's fair.

Liz: Do you want a chance to make any revisions based on these comments before
external review?

Paul: Sure, I'll wait to see John's comments.

Liz: Okay, then we will send that as soon as it's ready to go and we'll wait to
hear from you.

4.2.2 Proposed for approval

 o Locator/ID Separation Protocol (lisp)

Liz: This Lisp recharter has several blocks. Do we want to discuss this now?

Jim: I don't think so. I talked to one of the chairs yesterday and they are
formulating some responses to these Discusses they will send today. Until we
see those we can't really do too much.

Liz: So we can leave this where it is and await further instruction when it's
ready to bring back to a telechat.

Jim: Roman and Martin, you should see some responses today or tomorrow.

5. IAB news we can use

Roman: The IAB has not had a meeting yet. I put in chat that the new IAB slate
has been selected and publicly announced. There was a statement released around
the holidays around the US NIST standards strategy. What did I forget?

Dhruv: There's the BIAS workshop, I'll put the details in Slack. Any IESG
member who would like to participate in the workshop can notify me or Mirja and
we will add you to the program list.

Lars: I don't have anything else, the IAB has been pretty quiet.

6. Management issues

None - only item deferred to the informal telechat.

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

Lars: Is there any AD who won't be in Brisbane in person?

Jim: I may not be. I need to get a new passport and it's taking forever. I may
or may not be there; if I get the passport in time I'll be there.

Andrew: I'm still hoping to be there but I'm not 100% sure at this point.

Lars: If there are ADs who aren't going to be there we need to figure out if
having the Sunday meeting in morning or afternoon will be better and then fight
with the IAB for it. If we don't have a preference then I guess the IAB can
pick. And Secretariat, you guys have the script for everything we need to get
done on that Sunday meeting and all the appointments we have to make, right?
We'll be busy.

Liz: Yes.

Lars: The other thing we have is the IESG appointment to the Trust. We have a
few individuals who were nominated.

Liz: The nomination period is open until January 19, so there are two weeks
left.

Lars: Do we have a count of how many people are nominated?

Liz: I don't.

Lars: Could we send out a reminder?

Liz: Sure, we can take care of that.

Lars: Remembering WIT, we should probably give Robert some indication of when
we want the Datatracker changes to go live.

Martin: I was planning to do that today but WIT ADs are not here.

Lars: I suggested to Robert that we should have it in place before Liz starts
the agenda tetris so that should give the tools people some time.

Liz: And to put a date on that, session requests close on February 2, so
probably by February 9 is when I'll start the Tetris in earnest, so changes
should hopefully be done before then.

Roman: As a teaser for next week, we sign all our RFCs in a way that's manual
and not a great process, and the reason we did it may not be relevant anymore.
I'll write all that up for everyone.