Skip to main content

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

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

narrative-minutes-interim-2024-iesg-04-202402151500-01
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-02-15 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Amanda Baber (ICANN) / IANA Liaison
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
Mahesh Jethanandani (Arrcus) / Incoming Operations and Management Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Erik Kline (Aalyria Technologies) / Internet Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Incoming Applications and Real-Time Area
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
Jim Guichard (Futurewei Technologies) / Routing Area
Warren Kumari (Google) / Operations and Management Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area

OBSERVERS
---------------------------------
Ed Birrane
Henk Birkholz
Adam Wiethuechter
Greg Wood

1.2 Bash the agenda

Liz: Does anyone want to add anything new to today's agenda? Any changes?

Rob: If there's time, we add a management item to discuss whether we front load
page counts for two weeks time or have a limit or three weeks time at the end.

Liz: Sure, we can absolutely talk about that if we have time.

Rob: Thank you

1.3 Approval of the minutes of past telechat

Liz: Does anyone have any objections to the minutes of the February 1st
teleconference being approved? Great. I'm hearing no objections, so those are
approved and we will get those posted. We also have the narrative minutes of
the February 1st teleconference. Any objections to approving those? I'm hearing
no objections, so they are approved and we'll get those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

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

Liz: This is a brand new item for Murray, who's still not here, but hopefully
he sees it.

   * OPEN ACTION ITEMS

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

Liz: Neither of them are here, so we'll mark this as in progress for them.

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

Andrew: Still in progress, i've reached out to the chairs and had some
discussions, but I've had a number of feedback about this. I'm still trying to
figure out what exactly what I'm going to say to this, so just leave that one
in progress.

Liz: Ok. Thank you.

     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.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-detnet-yang-19  - IETF stream
   Deterministic Networking (DetNet) YANG Model (Proposed Standard)
   Token: John Scudder

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

John: Thank you for not dropping seven discusses on it, revised ID needed,
please.

Liz: This will go to approved, revised ID needed and you can let us know when
that is ready to go, John.

 o draft-ietf-netconf-http-client-server-17  - IETF stream
   YANG Groupings for HTTP 1.1/2.0 Clients and HTTP Servers (Proposed
   Standard)
   Token: Robert Wilton

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

Rob: I don't think unless Roman wants to discuss it. I've chatted with him a
little bit offline to reply to his comments issue, but I think the main issue I
probably need the authors to reply back to a better answer than I can. So I
think we need to wait for the authors on this one.

Roman: Yeah, that sounds right.

Rob: Thank you.

Liz: Should we put this in revised ID needed or AD follow-up?

Rob: AD Follow-up.

Liz: This will stay in IESG evaluation with a substate of AD follow-up.

 o draft-ietf-httpapi-link-template-03  - IETF stream
   The Link-Template HTTP Header Field (Proposed Standard)
   Token: Zaheduzzaman Sarker

Liz: We have a discuss on this one, do you want to discuss it now?

Zahed: Paul, I looked into that and it said like there are issues with the
colon and the -03 version that is out there now. Is there anything else you
would like to get?

Paul: No, that's it. I'll check this and resolve my discuss.

Zahed: If we can do it quickly then perhaps we can remove this one and approve
this one.

Paul: Sure, if you can leave it here for a second and i'll go look through it.

Liz: We'll come back to this one in a little bit and see if Paul has cleared
his discuss yet.

Zahed: Yes, let's come back to it.

(a few discussions later)

Liz: Paul's discuss has been removed so this is ready to go forward unless
there's an objection then this can be approved. Zahed, do you want  this in AD
follow-up to do any final checks?

Zahed: I think we can approved it with AD follow-up.

Liz: We'll put that as approved announcement to be sent with AD follow-up.

 o draft-ietf-babel-rtt-extension-05  - IETF stream
   Delay-based Metric Extension for the Babel Routing Protocol
   (Proposed Standard)
   Token: Andrew Alston

Liz: We have quite a few discusses, do we want to discuss it now?

Andrew: I think that most of them are pretty clear. I have seen that the
authors have been pretty responsive on the list so I'm watching that, and I'm
talking to the authors as well. I don't know, Eric if you've gone through all
of Juliusz's reply to you and the modifications he's made because it's quite a
substantial reply to your stuff.

Eric: I'm not sure which  Eric you're talking about, I'm assuming it's me, yes?
I've been Juliusz's reply and everything is fine.

