Narrative Minutes interim-2025-iesg-01: Thu 15:00
narrative-minutes-interim-2025-iesg-01-202501091500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2025-01-09 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Jim Guichard (Futurewei Technologies) / Routing Area
Francesca Palombini (Ericsson) / Web and Internet Transport Area
David Schinazi (Google) / IAB Liaison

OBSERVERS
---------------------------------

Marc Blanchet
Alper Demir
Abhineet Nayyar
Andy Newton
Ketan Talaulikar

1.2 Bash the agenda

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

Roman: Yes, I'd like to bash a little bit, so I think what we still have at the
tail end in terms of management items is to talk about alldispatch.
Unfortunately, the, the team of Francesca, Deb, and me did not finish
everything we needed to do, so we're gonna move that to the informal. And then,
additionally, I think we have I know at the end we have an exec session to talk
about, I think it's framed as one appeal. We're actually going to talk about
both appeals, and we gotta figure out how to split that time up when we get
there.

Liz: Okay, got it. Any other changes to today's agenda?

1.3 Approval of the minutes of past telechats
Liz:  Does anyone have an objection to the minutes of the December 19 2024
teleconference being approved? I'm hearing no objections so those minutes are
approved and we will post them in the Datatracker. Does anyone have an
objection to the narrative minutes of December 19 teleconference being
approved? Not hearing objection there either, so those are also approved and we
will also get those posted in the Datatracker.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

        Last updated: December 19, 2024

   * DESIGNATED EXPERTS NEEDED

     o Murray Kucherawy to find designated experts for RFC 9559 (Matroska
       Media Container Format Specification) [IANA #1385324].

Murray: In December I emailed the list with two candidates for this. I can
message them to you over Slack so we can add the item to approve them later.

Liz: Just send us those names and we can add something at the end.

     o Paul Wouters to find designated experts for RFC 9668
       (EDHOC Authentication Credential Types)[IANA #1401194].

Paul: I actually forgot about that. So I have two. I'm still waiting on the
confirmation of the 3rd one, so I'll just ping them and get the answer next
time.

   * OPEN ACTION ITEMS

     o Murray Kucherawy and Éric Vyncke to create a draft IESG statement
       about using 2119 language.

Murray: Still open, haven't touched it yet.

     o Roman Danyliw to work on adding a checkbox to the meeting
       registration system asking people to identify they are willing to
       serve as WG chair.

     o Roman Danyliw to take a look at Datatracker documentation of
       document states and update as needed.

     o Roman Danyliw to work with Secretariat to update non-wg list
       guidelines webpage.

Roman: The next four are to include that all the ones tagged as me for the next
four after that are all still in progress.

     o IESG to decide whether we are going to collectively agree to opt in
       to the RPC auth 48 Github experiment if authors are part of the
       github experiment.

Liz: We said we were going to add this to an informal to discuss, so that's
still in progress as well.

     o Deb Cooley, Roman Danyliw, and Francesca Palombini to review
       the ALLDISPATCH feedback.

Liz: We just talked about Deb, Roman, and Francesca to review the alldispatch
feedback, you said just a minute ago that that is still in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-emailcore-rfc5321bis-38  - IETF stream
   Simple Mail Transfer Protocol (Internet Standard)
   Token: Murray Kucherawy

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

Murray: I think I can go through them relatively quickly despite their size. So
1st on the comments that double slashed like the C++ style comments, I think
that we left those in because some of them were meant to explain why we did
something or did something else, but I didn't notice that some of them actually
talk about all the old items that have already been resolved, and they just
created more confusion than they were meant to resolve, so I apologize for
that. That was an oversight on my part. I'll have them remove them all. There's
actually nothing for us to worry about in there if you didn't find them
helpful, they weren't meant to be harmful, so we'll just clean them out, I
think that deals with actually most of our most of the stuff already raised.
The stuff about security is meant to be so the the issue just so for
everybody's background is that SMTP, as you may or may not know, is an entirely
insecure protocol. It was built back in the time when like there wasn't TLS
that there's nothing in SMTP to prevent you from claiming to be something else.
We added text to this document to actually call that out in a minute, and there
are extensions that provide those capabilities now. The decision or the
preference of the working group is not to make those core, like it was, it
seemed weird to us to create extensions that become mandatory. So, this
document still just covers base SMTP and also this the charter for this working
group was set to say to move something from the status of draft standard which
doesn't even exist anymore into internet standard and change as little as
possible, like clarify a few things, remove anything that was that is not in
use and then move it forward. So that the delta between the older version and
the new version, sorry the 5321 and this one is really what what they were
meant to produce is keep that minimal, so don't crack open any old debates
about what that term means or this term means, which leads to some of the
comments that I saw about why is this the way it is? It wouldn't pass today,
but we're very constrained here to only modify a few, the things that have to
be modified and clarified like using errata and stuff like that. That leads us
to not modernizing it in ways that we would expect a new protocol to be
modernized today around crypto and whatnot. The decision was made to put all of
that type of material in the applicability statement, which is the document
coming after this one and that will all be done as part of a cluster. From the
dialogues that I've heard, this can be resolved by making the reference to the
applicability statement normative, which the working group doesn't have any
objection to. So I think that clears up, part of Paul's objection and some of
the other ones like Ekr's and Martin Thompson I believe, and Rob Sayre. And
another point that was raised was there was not consensus to proceed because
that hadn't been resolved yet. I expected that to resolve as a result of last
call feedback. That was also my mistake, it didn't. It was much more of a
contentious debate than I expected. So the solution to that will be to run.
After that has resolved, the reference thing has been resolved. We will run a
second last call to make sure the community is fine with that change as
supporting the objection in that case. So I think I'm looking at Roman's
discuss which came in kind of late and I think a lot of the stuff had to do
with the comments as well like. At least two of yours cover the double slash
type things which I said we're just going to remove. There are,
 there's an outstanding IANA issue that I know we have to take care of. The
 issue there was that in the IANA consideration sections. The working
group presented some stuff for IANA to decide, the idea was this is what the
registry needs to say. Iana can present it however they want. IANA doesn't want
any decisions left to them. They just want this like basically it should be
called IANA instructions as I understand it. And so that's totally fine as well
and so they're gonna tighten it up and say do it this way, the working group's
gonna make the decision. And Eric's discuss, I am seeing for the first time,
I'm waiting for the working group to answer that one. So does that leave
anything major unaddressed? Is there, I mean I've given you a long summary to
what I'm asked to do a few small changes that should resolve most of all of
this while I talked for a long time.

Roman: So Paul I'm gonna talk about security stuff that's related to your
discuss because I supported yours instead of reiterating many of the things
again. So Murray, so the thinking is that we would make a normative reference
to the applicability statement and then we would reserve the  debate in the
applicability statement about what are the mandatory, the MUSTs or the SHOULDs
about using particular extensions that would make this viable on the open
internet.

Murray: There is text in this document now that says this is an old protocol
that doesn't have these capabilities. There are extensions that cover it that
basically are mandatory on the modern internet. Because we are constrained
about how much of a delta we're allowed to create in moving something from the
old status to the new status and the charter said you're like, don't do any of
those things, they stayed within their charter by not doing that here and it
also does seem weird to say that extension is now mandatory. So yes,the short
answer to your question is yes, all this discussion about how to take this
vulnerable protocol and use it in a contemporary way will live in the AS and
there will be a normative reference to the AS, which I think Ekr described as
closure of all the material if we make this a normative reference. So the short
answer to your question is yes.

Roman: And there is still anticipation that there will be a lot of work on that
AS document because my read, again, I didn't really review it. I just kind of
scanned because it was, it was referenced a number of times. What the AS
document does is not as far as I can tell, provide guidance on how to use it on
the real internet. What it names is the possibility or the existence of
different extensions. So e.g., I did not see language that says Start TLS is a
MUST if you're on the open internet or SHOULD. Are we expecting that to be
discussed or are we thinking the AS is done in.

Murray: No, the AS is not finished and that's something we can lean on. We can
be much more prescriptive or advise whatever provide pressure to move the AS in
that direction if that's what they want or sorry, if that's what we believe
should happen. No the AS is not finished.

Paul: I think also if you look at Martin Thompson, Ekr, and me that's what we
would require to be in that document. It would basically have to say something
like, it's not appropriate to send clear text email without encryption over the
Internet.

Murray: Right. And I think the working group has already expressed their intent
to solve this problem in that particular way. Because 321 bis depends on 5322
bis, and they depend on each other and now the AS is wrapped into that, they're
all gonna go as a cluster.
 So, if there ends up being some small additional text that needs to be added
 in the bis documents with the AS, they're all gonna go up together and that
 can be addressed.

Paul: So that's good with me. I'm not sure if Roman is good with that.

Roman: Sorry. I mean if we make the AS document be normative and we say we're
gonna have this security kind of conversation there that would resolve that
that would be kind of resolved kind of the substance of my concern with the
security.  I mean it doesn't resolve any sense I know what the answer is but
procedurally it resolves that we're gonna cover it in a different place and we
have a normative requirement. The one thing I did see didn't see in the AS
document is that I didn't see kind of clear language, in the bis document that
said you must follow what's in the applicability statement, and I in the
metadata tagging, maybe I missed it in the AS statement, nothing said we're
updating the bis document. So I think we need something a little tighter to the
languages too.

Murray: I've done AS before on things that are like lesser than this and I
don't remember them saying that the AS updates the other thing, but I suppose
that's also an option.

Roman: I'm just looking for whatever is the procedural with metadata or with
inline text that it is clear that from one or the other that you must follow
whatever is the additional security stuff specified in the other document. I'm
flexible on how that happens.

Murray: My understanding from talking to Ekr was that that he was satisfied
with just the normative reference, and we can also add stronger text in the AS
pointing with the saying again I'm sort of babbling of it yes, we can do it
this way.

Deb: And maybe clear text in the security considerations of this document.

Murray: I thought that it was there, but if it isn't.

Deb: I think it's a comment. It's one of these issue things.

Murray: Oh then yes, we can promote that to real text then. I thought I had
them add a paragraph at the top of section seven that said something like this.
I can make sure that it's as strong as it should be. Orie, did he cover
everything about yours? It's I think yours was all related to these weird
comment things that we're just gonna rip out anyway.

Orie: Two of them are. The other one is about the deprecations in the appendix
and the normative references.

Murray: Oh right, yes.

Orie: It's mostly just like, you know, this is maybe a style thing, maybe it's
not even within the discuss criteria, but it wasn't obvious to me whether this
document is performing the deprecations. The appendix has a BCP 14 language and
 it's telling you very clearly what you must understand and you must do and it
just is a little bit confusing that it's in the appendix with all of this
normative treatment there. I would prefer to see the exact section as part of
the body since it's part of what you must understand in order to implement. I
gather this is left over from the desire not to restructure the document
perhaps, but does it count as restructuring to move the section without making
any changes.

Murray: I remember now where we were talking, we talked about this a little bit
over Slack too. I think this was relatively easy to resolve. So the only thing
I haven't talked about yet is just Eric's, but that's because I came in in the
last few hours, and it doesn't look like that's a major thing, so I'll take
that up directly with the working group.

Eric: It's basically the wrong reference. It's an important one.

Deb: So that paragraph you asked for is considered a security section. It's
just prefaced by issues that make it sound like maybe it's not. The whole issue
was confusing.

Murray: It was me that suggested leaving those things in thinking they would be
helpful and they ended up being exactly the opposite. So I'm sorry for
confusing everyone with it. Did I miss anything or are we pretty much
understand what the action items are here for all of them and we can just I can
do any follow up and I can ping people individually once a new version is up to
make sure we're good.

Roman: I just wanted to double check on the IANA. So there's additional work
that's gonna be done to clean up the the the some of the IANA stuff
specifically I called out one where I don't understand the redefinition of the
guidance.

Murray: I believe yes, that there's a separate thread. Another thing
complicating all those is there's like nine threads live, one with IANA, one
with each of you, several of them with me, so anyway, one of them is one of
those is renegotiating this text with IANA to clarify it and not leave them
having to do stuff they don't want to do. AD follow-up for this, please.

Liz: So this document is staying in IESG evaluation with a substate of AD
follow up and Murray, just so you have a heads up, once this gets to approval
time, this document does have two down refs, so we are gonna ask you if you
want those to be added to the down ref registry.

Murray: They were part of the last call, right?

Liz: Yes.

 o draft-ietf-nfsv4-layoutwcc-05  - IETF stream
   Add LAYOUT_WCC to NFSv4.2's Flex File Layout Type (Proposed
   Standard)
   Token: Zaheduzzaman Sarker

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

Murray: I'm piping up on this one because I commented on Gunter's discuss. Yes,
your proposed suggestion is totally fine with me.

Gunter: Okay, cool. So I'll remove this case once it is updated. Perfect. Thank
you.

Liz: Okay, so this document is staying in IESG evaluation for now and it looks
like we're waiting for a revised ID, so revised ID needed.

Zahed: That's correct, and thanks for this. Just for your information I didn't
reply, but just for everybody, this has been discussed. I mean, I already
flagged this out in my AD review so I was waiting for the authors to actually
chime in, but this is easily solvable.

Gunter: Yes, thank you.

 o draft-ietf-bfd-large-packets-14  - IETF stream
   BFD Encapsulated in Large Packets (Proposed Standard)
   Token: Éric Vyncke

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

Eric: I don't think so and first let me thank let me thank all of you, and I
think this one is the, the most recursive ballot because if you look about it,
Murray, thanks John, we repeat what Warren said, we will repeat what Jim said.
I'm taking all of them in the same thought. Anyway, Zahed, about the padding,
that's your plan? So I will work with the authors then specify what is done
with the padding field, so it's revised ID needed for sure and thanks again for
the review.

Zahed: Yeah, so Eric, I mean I got a reply from Jeff. I'm actually seriously
confused now with that reply, so we need to work on it. I would like to
understand other AD's view I mean this is something this is a specific you must
put zeros and then the idea is like to not take a look at it. It doesn't mean
anything. At least for me, if I put some MUSTs somewhere, I have an error code
or like if I mean, what happens if this is that should be pretty clear. It's
not clear, so that's why I put it and discuss and I hope that we can clarify
that one when you're discussing this without the authors.

John: Just to ask, I mean, so as I understand the draft, all the stuff in the
padding is explicitly outside the the the boundaries of the BFD frame per se,
which means BFD has no business looking at it. I mean, yeah, I agree it's a
little weird to say zero fill this but that's none of your business. Would it
be clear enough from your point of view if the spec explicitly said there's no
expectation that the receiver will check this?

Zahed: Perfect because that's what I mean I think missing. I mean exactly, that
was the confusion, so I had two confusion was like am I doing a path part into
discovery with BFD, which I don't think we should. And then Jeff said, No, we
are not doing it, but it actually not explicitly saying like, I have to more
than one hope, I know one MTU, I don't know the other MTU, so I'll try longer
packet size and try to understand what is the sustainable MTU. That's basically
the thing. I mean that's if you don't call it discovery I don't know what you
should call it. And then when I say that ok with this one this 01 said I
understand that might be security thing you don't want to link that's why
sender should put zero, but what if it doesn't, and what if if the VFD doesn't
look at it, let's just split it out. I'm just doing this for the sake of
learning the NTU. And I'll BFD will not look into if it is zero or not, this
should be handled just exactly what you said, John, like that if you write that
thing, I think this is much clearer and I don't have any issue.

John: Cool. Thanks.

Liz: This document is staying in IESG evaluation and I think I heard Eric
revised ID needed for the substate.

Eric: This is correct.

 o draft-ietf-nvo3-geneve-oam-14  - IETF stream
   Active OAM for use in GENEVE (Proposed Standard)
   Token: Gunter Van de Velde

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

Gunter: I think there is good discussion going on between Eric and Greg on this
thing, some alternative approaches. Maybe Eric, you wanna say something about
that, but I think it is going in a good direction.

Eric: I would say so. So clearly for me, that's the way it's written right now
is a clear and no go, but they are alternative ways. I propose simply using the
discard prefix for instance, which is basically a global address. It can be
used in destination but will be rejected anyway, so there will be no leak, no
forwarding or whatever. And there are other ways of doing it.

Erik: Or we just go and allocate something new related to the same discussion
on the other document. They've been using colon colon one for a long time, the
general PFD and OAM type scenarios. Not a long time, but yeah, anyway,
apologies.

Eric: The another way is indeed to request a prefix, and it could be easy.

Gunter: I think actually, and I think on the longer term it probably makes
sense to some degree? Because you also do some delay
 measurement on links and things like that. And then there is also some
 prefixes being used in destination, things like that, so it could be
 worthwhile to investigate.

Eric: Now we may want to decide whether we because there was the other one? The
MPLS BFD, which is exactly the same thing, the same motors, this is Greg as
well. It's a reasonable guy any anyway, so we could block both of them and
asking IANA to allocate a prefix, I mean, a /64 that's a no brainer.

Erik: Why a whole prefix?

Eric: Because if you want to experiment with ECMP, you want to get the
additional address varying to provide entropy so you can test all the ECMP path.

Warren: It fits in well with the IANA thing, getting an address seems tricky
and complicated, whereas /64s are free.

Erik: I mean you could just allocate ::2 as an additional loop, it doesn't seem
that hard.

Warren: Actually something which I think we should really discuss is there's a
bunch of places where having the loopback network in V6
 would be really helpful instead of simply having a loopback address. There are
 a lot of places where people who would like to be able to use that.

 Erik:  We had 100 ::/forty eight, I think previously proposed. It got down due
 to some complaints from certain people as I recall,
but that doesn't mean it couldn't be revisited.

Warren: Who wants to revisit that with me?

Eric: No problem for me, it depends. So if INT ADs are doing then it includes
myself when it comes to IESG evaluation, so assuming I'm still reselecting.

Warren: So Eric and Erik.

Erik: Include Suresh too.

Eric: There's basically two things. There is the loopback prefix because it's
useful and this one is the kind of, this address is never forwarded, it should
not be received. Like pretty similar to the discard prefix for this kind of
thing.

Gunter: But it's not really a discard, is it? It's a valid drop, you expect the
packet to go there.

Eric: Yeah, but you don't process it at the IP layer because it's a dummy one.
It's simply to test the underlay. What is sending the overlay should be
discarded.

Erik: Not discarded. Discarded.

Eric: But like not forwarded or not processed BFD.

Erik: Right. Which is why they want the loopback, but like, I think I think if
I understood Warren's proposal correctly, if we allocated say like the the old
100 ::/64 or 48, addresses from those prefixes would be, would appear in the
destination address embedded down and encapsulated in these measurements.

Warren: I think my suggestion for the loopback prefix is orthogonal to this. It
should be similar to 1270008 or whatever it was. I think there are too many
zeros, but similar to the V4 thing in V6 because people sometimes needs to stay
local to a box.

Erik: Not applicable to this particular problem. Misunderstood there.

Eric: And for the for this one Erik, we can also try to get /24 for IPv4 for
the legacy one in the same document or whatever so it leaves open. It's up to
the authors and you, I guess, to see what's the best way to proceed. Cause we
can make requests a specific prefix for this and IPv4 and IPv6 for both
documents or because if we need to create a new draft, even if we expedite it,
it is sponsored. Requesting a kind of I would call it discard for now, even if
it's not the right term before and V6 prefixes, it will take months.

Gunter: I don't own the other document.

Eric: Yeah, it is Jim. I don't think he will be on the call.

Erik: If we did a document that allocated ::other prefix, it would, it would
have more than just this document to update, I think. There's the MPLS LSP ping
document that also uses ::1.

Eric: But you can create a document allocating the prefix without updating the
other one. Basically, we create a prefix, we offer the prefix to the community.
Please use this for your document, and then this one in the MPLS one can refer
normatively to it.

Erik: I guess I'm saying like you could block this waiting for that document,
or or you could not block this given that it's already current behavior and
then just have a future document update this.

Gunter: But then it will still have it discussed.

Eric: I mean honestly Gunter, I cannot approve this document with the same text
right now. It's easy to change.
 I propose a discard prefix for instance.

Gunter: That is what I was saying. So even if we do the approach what the other
Eric was saying, the document is still blocked because it is doing something
which it shouldn't be doing.

Warren: So what's the disadvantage to just asking IANA for a prefix for this,
this document? Seems like that would be faster than the whole.

Eric: The only thing I would say is that there are two documents right now in
this by coincidence. Having the same problem. So if we fix for one, the other
consideration is if this one has an allocation, but what about the other one?
We can ask to please allocate a prefix as the same as
draft-ietf-nvo3-geneve-oam. I guess IANA would comply but it's kind of strange.

Warren: Yeah, it's kind of strange. You're right.

Eric: That's doable. It would be perfect for me  but then after if you get
other documents, they cannot really refer to this one. No, because that doesn't
do anything with nvo3.

Gunter: So the real long term solution is to have its own document allocate the
whole prefix thing.

Warren: No, I think I think the long term thing is we have a document which
asks for a loopback prefix and a discard prefix. Maybe one document, maybe two
documents, I think we try it with one document and if it becomes sufficiently
controversial, we say, Great, we're flipping into two documents.

Erik: But isn't there already a discard document?

Eric: There is one. IPv6, not for IPv4.

Erik: Oh, and we can't just discard all of v4, I guess.

Roman: Do we have a plan or do you want to kind of table the continuation of
this conversation to work out a plan?

Gunter: Let me check on this particular document, let me check with Greg to see
if he can live with the discuss prefix for IPv6. And I think on the longer term
we probably need to think about the the other two prefixes and the other
document which can be used in the future for like other documents doing
something similar each from an OEM perspective.

Liz: Okay, so then this document is staying in IESG evaluation and AD follow-up
or would revised ID be a better substate?

Gunter: I think revised ID needed.

Liz: This will go into revised ID needed.

 o draft-ietf-lsvr-bgp-spf-44  - IETF stream
   BGP Link-State Shortest Path First (SPF) Routing (Proposed Standard)
   Token: Jim Guichard

Liz: I think Jim is still not on the call. So anything you want to go over
without Jim?

John: Well, I see that Ketan is on and he is the document shepherd. I guess I'd
invite Ketan to speak if he wants to, otherwise I think we can just defer this
to when Jim gets back.

Ketan:  I think thanks for your review and I don't think the author or the
editors have had a chance yet to respond. I haven't seen at least. So, we
probably might need a bit time to go.

John: No worries, you know where to find me.

Roman: So maybe we mark this since Jim isn't here as AD follow-up.

Liz: This one is staying in IESG evaluation with a substate of AD follow-up,
and Jim can figure out what to do with it from there.

 o draft-ietf-acme-onion-05  - IETF stream
   Automated Certificate Management Environment (ACME) Extensions for
   ".onion" Special-Use Domain Names (Proposed Standard)
   Token: Deb Cooley

Liz: It looks like we have a discuss, do we want to discuss this now?

Deb: I don't think so, but we can put it in revised ID needed.

Liz: This one is staying in IESG evaluation with a substate of revised ID
needed.

 o draft-ietf-cbor-cddl-more-control-07  - IETF stream
   More Control Operators for CDDL (Proposed Standard)
   Token: Orie Steele

Liz: There are no discusses so unless there's an objection now, this one is
approved. We can call this one approved.

Orie:  I haven't had a chance to fully read all of the comments on this. Sorry,
I'm running a bit late. Skimming them now?
 I'd like it to be AD follow up if I can just to make sure to close out any of
 the remaining comments.

Liz: This one is approved announcement to be sent; AD follow up and you can let
us know when it's ready. And also Orie, there is a down ref, so RFC 9285, do
you want to add that to the down ref registry?

Orie: This was on the last call right?

Liz: Yes.  When you let us know when it's ready to go, if you could just also
let us know what to do with that downref.

 o draft-ietf-mpls-p2mp-bfd-09  - IETF stream
   Bidirectional Forwarding Detection (BFD) for Multipoint Networks
   over Point-to-Multi-Point MPLS Label Switched Path (LSP) (Proposed
   Standard)
   Token: Jim Guichard

Liz: We have a discuss, anything to discuss on this now?

Eric: As far as I know, Jim is not on the call. It's basically very similar to
the nvo3 draft discussion with exactly the same problem. So I guess the same
solution applies as well and this is the same authors by the way.

Liz: This one will stay in IESG evaluation and we can just put this in AD
follow up for Jim to take from there.

 o draft-ietf-acme-ari-07  - IETF stream
   Automated Certificate Management Environment (ACME) Renewal
   Information (ARI) Extension (Proposed Standard)
   Token: Deb Cooley
Liz: We have a few discussions. Do we want to discuss these now?

Deb: I don't think so. I don't think they're hard to discusses honestly.

Eric: May I ask somebody from layer seven to review my discuss because that's
linked to HTTP and I'm unsure. So it's not an IP layer, so I don't know exactly
what's happening there, but I think this points.

Deb: Right, and we didn't have that review done, which we could do still, right?

Eric: I think simply if Orie or Murray can have a look and see whether I'm
completely wrong or not. Section 4.1 in the example.

Deb: Your question is whether the GET is correct? So you think Murray will know?

Eric: I hope so.

Orie: It's section 4.1?

Deb: If you look at it, it's got both. The current one and the one he thinks it
should be. I do think there's some issues with the this is ari, not onion,
sorry I'm getting my drafts confused. Example.com is OK for ari, but not ok for
onion.

Murray: So are you talking about my discuss? Let me bring the doc up.

Deb: I'm looking at Eric's discuss.

Eric: But I would love to have you take a look at it.

Orie: I think this is just an expression, the two possible text options are
both sort of, not, oh, I guess the difference is, is there's no protocol
example in your proposed text, Eric.

Zahed: I mean the thing is like if I definitely look at it, we can have have
this discussion, but this get can take URI URL or like resource or a relative
reference, relative URI, whatever. The GET method takes quite a while. A lot of
different static values, so, I don't know in what sense we should call it
incorrect. I think it just should say like you have a GET method with this
resource look at her and that's fine. Maybe rewriting this one in a different
way would be helpful, but then if you really would like to have an example, GET
method, then I can place some example how it should look like. I mean just just
go to MDM modular and then find a GET example you'll see how but I agree with
Eric like this is not the typical
 way you put an example GET but yeah I can live with that one, but there is a
 better way.

Murray: Orie would know better than me, can you put a full URL in a GET? I
thought that protocol and the and the authority which
 is the host were part of, like that's part of the connection that's
 established.

Eric: The only time I see a get with your URI is when you're using a proxy.

Murray: And that's a proxy language.

Orie: The way that this example is structured it is not, it's not sort of
precise enough to really tell the intention I think there, and then also like
is the goal to support HTTP without the S? I mean because  that's sort of
implied in the alternative text, but I think we have WIT, this is more a WIT
thing. He kind of answered it, I would take his advice.

Zahed: That's the only reason I talked about that one. I mean, as I said, I can
help you out, but this is fine. The syntax of the GET request target and then
the query. That's the syntax, but then you you're fine with saying like if it
is absolute part is the related part, I mean, you can go into that details of
how these request queries could look like. Obviously we can have a better
representative that's what I'm saying. I'm also saying that the way this is
written now is not completely wrong. I mean I can leave with that one as I
said, but there are examples I think we can just find a good example let me
because you can have quite a lot of host access, what not, maybe you can put a
full of HTTP headers but that's not the intention, I guess.

Deb: So what I get out of this is that his original get request isn't wrong
necessarily, but it's not the best.

Zahed: Yes, that's correct.

Murray: The semantics are there, the syntax is wrong. Maybe that's a good way.

Deb: So then what we need to do is make sure that we get a better example that
gets the syntax correct. I think he does want HTTPS honestly, you don't want to
do this over bear HTTP.  So that part is, is correct however we structure that.
Okay, so I think I understand what the what the issue is. So Zahed, would you
be interested in replying to Eric's discuss in an email?

Zahed: If I can find a good way of representing this one. Let me have a look at
it because what I'm also struggling is like the request target, it doesn't need
to have this HTTP protocol. The GET doesn't care.

Tommy: It seems that unless they're trying to make a very particular point
about this is different from normal HTTP and like how you would normally
construct it. You should just there, there are so many examples in other RFCs
of very simple example.com GET requests, just like make it look more like those
and we could help point to any number of them, but at this point it does not
look like that.

Zahed:  I mean the the intention was not clear and I that's why I'm struggling
with that like because I do have a solution
 right now in my head. I can just point it to that one just I will read that
 more carefully and come up with something.

Deb: That would be lovely, if you don't mind doing that.  Even if you were to
reply to your own comment except it wasn't sent, right? So if you don't mind
doing that, I would appreciate it. It's definitely revised ID.

Liz: So this one is staying in IESG evaluation with a substate of revised ID
needed.

 o draft-ietf-jmap-webpush-vapid-09  - IETF stream
   Use of VAPID in JMAP WebPush (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: If there's nobody who wants to discuss any of their comments, then
let's go with approved AD follow up, please.

Liz: So this one will be approved announcement to be sent AD follow up, and you
can let us know when it's ready.

 o draft-ietf-lamps-cms-sphincs-plus-17  - IETF stream
   Use of the SLH-DSA Signature Algorithm in the Cryptographic Message
   Syntax (CMS) (Proposed Standard)
   Token: Deb Cooley

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

Deb:  I think we're mostly resolved here. He needs to push a new update and
Paul needs to check it.

Paul: That's right.

Deb: So revised ID needed, please.

Liz: So this one is staying in IESG evaluation with a substate of 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

 o status-change-early-hints-to-proposed-standard-00  - IETF stream
   Status Change for RFC 8297 "An HTTP Status Code for Indicating
   Hints" to Proposed Standard. (None)
   Token: Francesca Palombini

Liz: So I guess the question is do we approve the status change? There were no
discusses, so unless there's an objection now, this one is approved.
 we also it looks like we have the consensus set to unknown on this so we will
 go ahead and change that to yes. And since Francesca
is not here today, we'll just go ahead and put this in AD follow up, so
Francesca can follow up when she's back.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-pquip-pqt-hybrid-terminology-05  - IETF stream
   Terminology for Post-Quantum Traditional Hybrid Schemes
   (Informational)
   Token: Paul Wouters

Liz: There are no discusses so unless there's an objection now, this one is
approved. Ok. I'm not hearing any objections so this one is approved. Paul, is
this ready to go or do you want to do something else to it?

Paul: Yeah, it's ready to go.

Liz: This is approved announcement ready to be sent; no substate so we'll go
ahead and send that announcement.

 o draft-ietf-lsvr-applicability-20  - IETF stream
   Usage and Applicability of BGP Link-State Shortest Path Routing
   (BGP-SPF) in Data Centers (Informational)
   Token: Jim Guichard

Liz: We do have a discuss. John, do you wanna say anything about this now? Jim
is still not on the call.

John:  I already talked with Ketan in the chat and same disposal as the
previous one, so we'll just wait for the authors on it.

Liz: So this one is staying in IESG evaluation and we will give it AD follow up
for Jim.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-rivest-sexp-12  - IETF stream
   Simple Public Key Infrastructure (SPKI) S-Expressions
   (Informational)
   Token: Murray Kucherawy

Liz: We have the consensus as unknown for this one, so we'll go ahead and set
that to yes for you.

Murray: I can't believe I missed that.

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

Murray: Very briefly, so this document so everybody else knows this finally
defined something that was actually referenced back in RFC 2692. It is not
actually trying to standardize that necessarily although. So that would have
made sense to do at the time. So one of the outs here for and sorry and one of
the problems here is that it doesn't pay attention to something contemporary,
which is internationalization, and I think that was at least part part of
Paul's abstain and a chunk of Orie's discuss. One of the things that we're
considering doing is just changing it to historic, which, I don't mean to be
flipping about it, but basically we'd forgive it for not addressing that 
important thing. This isn't meant to be  a modern technology. I believe there
are other variants of this that are much more current, but it's just meant to
document something we should have documented a long time ago. It was last call
that was informational. The author has said you guys can change it to whatever
status you want, and I said, well, it's not quite that simple, we can't make it
proposed standard without another last call. But do, does anybody think that we
would need to last call it again to go from informational to historic or was an
informational last call good enough to defend historic status?

Warren: I suspect that doing a very short last call would make sense, just note
that this is all you're doing and so hopefully people will calm down. It seems
like one of those things where it's safer to ask just in case, but you should
probably kick it off soon just.

Roman: I strongly agree with that.

Murray: That's totally fine. So the other thing that possible resolution is
that he is thinking about adding UTF eight examples, which I guess would also
solve the problem. So I will resolve this with the author either by doing a
last call on a historic and not changing anything or letting him add those
examples and making sure that Orie and Paul are happy with it. And I don't need
I don't need to swing Paul off the abstained, but if it does, then great.

Roman: I would point to if those not watching the larger IT have discussed
manually lists, the larger discussion about what is historic and all of the
intended kind of challenges.

Liz: So this document is staying in IESG evaluation for now.

Murray: AD follow up, until we decide whether it's going to be a status or a
new revision. I'll change it as appropriate.

Liz: Ok. Perfect. This one will be AD follow-up.

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-cfrg-opaque-00
   IETF conflict review for draft-irtf-cfrg-opaque
     draft-irtf-cfrg-opaque-18
     The OPAQUE Augmented PAKE Protocol (IRTF: Informational)
   Token: Deb Cooley

Liz: There are no blocking comments so unless there's an objection, it looks
like this is ready to go. Deb, is there anything you want to add to this  or is
this ready to send back?

Deb: Ship it.

Liz: So this one is ready to go and we will send that no problem message back
to the IRTF.

3.4.2 Returning items

 NONE

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

 o RESTful Provisioning Protocol (rpp)

Liz: We have a couple of blocking comments, do we want to discuss them now?

Orie: So this is my 1st charter that's gotten to this sort of stage and I've
already shuttled some of the IAV review back to the group to propose some
changes to the text. I guess I'm just sort of wondering process wise, what is
the best way to sort of provide a revision and then check back to see whether
the blocking comments have been addressed. Maybe that's better to take offline,
but, thank you all for the comments on the document. I think they're all
awesome.

Roman: Happy to follow up offline, Orie based on the feedback and on the kinds
of process stuff.

Liz: And so basically the the things we normally would do with these are either
wait for instruction from you Orie, send it back to internal review or just put
this back on the agenda next time right in the same place. So if you know yet
any of those three things you want to do or you can just think about it and let
us know which of those you want us to do.

Orie: I don't know that it'll be possible to clear these comments between now
and the next, so whatever the longer timeline path is.

Liz: Ok. We'll just wait for further instructions from you.

 o Taking IP To Other Planets (tiptop)

Liz: I don't see any blocking comments here, so it looks like this is ready for
external review.

Warren: Apologies for not having mentioned any of this earlier, but and for not
being that informed. But it feels strange to me that we need a working  group
for this, which I thought seemed like a relatively small thing. I thought this
was largely can't we just ask the RAR to please set aside some space and move
on with life or does it require all of this?

Eric: No. It's it's not about IP prefixes So I know that some people in the
ready to the potential working group wants to do it, but I think it's really
too far-fetched for now. So it's not about allocating, 3000/8 or whatever, for
IPv6 to the moon and another one to the mass or whatever. So it's way too
premature. It's it's really to check whether the existing protocol can have
been tuned in the sense of not modifying the protocol but maybe modifying time.

Warren: Ok. I completely misunderstood so no objections.

Eric: Thank you all for the review. As you have seen I just updated the charter
minutes before the call with the proponent and thank you Erik for changing your
point of view.

Erik: Thanks for addressing the comments.

Zahed: Thanks for the clean-up.

Eric: It's cleaner. It's clearly implemented. You change the charter, you
change it, you change it, and then it was done
 before the Christmas shutdown and then I did not look at it and then now it's
 much nicer. It's much nicer.

Liz: So this one is approved for external review. Eric, is this ready to go or
do you want to make any other changes?

Eric: I just changed the charter so I want to check whether it's correct
English because maybe put a comment more or whatever, and I will tell today or
tomorrow.

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

 o Protocols for IP Multicast (pim)

Liz: There are no blocking comments so any discussion here needed? Do we
approve on this recharter?

Gunter: So one little item like a couple of hours ago I made an update. I added
a few commas left, right, and center, actually only Oxford commas, funny, but
it should say like 08-O2, so I'm not sure if I've done something wrong maybe.

Liz: This is just the ballot that was sent out at version that's what that
referred to. If you made an update; that's fine. We'll just make sure that's
what gets sent out with the recharter announcement.

Gunter: Just like Orie, this is for me the first time I go through this. So if
it is approved, do I have to do anything else or will secretary do all the
magic?

Liz: If you wanted to make any last changes, we could wait for you to review it
and give us a go ahead or if you're ready to go, we will just go ahead and send
the announcements.

Gunter: It is ready to go.

Liz: Ok. We will send the working group recharter announcement.

5. IAB news we can use

Tommy: I don't think there's too much new. We're still confirming the NomCom
slate for the future new IESG. Sorry that's taking a while.

John: Thanks for jumping in there while I was looking for my mute button. My
only other thing was there was quite a bit of discussion with the last one
about the whether to do some kind of additional statement about ACH blocking
and as far as I could tell the outcome was no we already covered that in RFC
whatever whatever number is. No action then replying.

Tommy: Although if anyone, you know, on the IESG thinks that something needs to
be said about various countries blocking ACH, happy to discuss that. We're also
going to be talking with ISOC a bit about that if they perceive any kind of
measurements they have around that. It's mainly about watching this space
scenario.

Murray: I don't quite know how to ask this carefully, so I'm just gonna ask it.
Is there any chance that this is gonna take a whole lot longer? And the reason
I'm asking is because I just did

Tommy: For the NomCom?

Murray: Yes, I'm not trying to accelerate the process, I don't want you to do
anything wrong. I'm just thinking ahead. Like we only have four telechats left
during which we will have overlap with our replacement. So after today I mean,
so that's like if we lose another one then like that training opportunity is
chopped by 25 % et cetera et cetera, so I don't have to say much more than that.

Tommy: Correct, so, I mean the the situation that we're in is most of the most
of the slate we have confirmed, but there's some of it we haven't yet, but I
think normally  none of that becomes official or goes out usually until the
entire slate is approved, it is possible that some of it may need to go back.
So it is possible it will take a lot longer for at least one or two of the
positions. I guess we could talk about and get feedback from the NomCom if the
positions that we have confirmed kind of can be announced at least. If they're
comfortable with that.

Murray: I'm not trying to force you to change process or anything, I'm just
getting very sensitive about, and how how little training time it's dwindling.

Eric: I am also concerned. And by the way Tommy, I don't think it would be wise
to announce part of the slate, even if I would love somehow
 as I am interested because it basically split the future IESG in two parts.

Tommy: I think that's not preferred to do that. I think technically this is in
the NomComs hand for what they want to go for.

Roman: Yeah, that's exactly what I was gonna say. That's not up to us as the
confirming bodies, that's up to the NomCom.

John: Sorry one more thing on that tangent is do we at all want to liaise back
to NomCom that although we appreciate them following the normal procedure at
some point they should think about some partial results just in interest of
being able to onboard people? I mean it's still up to them, but they might want
to know our opinion.

Orie: I'm happy to share our opinion with them speaking as the IESG liaison to
the norm comm statement, so if you want me to take an action, let me know.

Eric: But I'm not sure whether we have an opinion as the IESG on this one.

Roman: My recommendation is to leave it, leave it kind of for now and see where
we end up by the time we head into the next telechat. I mean Dean is aware of
these challenges.

Murray: Here's one suggestion that doesn't tip anybody's, it doesn't require a
partial reveal or anything like that, the IAB for the people they have
confirmed could quietly nudge those people that they should start attending
telechats because it's open anyway.

Tommy: I don't think we can do that because technically the nom com can change
its selections for any of them.

Murray: That's true. Never mind.

Warren: It also seems like it would not be unreasonable and I'm kind of
wondering why everybody who ran for IESG positions hasn't been showing up on
these.

Tommy: That's fair. Like you just tell people, hey, if you think you're gonna
be on.

Warren:  I would have assumed that people have started attending them before
putting their name in the hat.

Deb: I mean if I'm honest, that's the only overlap I got as attending as an
observer.

6. Management issues

6.1 Designated experts for RFC 9559 (Matroska Media Container Format
Specification) [IANA #1385324] (Murray Kucherawy)

Liz: So Murray has identified Dave Rice and Steve Lhomme as the designated
experts for this registry. Any objections to approving these two? I'm not
hearing any objection, so they are approved and we will get that official note
to IANA.

6.2 Executive Session: Appeal to the IESG re WGLC of draft-ietf- lsr-multi-tlv

The management issue was discussed in an executive session with
IESG and Secretariat present. Observers and liaisons dropped from
the call.

6.3 Executive Session: Appeal regarding threat on the TLS Mailing List

The management issue was discussed in an executive session with
IESG and Secretariat present. Deb Cooley and Paul Wouters recused
themselves from the discussion and left the call for this portion.

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