Andrew: I don't think there's anything that needs any heavy discussion there. I
think I just need to work with the authors through all of the discussions and I
think there's definitely gonna need a revised ID on this. And I apologize for
missing the typo on the RFC number. That was my screw up exactly in my notes
and I forgot to send it.

Rob: Hi Andrew, can I just ask what status this documents is it gonna move to
experimental or is it going to stay a standard track or is it split into two
documents? One, standards tracker and one that's experimental. Do you have a
view on where that's gonna go?

Andrew: I think that this is probably going to remain a standards track, but I
think with some rewording around what they turned experimental.

(Crosstalk)

Eric: I agree with you Andrew. It deserves a standards track, but the way it is
described in the text as experimental is the wrong thing, right? Basically they
shouldn't.

Andrew: It's kind of a wording issue rather than it doesn't deserve to be a
stand, if i can put it like that.

Zahed: Andrew, for my discuss, I didn't get any reply from the authors, but
there was some bubble enthusiast was replying to me and saying, don't read too
much into the word experimental or experiments. So I think like the way it is
written, it felt like this is supposed to be experiment and we are not sure
like we have done those experiments. We are not sure like we're confident about
this experiments
 or the results and whatever, so I also suggest like there might be a good
 point of putting an implementation
of status kind of a section because it doesn't claim of having hundreds of
devices already having this one. This is not experimental or we talking about
future experiments and already there is implementation going on in deployment.

Andrew: That's a very fair comment and i'll definitely take that up with
Juliusz. I don't see any real issues on that. I did see a reply on there from,
I think it was actioned here from David. I found his reply to you about reading
8966, and the tone of it isn't something I would've used, but well, I agree
with you on the implementation section would be useful. I do think that it'll
stay a standards track, but i do think there'll be some serious rewording there
to sort that issue out.

Zahed: I'm fine with if the document reports to something that is already
already addressing my comments and I can read about that now, but my point
actually to why I was having that discussion is this is an extension, an
extension is just not relocate patch and we took the diff and say this is a
standards track. It also has to give enough explanation why certain decisions
has been made. To the particular section of a particular RFC, I have no problem
with that, but it does completely doesn't do those kind of things. It's
expecting their readers to actually know a lot and I don't think the RFC should
be like that. That's what my point was also part of my discuss.

Andrew: That's perfectly fair, and like I said I'll be working with them to get
this result.

Martin: Does it really not matter at all what the nodes do with this
information? If everyone picks different magic numbers for their little graph
and you use different algorithms for everything. Does it all just sort of
converge, even so?

(crosstalk)

John: Not everybody has to know everything.

Martin: We're talking about statuses and stuff, and I hate to ask a technical
question, but so Babel's disturbing everywhere and those costs are being summed
into distances to be reported to neighbors right? Then independently i'm
generating RTT submit for my next up, which is not being set through the
network or is it. If the RTT is being propagated through the network as a
distance or is just being used locally to make a decision.

Andrew: I was under the impression that it was being used locally, but I need
to go and dig into that, and let's have a discussion on this afterwards.

Eric: To the cost of the link, Andrew? Like you can get different costs per
link?

John: They used a derivation, step function graph. Where it's like at the lower
step, higher step, and the slant.

Martin: This is a means to a computing cost.

John: That's my impression, yes.

Martin: Alright. I was a little confused.

Erik: Section 4.2

Martin: That should probably work. I'll think about it a little bit. I'll
probably lift the discuss.

Andrew: If you want any words to clarify, because by the sounds of things it
could be misread. Just let me know and I'll chat to them.

Martin:  I think I might have confused myself, but regardless, I think everyone
agrees that maybe a clear statement
 of what is being standard and what is not, would be useful in the document.
 Thank you.

Andrew: Yeah, fair comment. Any other issues that I need to take up with them?

Liz: It looks like the discussion has ended. Revised ID i'm guessing for this
one?

Andrew: Yes, definitely.

Liz: We'll leave this here and mark it as revised ID as needed.

(Discussion went back to draft-ietf-httpapi-link-template-03)

 o draft-ietf-opsawg-9092-update-10  - IETF stream
   Finding and Using Geofeed Data (Proposed Standard)
   Token: Robert Wilton

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

Rob:  I've not had a chance to read it. I'm fairly sure I can see the screen. I
think Paul had some discussion with the authors on this anyway, from what I
recall. So hopefully, you had a chance to resolve this? I felt discussion was
required.

Paul: No, I've not had a chance to see their responses.

Rob: I'm sure we can do it offline.

Paul: Sorry, what do you mean on the fly? Is it right now?

Rob: Sorry, do it offline.

Paul: Sure.

Liz: Does this require a revised ID?

Paul: To bring up that first issue, actually. This is kind of weird, it's a bis
document, But it's standard track? But it doesn't have change control, it's
basically saying we're documenting what the operator community is doing. This
is a bis document and it has already happened in it's predecessor, so I don't
know if it's worth racing it here but it's kind of weird.

Rob:  I sort of feel like the operating community has changed control. I think
it's more that the operating community is acting and what this is doing, as far
as I know. so don't think this is like following along what they're doing. I
think it's giving guidance to them. They're, as far as I understand the
operating communities actually acting on some of this and then moving forward.
Is Warren on the call today because he's one of the authors?

Paul: No, he's on a plane.

(Crosstalk)

Erik: Which is input to all of this.

Paul: Ok. We'll take it offline, sorry.

Liz: So this will stay in IESG evaluation with the substate of revised ID
needed, and then to save us a step for when this does eventually get approved.
This document does have a down ref, so would you like to add RFC 8805 to the
down ref registry? This was in the Last Call, so it doesn't need to be
approved. It's just whether it should be added to the down ref registry.

Eric: Which RFC is this?

Rob: I'm looking it up. It's former, for self published location feed. I don't
think. I can't think it's going to be referenced to that frequently.

Andrew: I'm not so sure about that, Rob. You need to know the format when you
actually add the geofeed. If I may, Paul, as an operator, i've actually
instructed to add geofeed to all of the life objections. My  impression of that
change control was that the change control is in the hands of the operator in
terms of the geofeed file and in terms of the actual geo tagging on the objects
themselves. That was my impression. But I would say that with regards to the
format of their geofeed file, that's pretty important because if you don't know
the format then you can't actually pause the geofeed file.

Erik: That just means it's a normative reference, right?

Paul: I think it's just a phrasing in the document that needs to be fixed.

Rob: As for the down ref, I think it's only whether this is going to be heavily
cited or not that is my stance in the down ref registry, not this one but the
one that is being cited. I'm not sure if it will be 8805, is there any other
reason for it to added to the down ref registry? I should know after four years.

Eric: That is my understanding as well, Rob.

Rob: I think it doesn't really matter, we can do it either way and it doesn't
really matter. Choose one, I'd day, don't add it now and if it comes up again,
then maybe add it.

Liz: We won't add it to the down ref registry then.

 o draft-ietf-drip-auth-47  - IETF stream
   DRIP Entity Tag Authentication Formats & Protocols for Broadcast
   Remote ID (Proposed Standard)
   Token: Éric Vyncke

Liz: There are no discusses so if there's no objections, it looks like this one
is ready to be approved.

Eric: It will be approved, but revised ID needed. By the way, thank you Paul
for deferring it because it allows Adam who is in the call by the way. So if
you have last minute question, you can ask Adam there to address the discuss
from your end, Roman. Thank you so much for deferring it. It's makes things
ever much smoother.

Paul: I wouldn't want to stop you at 47 revision.

Eric: Revised ID needed to address a few comments remaining and thank you all
for this long path together on drip.

Liz: Same question for you, Eric. There are two down refs for this document, do
you want to add these to the down ref registry? They are 9153 and 9434.

Eric: I'm really bad with numbers so can I reply back to you later on this?

Liz: Sure.

 o draft-ietf-ccamp-mw-topo-yang-10  - IETF stream
   A YANG Data Model for Microwave Topology (Proposed Standard)
   Token: Éric Vyncke

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

Eric: No, I think it's pretty clear. So once again, thank you for all the
reviews and the comment is pretty sensible. Rob, I read Scott's reply and
everything will convert quickly. So if you don't agree, Rob, simply go mark it
as revised ID needed.

Rob: I agree.

Liz: This will stay in IESG evaluation with a substate of revised ID needed.

 o draft-ietf-lamps-rfc8398bis-05  - IETF stream
   Internationalized Email Addresses in X.509 Certificates (Proposed
   Standard)
   Token: Roman Danyliw

Liz: We don't have any discuss here unless there's an objection it looks like
this one  is ready to be approved.

Roman: First, I like to thank everyone for the review. Can you put it in
approved and revised ID need? There was that nit that got pointed out that we
should just merge so it doesn't come up with the RFC editor.

Liz: No problem. This is approved announcement to be sent, revised ID needed.

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

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-nvo3-encap-11  - IETF stream
   Network Virtualization Overlays (NVO3) Encapsulation Considerations
   (Informational)
   Token: Andrew Alston

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

Andrew: There were some extensions on this, and I just kind of wanted to
clarify on this. There was a lot of discussion within the working group about
that design team work and I felt that in this particular case, it was worth
publishing why the rational was what it was, and bringing this document
forward, but just thought I'd add that as a note. Inside I did see three
extensions on the document on that issue, but if anyone wants to add any
comments, but other than that, I think we're pretty much good to go.

Paul: Let me comment because I was actually part of a design team that was
later accused of like doing secret things, and pushing things through the
working group without consensus. So I'm maybe a little bit more sensitive to
this, but I would really prefer to have seen that the text should have just
said a design team has done these things and the working group was publishing
this document and the working group consensus made this document just like a
no-brainer. So i'm not sure why it instances on making statements about the
design team because it look at our design team RFC, the only thing the design
team does is bring input to the working group. It kind of violates that in a
subtle way.

Eric: This is basically my abstained position because its becoming working
group documents.

Paul: Yeah, exactly.

Andrew: I would say that the document did have the working group consensus at
the same time. I mean, the team may have written more document, but the
document did have working group consensus to progress.

Paul: If it has consensus then it should make claims as a working group and not
the design team.

Zahed: Can't we just remove the design team section from this draft and publish
it?

Andrew: I think that's perfectly fair and I can certainly ask them to do that.
I think this is gonna need a revised ID anyway.I will take that feedback back
to them and ask them to do that. That's not a problem.

Eric: Thank you, it would be very sensible.

Andrew: I have no issues with that.

Liz: This will go into approved announcement to be sent, revised ID needed.

Eric: By the way, Andrew, when it's done, can you contact me? I will lift my
abstain.  It will not change the result.

Andrew: No problem.

 o draft-ietf-detnet-ip-oam-12  - IETF stream
   Operations, Administration and Maintenance (OAM) for Deterministic
   Networks (DetNet) with IP Data Plane (Informational)
   Token: Roman Danyliw

Liz: There are no discusses in the tracker, unless there's an objection now it
looks like this is approved? Roman, do you want to give this a final look or is
it ready to go?

Roman: First of all, thank you for everything for giving this document a review
and all that feedback. Can you, please put an AD follow up? I have not had the
opportunity to run through everyone's comments. It looks like things need to
change, but I just want to give it a look before I say revised ID. Thank you.

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

 o draft-ietf-dtn-dtnma-10  - IETF stream
   DTN Management Architecture (Informational)
   Token: Zaheduzzaman Sarker

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

Zahed:  So first of all, thanks for the comments. I think those are really
good. Some of the comments, I saw already that Ed has replied and by the way Ed
is on the call, so he can participate in the discussion when needed. On Roman's
discuss, I think Ed replied. I don't Roman if you had a chance to look.

Roman: I have not.

Zahed: To discuss this what we have, Rob, I think you question the formulation.
While we're working on this DTNM, we have been really changing this based on
different comments, so I don't think that would be a big issue. I was more
concerned on whether the motivations are well described or not. Eric, I then
saw you were abstained, that you were missing an external review and as far as
I remember this also had an early external review, but Ed you can confirm these
things.

Ed: Number one, thank you everyone who provided discuss and comments. I think
I've been able to respond to all of them with the exception of Rob's because
that one just came in today. Roman, I think I agreed with certainly all of the
discusses and I think there is some language that we can put in there to
clarify all of those things. All of the comments will only make the draft
better.

Roman: Much appreciated, sorry I didn't have a chance to read it yet.

Ed: No worries, hopefully you'll read it and be very pleased. We did have sort
of two OPS area reviews. One, a long time ago, which caused us to sort of
restructure the document and then more recently, This pass of June in the
detail may -05, Rob had asked Urgan to provide review and he did, it was a
pretty complementary review. I can send it back out, but in particular, he
didn't quite have the same concerns that we were trying to do something that
was absent or against the existing network work that is being done and did not
see that as something difficult to merge together later. So we believe were in
a good position there, but to talk about it here if there are specific
questions.

Rob:  Unfortunately, my review didn't come in earlier, I was on PTO yesterday,
so I had a busy telechat. I think my main concern here is it's still, I think
managed to read all of the details in terms of your new proposed architecture,
but it feels like you are, from scanning that section, you're proposing quite
different architecture for managing these devices.I think you may have good
reasons for that, but from my reading of it, it felt like the document was
saying we've looked at what's already there and, the existing pieces won't work
for this for these reasons. I think a lot of those reasons as to why the
existing pieces won't work is not in my mind necessarily valid as in, they will
support differently in coding, they can support running agent on devices. They
can do these other things, so it felt like the justification doesn't come
through as this document is like we've looked at what's there and hence the
obvious conclusion is we need something new. To me, it's like, we looked what's
there the default conclusion would be, we need to make some extensions to
what's there to achieve this goal.

Ed: I'm sorry, I did not mean to interrupt. But I can clarify that just for a
moment, there is a set of following work happening in the DTN working group
that,that would then be informed by this, and in that case we are proposing
extensions to what is already there. So when we're trying to understand sort of
what we're considering this logical architecture and this notion of agents and
how we would exchange things that is in part to mimic the way that autonomy
systems and network autonomy systems are done in very challenged and
constrained environments because they're for other places that is considered a
best practice. But we think that we can do that within the management tools
that we have today. So, for example, the following documents in the detailed
working group would describe the YANG modules for how we would model this and,
and try and take it forward without presupposing that there would be some
other, transport way of getting something done that would be against things or
something else. So we're trying to put all of it together and, and work through
some of that extensibility, not create a competing ecosystem. We could put into
the document that just clarifies that, that was never our intent to create a
competing ecosystem. It was to explain the need to do this kind of management
and agent- based management and then use subsequent work to do the extensions
that you were talking about.

Rob:  Fine, so then I think what would probably be helpful for this document is
if some of my replies I pointed to bits of work where they're sort of related
to what you're suggesting and some of these points to maybe tie in when some of
that. I still think it might be help to present this architecture document or
an overview of it into maybe like NETMOD, NETCONF, and OPSWG, so that this
virtual wider awareness of what's being done here. I'm more discussion and
interpret between the sorts of two areas because at the moment, it feels like
the DTM works happening. From the rest of the network management stuff, and I
think most probably the network magic guys are not really aware of this so
that, and maybe that'll come out more in terms of the future work here, but I
think that's something that will probably be helpful.

Ed:  I would celebrate the idea of getting more of that overlap and, and some
of that work, my question this informational document as a statement of what we
think is need and defensible need. Is that the document that would be the area
of overlap or should we start that overlap discussion with the existing other
working documents that are not informational? Because I think that's where we
really do need the help to understand how this merges in with the YANG modules
and NETCONF and NETMOD communities.

Rob: I would argue both. So I think they're gonna want to see the justification
cause otherwise the first thing you're gonna get back is probably what you're
trying to achieve and what you're doing it this other way. Effectively, I think
that's what would be useful. So I think it would be worth talking to them soon
and early on this to make sure it's a good overlap and also highlight the
future work that's coming up and show where those document go, like cross
working group reviews to relevant working groups or maybe even happen in those
working groups. I don't know. That might be another choice in things, depending
on what those extensions are looking like, I think it needs coordination here.

Zahed: So on the coordination part, I think, DTNMA is here in front of you
right now because at least I was pushing the authors and the working group to
talk with OPS AD and others so that we get the early reviews. Rob, we have been
chatting about it so we're having some more coordination there. We'll increase
that up in the DTNMA. Now on DTNMA and DTN working group have moved and perhaps
we will have more coordination on such, but I like the idea of like working on
it because I actually support this kind of management architecture document as
informational just to lay out the base and then you work on the extensions to
actually create new technologies. I think that would be helpful. So yeah, I
think I like the idea of like having this one and then also point out the other
things that's happening and later on when we are exactly doing those things in
DTNMA and I do some more coordinated effort, like we did it here makes sense.

Rob: That sounds good. Ed, are you going to be in Brisbane?

Ed: Yes, I will be there. That was gonna be my next question is even before
then would there be a point of contact for each of these other working groups
like that NETCONF and NETMOD that we could send this to for a review. Again, my
hope is to collect those reviews in the appropriate timeframe and then make
sure we get around to -11 or -12, so to make sure we get all of this
synchronized.

Rob: I would suggest you reach out to the working chairs for those three
working groups. NETMOD, NETCONF, and OPSWG, and cc Zahed and myself.

Eric: Not directly to the working group?

Rob: Well, I'd ask the chairs first then they might send it to the working
groups or direct it.

Zahed: We will not approve this, and this will be IESG evaluation and revised
ID needed.

Liz: This will be revised ID 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

 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: Murray Kucherawy

Liz: Unless there's an objection now, I think this one is ready to go back ISE
with the no conflict message. I'm not hearing any objections, I think this is
ready to go. Murray, if you're still with us, do you want to do anything more
to it?

Murray: I don't know what else is there to do after except the IANA action, but
we can take care of that separately, but yeah, ship it.

Liz: We will send this out. Thank you.

3.4.2 Returning items

 o conflict-review-irtf-hrpc-guidelines-00
   IETF conflict review for draft-irtf-hrpc-guidelines
     draft-irtf-hrpc-guidelines-21
     Guidelines for Human Rights Protocol and Architecture
   Considerations (IRTF: Informational)
   Token: Paul Wouters

Liz: Does anyone have an objection?

Paul: Just a reminder this came back from two weeks ago when there was a link
in the document to a GitLab repository that posted comments to existing RFCs
and draft that people were uncomfortable with, so that reference had been
removed, so that was the only change and that was the only objection before. So
I think it's good to go.

Liz: This one is approved, and we'll get a message back to the ISE.

 o conflict-review-farinacci-lisp-lispers-net-nat-01
   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: Éric Vyncke

Liz: Any objection to this going back with the do not publish?

Eric: Looks like everyone agrees to not publish, let's go with this.

Liz: Ok great.

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

 o Detecting Unwanted Location Trackers (dult)

Liz: Does anyone have any objection to this chartering being sent for external
review? Hearing no objections, it looks like this is ready to go for external
review. Roman, is this ready as is or do you want to make any edits?

Roman: First, thank you for all the reviews. Zahed, I made changes for you.
Eric, I made changes for you in the background. John, I am almost done
addressing your feedback. I need to make one more revision before this goes
out, but I hope to have it in the next couple of hours. Thank you.

Liz: Ok perfect.

 o Workload Identity in Multi System Environments (wimse)

Liz: We do have a block on this.

Murray: So the authors are responding, they've already responded to me this
morning. They said they plan to respond to Roman and try to sort this stuff
out. They think it's fixable. I wanted to verify the timeline for this because
I have a slot holding a space for them in the working group scheduling. Roman
and I were talking offline. We think we can still get this through properly
between now and 119 because we have two more telechats and the requirement is a
ten day external review. So I think if I can get this block cleared by about
the 26, we're still good. Does anybody think that's wrong? Roman, did I get my
math right there, in your comments?

Roman: No, I think you have it right. It's whatever ten days is minus 29.

Murray: 3/7, right?

Roman: We can work it out, it's fine.

Murray: If your block clears, and we ship it, as long as we start the ten day
review before 3/7 minus 10 days, we can still make the timeline.

Cindy: You have a little bit of wiggle room because you can make the external
review as short as 7 days. 10 days is the default but you can make it 7, if you
get into that situation.

Murray: I'll keep that in my back pocket, but let's try not to do that by
default.

Roman: I didn't know that.

Murray: That might've come in handy previously. We'll get this sorted out and
we'll let the Secretariat know when we're ready to ship it.

4.1.2 Proposed for approval

 NONE

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: Apologies. I didn't not join the IAB because I had another conflict. I'm
relying on Lars to help me out here.

Lars: It was the long discussion yesterday about the independent stream and
specifically non- widely reviewed crypto standards and I think the outcome is
that Eliot's gonna talk to you and Paul about potential having slot in SEC,
either in Brisbane or maybe in Vancouver where he can sort of have a discussion
with a broader IETF community about what they think that the independent stream
should be doing here.

Mirja: I'm not sure about the slot in SEC, but definitely he was initially
we're thinking like his action depends on what you are doing for SEC and any
kind of policy you're working on, but I think these topics are actually
independent. So I think he will take some action, but it's not clear which
action yet.

Roman: I have not coordinated with Paul at all. So I'm speaking kind of for
myself. I have some hesitation that the IETF stream would try to tell what the
ISE is kind of doing.

Lars: He wants to use the community that comes together in SEC to give him some
data points. Let's call it on, on what it should be doing. So this has nothing
to do with the IETF RFC Stream so let's make it pretty clear that we will not
continue to publish these on that stream, but he would like guidance from
somebody on what he should be doing for his stream.

Roman: Feels like then that the stream manager should organize their own
meeting, and not use IETF SDO time.

Lars: It's not clear that the ISE can ask for agenda time, but it might also be
in IAB open or something.

Mirja: I think that point is completely open. He wants community feedback, but
it's not clear where. Are you have any discussion this time on what should be
published on the IETF stream?

Paul: No planned.

Mirja: He was under the impression the SEC ADs are planning for something and
he wanted to wait for that, but no matter if he's doing that or not. I think we
can do it independently.

Lars: I think he misunderstood something that wasn't going to happen so that's
why.

Paul: I think the confusion might be that we were thinking of an IESG statement
on this, but maybe that's what he's confusing it with. Roman and I have been
thinking, and we haven't really agreed whether we think an IESG statement is
the best way forward.

Lars: My suggestion to Elliot was that he arranged the feedback session. He
wants to have an ask the questions that he wants to get answers to directly
rather than sort of trying to have somebody else do it for him, and I guess
that's what's gonna happen or not.

Mirja: I think the IAB can support it with that, but it will not happen in
Brisbane, so we're looking for July anyways. But it makes sense anyways if you
catch up with Elliot to make sure there's no misunderstanding left.

Lars: That's all I remember from yesterday.

6. Management issues

6.1 [IANA #1353885] Acceptance of media type registration from standards
organization Trust Over IP Foundation Technology Stack Working Group -2 (TSWG)
(IANA)

Liz: This was coming back from last time where people wanted extra time to
review this group, has anyone had a chance to do that?

Murray: I did. I don't have a problem with this. The only thing that gives me
pause is they don't have any plans to submit anything else. So like, why
bother, but there's also no harm in doing it since they seem to be a legit
thing. So whatever IANA wants to do is fine with me.

Amanda: Should this be the larger organization or working group that we name?

Murray: Did the request come from the WG or foundation?

Amanda: It came from the WG.

Roman: Can I put Orie on the spot cause I feel like he has unique insight here.

Orie: I'm not familiar with the specific working group here. I would accept the
foundation based on what I know of the group. What additional questions are you
asking beyond that particular issue?

Roman: Maybe I was just remembering perhaps incorrectly that you were the only
one that actually recognized these folks last time we talked and had some kind
of insight here. But it sounded like you know stuff.

Orie: Yes, I'm familiar with the foundation folks that have been working within
it and this particular media type, like I understand, you know what its purpose
is, and why they're asking to register it.

Murray: So do you have an opinion on whether we should admit the working group
or the foundation?

Orie: I would admit the foundation based on what I know about it and,as an
additional wrinkle, I think there's been discussions about potentially this
group merging with other Linux foundation groups and so I would definitely use
the foundation as the reference point, not the working group.

Murray: Except that then we inherit whatever that merger, I'm fine with this.
Let's just do the foundation. Amanda, can we alter the request and proceed that
way?

Amanda: Sure.

Liz: This is approving the foundation, and are we also adding them to the
standard related organizations that have registered media types in the
standards tree list.

Murray: Yes.

Liz: We'll send that official note to IANA.

6.3 [IANA #1358123] renewing early allocations for
draft-ietf-pce-segment-routing-policy-cp (IANA)

Liz: John, this is one of your document, do you want to let us know what you
think about this early allocation renewal?

John: Yes, let us please renew it. The document is password group last call,
they got some feedback from a director review, they're addressing, but I expect
to see it in my public queue pretty soon, like  within a month.

Liz: Any objections? Hearing none. We'll approve this early allocation renewal
and send that official note to IANA.

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

Liz: This is just assigning this action item to Murray.

Murray: Got it, and I think I have one. I'll get back to us on the 26th.

6.7 Page Counts on Upcoming Telechats (Robert Wilton)

Eric: I'm just suggesting that we can remove some of Roman's draft from the
last one, 3/7. I know you're leaving, Roman.

Roman: I'm not good with that. I want to get mine. I want to get mine off the
plate as well, and  I appreciate, I'm staying on as AD, but I would like to do
as clean up a handoff as I can, and not act like I will not be there. I've
gotten feedback from the community not to shadow SEC AD so I'm trying.

Rob :So, my question really is whether we should try and boost some of the page
count for next week, not working two weeks' time. Sorry, given that the YANG
things are quite light and pushed it up to like six hundred pages to make the
one afterwards not so heavy.

Roman: My only input is that the document I put on 3/7, is not a light read.

Rob: The YANG stuff is.

Andrew: I would personally have no objection because I'm maybe able to get one
of two more documents on there, which will make good to happy, but I have
already got like three on there already so either way.

Eric: I mean, putting it on the agenda if you don't get enough review doesn't
help a lot though, right?

Andrew: Yeah, that is true. How much space is still on agenda for 3/7?

John: Remind me what the benefit is from pushing that stuff forward because
like Eric said, if I somehow find the time to review two agendas worth of
documents. I could give you reviews ahead of time and then they'll still be
reviewed. We would add even more stuff on 3/7 even after accelerating stuff
into the next meeting.

Roman: I think the argument whether you believe it or not is that if you have
stuff that's mostly cooked, it's helpful for the outgoing AD to clear their
desk primarily because incoming ADs will probably want to reset the process,
right? As an incoming AD, will you accept another ADs' review or are you going
to rewind the document for further back. It just introduces more latency in the
pipeline.

John: Understand, are we talking about adding even more documents to the
overall thing? I guess the answer is, yes,
 we were talking about adding even more documents I'm willing to try. I reserve
 the right to click the hell out of the defer button though.

 Martin: Do we have agreement that the, that the February 29th has more
 bandwidth given that it's like twelve pager and then a bunch of YANG and it's
 two weeks, whereas 3/7 is this giant beast that is Roman’s and it's only one
 week? Shouldn't we add stuff to the 29th?

Cindy: Do you want us to take some of the things that are currently on the 3/7
telechat and move them to 2/29 now?

Eric: Maybe we can try? We can also defer right?

Andrew: If you were to move the MSPP, WAN, and the TVR use cases document which
I think are particularly heavy and WAN document has already been through one
ballot process, i'll clear that ballot now so people have already read that
before. If we were to move those three, that would open up some space on 3/7
and that would be a total of 60 pages. I wouldn't move the VPN document because
that's quite a heavy read, but if you remove the other three items than that's
not a problem. If no one's got an objection that is.

Cindy: And it sounds like no one is speaking up with an objection, if you could
stick the, the actual file names of those docs in the chat, then I can make
sure that we move the right one.

Andrew: I can do that right now.

Cindy: And then do we want to put an additional like, set a new cap for the
February 29th telechat?  Like a new page count cap for that?

Roman: I don't think we can pull off what we discussed if without changing the
cap, we've already blown the cap. Question is what is the cap?

Rob: I think if you do the cap at say 550, I think it's still end up being
lighter than normal or the same as normal telechats. I think that a lot of in
the YANG documents, I've had, I think it's a 180 pages, which of those that are
either just IANA registries converted to YANG write script or about document
processing. I think you're sort of reviewing half of those.

Roman: Does that mean I could carve out? I don't know like a 100 pages up more
on the 3/7, 150 more?

Rob: If I get my other docs on, maybe.

Roman: The Janga for me is I have 100 pager which is hard to manage, the other
ones are much smaller.

Rob: Is the 100 page ready to go?

Roman: It's not, it's at the tail end of Last Call so i'll be ready on Monday.

Rob: That could go on the next one, I would suggest you put that one on. At the
end of the day, people can hit defer if they can't manage the reviews.

Lars: If any of you feel bored, right? There is an optimization here that we
can do, which is that we don't need everybody to review everything. So if we
assign sets of documents that basically come to more or less the same page
count to different people then the overlap should be sufficient. But i'm too
tired to write this program now, but we could gain it a little bit like that,
right? In other words, review strategically if something is already good to go
unless you really have a burning desire, maybe pass on that one and review
something that needs ballots.

Roman: Maybe Lars, we leave it to the areas to talk amongst themselves. The
pure ADs can sort it out. What I would say is, I don't want to really offer
this, but I mean, I get the difficult situation we're in, I am still going to
be on the IESG after this. So if you have to choose between deferring an actual
outgoing no longer on the IESG defer mine first.

Andrew: I've dropped the names of the three documents in the chat by the way.

Cindy: Thank you, i'll get those moved.

Roman: And one other thing kind of administ administratively that we can, I
don't know what we're gonna end up with how many we're actually able to work
through the queue one signaling thing that would be helpful for the Brisbane
crew is, could we make the future telechats after 3/7 appear? So if they are
scheduled past the 3/7 we can see which telechat it's on because it's just not
on the page because I think you only show two ahead. Is that hard or easy?

Liz We'll have to work on what the schedule is, so we'll get working on that.

6.2 IETF 119 Agenda Conflict Resolution (Liz Flynn)

The conflict resolution was discussed.

6.6 Executive Session: IESG Confirmation of ISOC BOT Candidates

An executive session was held.

6.5 Executive Session: IETF Trust Appointment

An executive session was held.