Narrative Minutes interim-2024-iesg-20: Thu 14:00
narrative-minutes-interim-2024-iesg-20-202410031400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-10-03 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 (Department of Homeland Security, Cybersecurity and
 Infrastructure Security Agency) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Jim Guichard (Futurewei Technologies) / Routing Area
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Tommy Pauly (Apple) / IAB Chair
Colin Perkins (University of Gllasgow)/ IRTF 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
Sandy Ginoza (AMS) / RFC Editor Liaison
David Schinazi (Google) / IAB Liaison

OBSERVERS
---------------------------------
Mike Jones
Laura Nugent
Greg Wood

1.2 Bash the agenda

Liz: We have a pretty full agenda today and we do have the agenda
deconfliction, so I expect we will be here full time today.  We had regrets
from Sandy and David and otherwise we are all here so we can get started. Does
anyone want to add anything new?

1.3 Approval of the minutes of past telechats

Liz: Does anyone have an objection to the minutes of the September 19
teleconference being approved? I'm hearing the objection, so those are approved
and we will get those posted.  Jenny sent around corrected narrative minutes
from September 19 earlier this week. Does anyone have an objection to the
narrative minutes of September 19 being approved? Not hearing objection there
either, so those are approved and we will get them posted.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

        Last updated: September 30, 2024

   * DESIGNATED EXPERTS NEEDED

     o Francesca Palombini to find designated experts for  RFC 9595 (YANG
       Schema Item iDentifier (YANG SID)) [IANA #1369452].

Liz: This one will mark provisionally approved because we have a management
item at the end to approve some names here.

     o Orie Steele to find designated experts for  RFC 9581 (CBOR)
       [IANA #1372387]

Liz: Same with Orie to find designated experts for RFC 9581. We also have names
for this today.

     o Deb Cooley to find designated experts for draft-ietf-gnap-core-
       protocol (GNAP Grant Request Parameters) [IANA #1373603].

Deb: In progress.

     o Paul Wouters to find designated experts for RFC 9594 (Key
       Provisioning for Group Communication Using Authentication and
       Authorization for Constrained Environments (ACE)) [IANA #1374729].

Liz:  We also have names for this one to approve today.

     o Zahed Sarker to find designated experts for RFC 9653  (Zero
       Checksum for the Stream Control Transmission Protocol) [IANA #1378063].

Liz: Zahed, make sure you have this on your list.

   * OPEN ACTION ITEMS

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

Paul: In progress.

Roman: Paul, I I wanted to ask you about that, given that we're s we're talking
about spinning up a new IANA process related working group. Do you think we
should put that task in the scope of the working group instead of us trying to
define something?

Paul: That actually makes sense because one of the reasons it got a little bit
delayed is because there's actually like existing registers do it on purpose in
different ways like so for some of the meeting list is closed and for some it
is open and then open to post and or open to subscription and listen only. So I
wasn't entirely convinced yet what actually the best approach would be. So
that's actually a much better proposal to let them deal with that.

Roman: Can you scrum with Murray to get the right bullet point just added to
that charter text? Because the charter just has a long list of things like we
should consider and this seems like the perfect thing to add in there.

Murray: I think Amanda already had me add that so that's already in there. I
did notice that, but I agree merging these efforts are better to have a working
group come up with this than us.

Roman: Action item is closed from what I hear.

Paul: Awesome. Done.

Liz: Then we will take this one off the list. Congratulations Paul.

     o Orie Steele, Francesca Palombini, Murray Kucherawy, Mahesh Jethanandani,
       Warren Kumari to write draft of IESG statement addressing issue of
       credit in documents & the importance of capturing and addressing all
       comments as a necessary part of the consensus process, mostly
       pointing at existing advice.

Warren: So we have much of that written down. I think it's just how do we get
it from here to there?

Roman: Do we wanna haggle on it, haggle about it or set a deadline for review
for the next informal next week?

Orie: Deadlines are good.

Roman: I mean just to get just to force folks to get other eyes on that.

Liz: We can add this to next week's informal agenda.

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

Murray: Finished. The text has stabilized, so I think we'll also add this to
the next informal for approval.

     o Murray Kucherawy to draft an IESG statement on use of Internet-Drafts
       to meet "specification required" in IANA registries.

Murray:
This one has become much more complicated. I don't know controversial or there
are more opinions about it. So I think we should get a block of time on it
informal maybe like late in the agenda so it doesn't drag everything else out
so call it still in progress. I'll put it on the next agenda.

Roman: Aren't we gonna put that in the scope of the working group, of the IANA
bis and get community consensus on this one?

Murray: There was a scrum of four ADs got on a call and it sort of hashed out
and we have a solution we kind of like. I guess we could do it through the
working group, Warren what do you think?

Warren: I think what we should do is, we should explain what we think in the
working group. So, basically propose to the working group, this is an option we
think it's a good one. I mean I'm still not entirely sure that we want/need a
working group, but we've got a charter, so I guess we'll have a working group.

Roman: I mean the reason I'm poking this, I think there's a bullet in the
charter right now that says, talk about what it, what is the bar for
specification required? Like in terms of documents and so it seems weird for us
to make a statement you know regardless of what it is and then for that to be
charter scope.

Warren: I mean that you're right, it's a little sad because we did come up with
a solution that would have just be nice and easy, but you're right, it would be
weird if we did that and then we're like, and now let's have a working group to
decide it.

Murray: On the point about whether we actually need a working group, the reason
I decided to go that way is just we've been getting static lately from some
noisy members in the community that's that are, of the opinion that we
shouldn't be doing these things with IESG statements or AD sponsored documents
like you saw the response to BCP 97 bis. So, ok, we'll do a working group.

Roman: I mean we have the feedback from all dispatch, so it seems like that's
where the community wants to.

Murray: So then just to round that out, there is a charter available. I'm gonna
stick it on I'm gonna Cindy's helped me with the timing, so it will probably be
on the next, then on one of the on the 17th, which gives us just enough time to
get it chartered before 121. It's not that like there's any urgency, but it's
sort of a convenience thing, that way they can, the working group can actually
get started at 121.

Liz: Should this item stay on the action item list here?

Murray: No, you can take it off, I'll fold it into the charter.

     o Roman Danyliw to reach out Systers about the value of writing
       recommendation letters to employers.

Roman: So on that one we can take it off the list. Systers is scheduling an
interim meeting. I don't have the date because I'm not sure it's actually been
scheduled yet, but my intent is to take this topic to the meeting.

Eric: It's still the goal to make this kind of recommendation letter as well
for any participants, right? Not only for Systers.

Roman: That was my thinking, and I think that's how we discussed it. I don't
know whether we've committed yet to even spinning this up. I think this is an
information gathering step to really just check if this is useful.

Deb: FYI, she's got a doodle poll up for that, so if you wanna put your
brothers in, you should do it.

Roman: I don't have If it was sent to the Syster's mailing list, that is not
available to me, so I cannot participate in the doodle poll. I don't have the
mail, I don't have the link and I don't have the cut of the rest of it.

Deb: That's fun.

Roman: That is the nature of the Syster's mailing list?

Deb: Is it? I mean wasn't Lars on it?

Roman: I can't say I'm not eligible because I am not an eligible participant so
I can't be on that list.

Francesca: I know that at some point Lars consider getting onto that list but
was advised also by me not to do that and I think we should keep that going.

Roman: We don't need to stress about this, i'll sort it out. Thank you for
letting me know, I did not know that we were ideating on dates.

Deb: I didn't either until I looked.

Francesca: I can I can suggest that that email is forwarded to do Roman, to you
from Carolina so you can get the poll as well.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-rats-uccs-10  - IETF stream
   A CBOR Tag for Unprotected CWT Claims Sets (Proposed Standard)
   Token: Roman Danyliw

Liz: We have some discusses here, do we want to discuss this now?

Roman: So I want to say thank you for everyone's deep review here. I believe
that all of this is great feedback and I want to let the authors respond to
that. I mean what's been proposed here is it discussed I don't think requires
discussion here. I think we need a response back from the working group on
this. Thank you for the feedback. Revised ID needed.

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

 o draft-ietf-oauth-resource-metadata-11  - IETF stream
   OAuth 2.0 Protected Resource Metadata (Proposed Standard)
   Token: Deb Cooley

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

Deb: So it turns out that Mike Jones is on the call if you want to talk about.

Murray: Mike already replied an email that this is, I just skimmed it really
quickly, but the general idea is that this is justified and it's kind of a
carry forward of the way this was done in other registries with OAUTH Which is
fine. I guess I was just missing the explanation about why it was done that way
and it's unfortunate that the earlier documents that did this didn't quite
explain why the loophole was usable, but or was necessary. But I mean the other
part of this is that it's topical because of the working group we're talking
about starting up. Maybe this is something we need to capture in a new registry
type. I'll come off of discuss now that I have that context and then we'll just
figure out how to apply it going forward.

Deb: He messaged me and said he's happy to join a new working group, so I think
we're good.

Francesca: I'd like to bring up my comment. I didn't put in a discuss, but it's
also about IANA, and Mike replied to my email. I think I haven't had time to
reply back. So there is this sentence that says that if, registration requested
are undetermined for a period longer than 21 days, it can be brought to the
IESG's attention for resolution. Initially to me this was I don't really
understand what the IESG is supposed to do. Is it supposed to be under IESG
approval policy or is it maybe like escalation or something else? And Mike
clarified in his response that this is supposed to be IESG approval policy,
sort of like this has expert reviewer policy with IESG approval policy after 21
days of un-responded requests. I in general am not sure that this is a good
idea because the IESG would end up having to decide on registration requests.
Just going like the usual route, which is like escalation and then to
understand what is the reason for this delay. So  I was wondering if I'm the
only one that has this concern or if others think that IESG approval is a valid
additional policy to add here? It's not a blocking comment so I will accept it.
But I just wanted to bring it up. Opinions?

Deb: So in other cases we have issues with designated experts not being
responsive, right? I can think of one.

Francesca: Do you think that's a valid resolution for these requests to come to
the IESG for the IESG to decide?

Warren: I don't, I just think there needs to be a path forward. I kind of think
that it is a valid thing because if the DE drops the ball, it comes to the IESG
and we go back to the DE and we're like, what are you doing? you're not  being
particularly helpful here and we know to put in a new DE. So I don't think this
is in a bunch of these coming to us, it will involve one or two per registry
max.

Francesca: What we are you what you're describing is the, the regular IANA
escalation procedure that should be working that way, which is, the DE doesn't
answer, IANA gets to the responsible AD, the responsibility is supposed to do
something about getting the DE to answer and if they don't, then it gets to the
IESG but it's not the IESG that is supposed to decide if to approve this
request or not, which is the IESG approval policy.

Warren: I think that the IANA try is really hard to not ever escalate things to
us and I guess we could ask them nicely to be more escalate.

(crosstalk)

Warren: I once had a nice question from like, would you mind seeing that this
person's around but that's all. Okay, anyway, guess it's just different.

Eric: Have you seen Mike's comment on the chat? Should we allow Mike to speak
and it.

Mike: Thank you for letting me speak. The point is to have a fallback if the
designated experts don't respond in the 21 day period. So eventually this thing
gets processed. I'm open to any alternate escalation language. This is the
language that's been used in like ten OAUTH specs, so I just copied it, as was
the language that Murray had to discuss about previously, if anyone on the IESG
wants to suggest different language other than can be brought to the attention
of the IESG, I'd be glad to put it in.

Murray: My worry is that the IESG isn't the appeal path.

Mike: That's the point.

Murray: Well yes, but I mean that means after 21 days, there's automatically an
appeal to the IESG basically.

Mike: If the requester asks for it, yeah.

(crosstalk)

Murray: That doesn't make it right.

Mike: Ok. Tell me what would be right?

Murray: I don't have a better solution at the moment. I'm sort of noodling on
it, but the way I'm looking at this is, we, there's basically an automatic
appeal to the IESG after 21 days of DE inactivity. Well, why not replace the DE
with someone who is responsive?

Francesca: Well, Murray, that was not clear to me from the text, if, at least
if you could scroll down to my comment, the text that I quoted just say, can be
brought to the IESG's attention for resolution that could be interpreted as
IESG approval, so it's not an approval, it's not right. It's just IESG
approval, which I don't think is the right thing to do. I think we should let
IANA do their usual escalation, which is through the responsibility and then to
the IESG. That text needs to be clarified on what needs to be done. And I'm not
against Mike, I'm not against having a text that says like after 21 days. Sort
of giving a timeline to experts, that's fine to me, but I'm just trying to
clarify what, what the IESG is supposed to do. And Sabrina wanted to talk
before she, she unmuted.

Sabrina: I think just to confirm what you, what you said Francesca. So as far
as our process, we do give the expert two weeks initially to respond to the
request. And so if we don't hear from them after two weeks then we ping them
one more time. And then after four weeks of not hearing from them, that's when
we escalate to the area director. That's our current process right now.

Orie: Can I ask, have there been cases where IESG approved something in a
registry, because the DE did not respond in some period of time so that the
IESG took a registry approval role from the DE? Is that a common occurrence?

Sabrina: I wouldn't say common, in fact it's something that I think I'll have
to kind of look up and see when was the last time that was done. So no, not
common.

Warren: I believe it happened a few times while I've been watching, but very,
very seldom, but a somewhat related question, I think at one point IANA had
nicely sent us a, list or something of I'm not gonna say initially problematic,
designated experts, but problematic registries maybe where they needed some
more help. And I think we fixed some of those. I don't know how hard that is to
do, but if you know of any, especially in OPS, I'm happy to help find
additional help.

Sabrina: Yeah, I believe that was part of the designated expert outreach
project that we did, where we contacted all of the experts and so for the ones
that we didn't get a response after I think three tries, those are the ones
that I think we sent to you. But yeah, you're right Francesca, the 21 days
would be a little bit out of the, ordinary, so that's because we still ping the
experts after I think two weeks. We give them one more chance and then it's
usually after a month that we escalate to the AD.

Francesca: So, yeah, following from the, Webex chat, I will be fine with Paul's
suggested text that the IANA process for escalation is followed when or if that
is not responsive for 21 days or you can rephrase that.

Paul: But is that something we need to put in every individual draft that's
authorized?

Francesca: But 21 days is different, right? Like usually IANA has this timeline
that is 14 days and then 28 days so if, Mike authors, working groups want to
put a timeline into their document that is also different from what IANA
usually does, I'm fine with that.

Mike: I'm fine with the standard timeline. I just want an escalation path.

Paul: But to me the escalation path is there, right? For each, for each DE that
is not responsive in every draft where this is happening. So I'm not sure why
these drafts need to explicitly say it and then cause all this sort of
potential customization or outdated policies because your policy won't get
updated either then, right? Right, if the IANA decides to change their process.

Francesca: Escalation processes are implied when IANA is. I'm not against
putting that text in there, even though like it doesn't mean that every draft
that doesn't have it doesn't follow it. It just means that this is more
descriptive.

Zahed: My thinking here is like whether the question is basically do we need
this 21 days as a hard limit for some reason that we justify then that and say
that, hey, and after 21 days if this is not resolved and it's supposed to
escalate it to for resolution, I wrote some text in the chat, but my question
is like the 21 days is my is it something like something coming from the
historical reason or like something that the OAUTH community really thinks like
21 days is the hard limit for getting the resolution?

Mike: Having a day limit is useful. When negotiating responses with designated
experts that may feel like they have better things to do. And I have one of
those situations right now, so after 21 days I'll talk to Deb if the expert
doesn't respond.

Zahed: I'm fine with putting in to 21 days, but just just tell like, ok, after
21 days IANA is requested to follow the some escalation procedure to get the
resolution done and Iana will do that then for this kind of thing. IANA perhaps
will not follow the regular four weeks procedure rather than three weeks.

Roman: But if I'm not mistaken Paul just proposed not putting any dates in and
just repeating what is already good to always be true, which is the process for
escalation is followed with these you're not responsive. You don't pin dates,
and Mike, you said you were good with that, right?

Mike: I'm fine with that too.

Francesca: Roman, Mike was saying that he prefers to have days. Because there's
a place that he can refer to and and and get experts to do their job in in that
timeline, which again is fine on me. Anyway, we don't probably don't need to
continue this conversation. I think I expressed
 What's my concern was with that sentence. I hope we can clarify that it's not
 the IESG approval
policy that, you know, moving forward.

Mike: I'll make that correction.

Francesca: Okay, thank you. Otherwise I trust you and Deb to go with whatever
you think is best, either remove that text or clarify it.

Liz: Since there's a discuss this will stay in IESG evaluation and it sounds
like we have a revised ID needed on this one.

 o draft-ietf-6man-pio-pflag-10  - IETF stream
   Signaling DHCPv6 Prefix per Client Availability to Hosts (Proposed
   Standard)
   Token: Erik Kline

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

Erik: Thanks everybody for having a look. Revised ID needed.

Liz: So this one is approved announcement to be set. Revised ID needed.

 o draft-ietf-grow-bmp-peer-up-05  - IETF stream
   BMP Peer Up Message Namespace (Proposed Standard)
   Token: Warren Kumari

Liz: There are no discusses in the Tracker so unless there's an objection now,
this is also approved. This one is approved. Warren, does it need a revised ID
or any follow-up?

Warren: Ready to go. I believe it does. I think it's ready.

Liz: Approved announcement to be sent, and we will send the appropriate
announcements.

 o draft-ietf-gnap-resource-servers-09  - IETF stream
   Grant Negotiation and Authorization Protocol Resource Server
   Connections (Proposed Standard)
   Token: Deb Cooley

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

Roman: So I want to pause here. I noticed just quickly in the Datatracker that
the it says IANA not OK so I am happy to hold a discuss for IANA on the issue
that needs to be resolved.

Deb: So the reason and I'm gonna hold it, so it the reason is because there are
no designated experts for the core protocol yet, and the proposed designated
experts that I was gonna put on which is one of the reasons I haven't let that
action open is because it's the authors. That doesn't like work, right? So I
need another designated expert that's not an author for both, for the core
protocol to actually then do the designated expert for this. So, it's a little
bit weird situation. We're working, so if you put it in AD follow up with
revised ID needed, as long as IANA is happy with that. If there's another way
to do it that works too.

Warren: I might be wrong, but I think we've often had authors of a document be
the DE for the registry they create. So, if that's your only concern, that
might be OK.

Deb: But those two documents, they're both the same authors. I was gonna use
those authors as DEs gonna DE them for themselves? Like, do they not have to
reduce themselves?

Sabrina: So you as the AD, Deb, you do have the option to override the expert
review requirement here. I think Amanda just sent a note last night, so you may
not have seen it yet, but, the, the authors can be the experts for, for the
registry, it's just for this particular review, we may have to ask you to sign
off on it.

Deb: I did see that note from her this morning, the joy of being on the East
Coast. I have already kicked off a couple of messages to the old, the working
group chairs and the authors. It's nice to know there is an option to override
it and just let the authors do the DE for himself. It seems a little weird to
me, but OK. AD follow up, revised ID needed because I think there's other
things that have been changed anyway.

Liz: We can only pick one of those, so why don't we just go this will be
approved in announcement to be sent and we'll just put it in AD follow up Deb
and then you can do what you need to do with it.

 o draft-ietf-sidrops-rrdp-same-origin-04  - IETF stream
   Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP)
   (Proposed Standard)
   Token: Warren Kumari

Liz: There are no discusses so unless there's an objection now, this is also
approved. Ok, this one is approved announcement to be sent. Warren, what do you
want to do?

Warren: It's all ready to go and go. The authors have been making updates as
it's been going along and I think it's all cut, so approved announcement to be
said, no revised ID needed.

Liz: So that's ready to go and we will send.

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-pim-mofrr-tilfa-06  - IETF stream
   Multicast-only Fast Reroute Based on Topology Independent Loop-free
   Alternate Fast Reroute (Informational)
   Token: Gunter Van de Velde

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

Roman: Yes, please.

Gunter: One of the discuss has to do with the template which is a little bit
old and I do agree on that one, but that is quite easily fixable. I think on
the discuss from Roman I think we have converged to an understanding of that.
The shorterage could be improved as such.  I think the main question which is
residing right now is either the document pass with the marker that the charter
will be updated or we keep the document in quarantine until the the charter is
updated, basically.

Roman: I think that's the position. If you are willing to commit to revising
the charter so we don't have this ambiguity, I mean this seems like a low
stakes document, we're a little bit in the gray zone. I'm willing to clear, if
you're willing to update the charter at some point after.

Gunter: Yes, and actually I will have to update the charter anyway because
there are like two other documents which have been passed over from the SPRING
working group to do with segment routing and point to multi point segments
which are actually beyond the shortage of. So we have to update it anyway, so
it was work in progress for IETF 121 to come, but this will expedite the you
know the energy there for sure.

Eric: And by the way Gunter, on my thing, it's only about the template is we
are changing the copyright notice, all the authors need to agree with the
change of copyright, right? To be fair.

Gunter: OK. I didn't really understand the impact of that, so thank you for
clarifying that.

Jim: I took a look at this this morning. It looks like a pretty easy change to
the charter, frankly to take these in and so if you need any help with that
because I was the AD for this, this working group as you know, so just just
ping me.

Gunter:  I think the point to multipoints point stuff, I think that agreement
was before you were AD.

Jim: It was, yeah.

Gunter: You're not to blame here. We'll figure it out, both of us together.

Liz: This document will stay in IESG Evaluation for now, should we put it in AD
follow-up?

Gunter: AD follow-up is for the moment, yes.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

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

 o Standard Communication with Network Elements (scone)

Liz: There are no blocking comments, so unless there's an objection now, I
think this is ready for external review.

Zahed: Thanks for the comments. I think I have got some comments that actually
I think we need to discuss. I'm a bit more wondering how to actually address
John's comment because he was saying like, 'hey, please rewrite this kind of
non goal thing.' When we discuss these things we try to pick the sentence as
simple as possible. So if you guys have any kind of suggestion how to project
what we want to say in a better way, then that would be great. Otherwise, I
mean, we can take it on when we get the external review.

John: I can noodle on that for a minute after the meeting and maybe come up
with something. I obviously didn't make it a blocking comment because I don't
think it does need to block sending it for external.

Zahed: I get your points John, I also think like that's like bare minimum kind
of sentences there but I don't have a better solution right now. So if there
will be any kind of solution I think that would be great. Otherwise I think
we're fine with waiting.

Roman: Since we're on the call, I just wanted to explain my comment about the
security and privacy things. So I was I guess a little bit confused about what
that sentence meant and in what way it was gonna scope the work because the way
I read it is we're gonna do our protocol work and then we're gonna analyze the
security and privacy properties. But that's restating what's already required,
which is everything already needs a security consideration. So it wasn't
committing to anything other than we're gonna follow the process of what we
had. What I was expecting is what typically happens kind of in charters is that
you describe in some high level way the security properties you are committed
to to design into the protocol because otherwise if it's not that, that
sentence doesn't add anything because you already required to do that analysis.
Analysis just means you're documenting the thing that you already built, not
that you're guaranteeing anything or building anything in. It's not even the
sentence could say there's no security whatsoever and that's the analysis,
which I don't think is the intent.

Zahed: I get your point. I think this was a bit like the two boxes that we had.
We have been discussing this security and analysis for a long time and this was
pretty obvious like people want to work with it, but people want to be really,
really strict about like this privacy,  and security aspects of different kind
of choices and they wanted to put it into the the charter so that this is like
even if like a natural thing like to do when you have a standard, you do those
kind of things, but this is the where they want to focus and they wanted to
make it more visible, that's why it is there and and then I also kind of like
try to get like, ok, what kind of security properties and all this thing, but
then that discussion went into this. Now we are looking into some security
properties and all these things just leading to a particular design and stuff
like that. We don't want that either. So this is basically where and why it
looks like this. And I'm fine with like removing things like, ok, this is a
natural thing, but I think some of the proponents and some of the like
interested who were work interested in this work they wanted to make it visible
in the charter, like this is going nowhere is a super deep security and privacy.

Roman: I understand it. I just find it very confusing because it's not actually
committing to any properties or kind of anything. It's just making a statement
to include, we're gonna document we have no security, which I know is not the
intent. The only other way I could envision that might be useful is that if the
workgroup is intending to create a different artifact, you know, so e.g., maybe
they're committing to a formal analysis or they're committing before they ship
or maybe they're committing to, you know, we're gonna write a separate
document, you know, because that's how we want to structure, and then those
words would be more meaningful.

Zahed: If we say something like: 'ok you're committing to a formal analysis of
of the security,' then that basically would be something going to deliverable
also like I mean from following the chapter. Again pretty bare minimum to say
like we're just repeating the process that we want to do. I think the idea as I
said, like the idea was to put the emphasis so that the charter explicitly says
like we are gonna do that.

Roman: I'll let you work with your audience, in a sense I'm worried that if
that's the precedent because when future charters don't include that, you know
what I mean? What does that mean? I mean that's always a kind of a requirement
so that when we highlight the thing that's already a requirement sometimes but
not without being specific, it's kind of confusing to me.

Zahed: I don't know this would be like super bad precedent, but I mean, what I
care more about is are we clear or not what we are writing? So I think we'll
try to get some wording there. I'll dig into the previous discussion and see if
we can actually put some properties there that the working group comments on.
So that was a good comment. I mean I'm getting very good comments to clarify
the charter a bit more, but, there is a chance like we actually repeat the
discussions again and again and again and go nowhere. But let me work on that
with the properties. I'll update the charter.

Liz: Okay, Zahead, do you want to make those updates before we send this out
for external review?

Zahed: I'll anyway make some changes and ping you.

John: I also pinged you about some proposed text.

Zahed: Thanks, i'll have a look.

Cindy: I also have a question about the mailing list. The SCONE BoF used the
SADCDN list, is going to continue to use that list or are we going to create a
new one for it?

Zahed: I think Cindy I was having some chat discussion with you like I was also
a little bit confused, for SADCDN, I don't think we want to use the SCONE if 
we approve this working group, this should not say SADCDN. It should say
scone@ietf.org. My plan is now to have the chartering discussions whatever we
need in the SADCDN as it is, and then when you approve this working group will
create the SCONE and try to change membership to the new one and keep the
archive of the SADCDN mailing list. If that's work.

Cindy: We can totally do that. I will probably want to get started on creating
the mailing list sooner just because that is no longer a thing that the
secretariat can do in a couple of minutes. There's a round trip with the the
SRIUS contractor, so it sometimes takes a couple of days, but if you just want
scone@ietf.org, we can get that set up and have it ready to go once this is
approved.

Zahed: Let's do that. Right now I say the notice goes to SADCDN, so when you're
done with that we can send it to SCONE.

4.1.2 Proposed for approval

 o Getting Ready for Energy-Efficient Networking (green)

Liz: I think Mahesh is still not on the call yet though, but so we'll check
with him when he's back, if this is ready to go or if he wants some more time
to make any final checks. Does anyone have any other comments or anything for
Mahesh on this?

Roman: I think he's gonna want to make one more edit because he said he would
merge a small change for me, but we should leave it to him.

Cindy: And just to note that I will have a similar follow up conversation with
him about the mailing list because currently this is using greenbof@ietf.org
and once it's approved it will no longer be a BoF. So I'm assuming that's going
to change.

Liz: So it sounds like we are waiting on a few small things, but there are no
overall objections. So this is approved pending those final bits and bobs.

 o MODeration PrOceDures (modpod)

Liz: There are definitely no objections. We didn't quite get our record number
of yeses, but is this ready to go as is and be announced or do we need more
time with that?

Roman: So the text itself has one editorial merge I want to make it it's
missing a comment in one particular place, so I'll make that. But the thing I
have not done yet is announced the chairs, so we can't send it out for as
approved until we name the chairs based on a kind of process. So I need a
couple more days to sort this out.

Liz: So we will just leave it where it is for now then Roman, and you can let
us know when it's ready to announce. And are we good with the mailing list?

Roman: For the mailing list, we're going to stick with modpod discuss.

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

John: I missed the meeting so there's no IAB news from me.

Tommy: Nothing too big, the AI control workshop did happen. That was an in
person workshop. I was not there, but all the reports were that it was a very
successful productive meeting, and there is expected to be some work that
they're gonna try to take into the IETF from that. I think the plan right now
is to have a side meeting at Dublin and then try to go for some chartered group
after that. This is something that has some time sensitivity due to the
regulation landscape, particularly in Europe. I believe some of the proponents
are already talking to, some of the ADs on this call. So that's the main thing
going on.

Eric: The side meeting would be completely open, right?

Tommy: I believe so.

Roman: It has to be, right, Eric?

Eric: It has to be, I just wanted to double check.

Tommy: I mean this would be like a side meeting on the side meeting list. This
is not just like group of people in the corner.

6. Management issues

6.2 [IANA #1376075] IESG approval for application/toml (IANA)

Liz:  So this is to approve that as a grandfathered standards tree media type.
Does anyone have any comments on this one?

Murray: I'm not familiar with the history here. Anybody know why this is going
through the grandfather path instead of the regular path?

Erik: I don't know what the grandfather path is. This is what Russ uses for its
cargo files.

Murray: I'm reading appendix A of the BCP, I forget the number. It talks about
faceted names. I'm unclear why this has to be done this way rather than just if
the media type reviewer is reviewing it. If Amanda's not here Sabrina, do you
know?

Sabrina: I'm not sure, but, I know that I think Alexey has asked for this
before. I believe, just back in May I think there was also another
grandfathered request. I think that was for application/stratum, if I'm not
mistaken. So I think the requester is the same. That's unfortunately all I know
about this.

Murray: I mean I trust Alexey I'm just looking at this going as nothing special
about what in the in the template, there's nothing special explaining why we
would use this little known path through BCP 13 to get there I mean, so I'm
fine approving it.

Roman: We have no time pressure here as far as I know. I mean, we could send a
note to Alexey to say, hey, can you clarify for us why we're going down this
path?

Murray: I mean or we could go look at the media types list. The discussion
might be there. I didn't I didn't do any homework on this.

Roman: Can you send a note to Alexey just to explain it to us and we can bring
this back on October 17?

Murray: Can we reschedule it and I'll take up the investigation here.

6.3 [IANA #1375267] IESG approval for protocol number (homa) (IANA)

Eric: This is where I just discovered this my morning, right? I think we need
to think a little bit more on this. I mean there is no scarcity really. We have
more than 100 code points left, and my understanding of this, it's even if it's
only used in data center, I mean, I would really love to get a three page draft
in INT Area TSVG explaining it what it is before approving. And I'm not sure
how an IESG approval is done for this rather than specifications so as far as I
know in my five years of IESG standing, this is the first time we got an IESG
approval for code points. That's up to you if I'm something wrong there.

Sabrina: That's a good question. I may have to look at, look up when was the
last time we did IESG approval for this, this registry. I think the only
additional information that I wanted to add to this is, the requester noted
that they wanted to wait a while before writing a document so that the protocol
can evolve, just based on early use. So, and that was the only additional note
that they provided to us.

Eric: Because typically when we do an early allocation for any code point from
the top of my head, it needs to be that the protocol is not evolving too much,
right? To avoid interpretation issues, Isn't it into 8126 early approval?  I
think I can't think this is an action item because it's related to the IP layer
somehow or except if, any transport AD wants to take it or Erik if you want to
take it, but I suggest that we don't approve it now. And I can contact or Erik
can contact or any Transport AD can contact John to see what is behind.

Liz: We can leave this item here until the next telechat and Eric you can
gather some more information in the meantime.

Eric: Expect if anyone wants to take the hot potato.

Roman: No Eric, yeah, I think you have the potato. Thank you for taking the hot
potato. Yeah, I think we also may want to consider for future IESG, whether we
want to provide a little bit of guidance to those future ADs on how they would
evaluate these requests and what information they might want to have to make
that decision because we have tremendous flexibility from with IESG approval
but we I think might want to have some consistency. One of the consistency
properties to me might be if we're not sure we could in fact ask the community
in some way.

Zahed: So just just for my understanding because you kind of speak for
Transport ADs. I mean this they are not asking for a port number. They're
asking for a protocol.

Eric: Sure, but for doing some kind of transport thing to replace TCP on the
top of it, that's the reason again I don't know the topic, right? When I'm
reading what is below what's on the list screen, right? It's to make something
faster than TCP. And then my immediate question is why not using UDP and it's
not for the eight bytes or whatever of UDP, that could change a lot.

Erik: Yeah, I think I think he's just trying to get past a bunch of TCP stuff
TCP or TCP inspecting devices in the data center. Did this ever come up at
TSVWG?

Zahed: I don't remember this one.

Erik: I did see something about this a while ago and I found a presentation at
NETDEV, from, I think June of this year or July. Somebody at Google, I reached
out to pointing me to it. So, I don't have a problem, you know, but I
understand the hesitation.

Eric: Even if it's for data center, if they want to push more packets through
the transport layer, I wonder whether there's a link or should we make a link
with HP one? One is for layers, right? And this one is for a data center.

Zahed: I mean this is kind of related to the OGSP one kind of discussion that
we were having. What i'm struggling is this something, if we can. Can you say
like: 'hey, this is like you're changing like bypassing TCP or and then you're
trying to create a new transport protocol with the new protocol number and you
are not allowed to do that.' Can we say that? I don't think we can say that. If
they ask for like a protocol number or port number assignment then i'll have
our port gives feedback. I think one thing definitely we could do if they want
to bring this one to IETF as a work item and then connect them to TSVWG and all
these things. So these are two different things to me. One is like Their IANA
registration request whether they would like to do and what what would be our
like as Roman was saying, what exactly should we be looking at? I mean, because
this is a valid request. I don't see any problem with the request.

Eric: Except that it's either by request, but the normal way of doing it would
be some specification, right?

Roman: That would be the preferred way, but there is the IESG approval route. I
think there's a little history that we can help with.

(crosstalk)

Eric: The process is being followed, so there's no point about it.

Zahed: Do they have any standard somewhere?

Eric: I will ask. I will contact John and come back in two weeks.

Zahed: So what I can help with like if you put me on the CC I can see like the
1st and response from them to see like whether there's already any
specification. If not, we can tell them, ok, I think we need to discuss and
decide like whether we can approve it or they really need to work on the
standard detection. So that would be our decision point from the IESG point of
view, but we can actually get more socialized with them like what exactly,
where exactly this is defined and how they're using it.

Eric: I was planning to put you and Erik on the cc. Again, I don't see how we
can refuse it because they're quoting code points somewhere.

Erik: We can refuse it because the number space is small, but we can also
reallocate them to ancient unused number.

Eric: The number number space is not that small, but not huge.

6.4 [IANA #1372387] Designated experts for RFC 9581  (Orie Steele)

Liz: Orie has identified Henk Birkholz and Esko Dijk as designated experts for
this RFC. Any objection to approving them? I'm not hearing any objection, so
those two are approved and we will send that official note to IANA.

6.5 [IANA #1374729] Designated experts for RFC 9594 (Key Provisioning for Group
Communication Using Authentication and Authorization for Constrained
Environments (ACE)) (Paul Wouters)

Liz: Paul has identified Francesca Palombini, Marco Tiloca, and Rikard Höglund
as designated experts, does anyone have an objection to approving those three?

Francesca: I obviously recuse.

Liz: They are approved and we will get that official note sent to IANA.

6.6 [IANA #1378063] Designated experts for RFC 9653 (IANA)

Liz: This is the new one for Zahed, so hopefully we'll have names for that one.

6.7 [IANA #1373645] renewing early allocations for
draft-ietf-idr-sr-policy-safi (IANA)

Liz: John, this is one of your groups. Do you have any comments on the renewal?

John: My comment is let's do it. It's currently in AD review. Actually Roman's
AD review. Thank you Roman.

Roman: I think we're on a good path to make some changes, but I see nothing
that wouldn't have this going to last call within the month.

Liz: Any objections? Not hearing any, so let's call that approved and we will
get that official note sent to IANA.

6.8 [IANA #1369452] Designated experts for RFC 9595 (YANG Schema Item
iDentifier (YANG SID)) (Francesca Palombini)

Liz: Francesca has identified Michel Veillette, Alexander Pelov, and Laurent
Toutain. Any objection to naming these three as designated experts? Not hearing
objections, so they are approved and we will get that note sent to IANA as well.

6.9 Approve telechat dates between 121 and 122 (Secretariat)

Liz: This one, there's pretty much just the one option that works based on how
the holidays are shaking out this year. So we'll get one formal in between IETF
121 and the US Thanksgiving holiday, and then the 1st one back in January will
be 9 January, which hopefully people will be back from vacation by then. And I
don't think there are any major other holidays that this impacts, so does
anyone have any comments or questions? I'll take that as your approvals and we
will go ahead and get all of those booked in the calendar.

6.10 [IANA #1373649] renewing early allocations for
draft-ietf-sidrops-aspa-profile (IANA)

Liz: Warren, this is one of yours. Do you have anything you want to say about
this? Are you still with us? Does anyone have any comments about this one? Any
objections to approving this renewal?

John: People are working on it, I think we should renew it.

Liz: Then we will call that approved and we will send the official note to IANA.

6.11 Additional Designated Expert for JOSE Registries (Paul Wouters)

Liz: Since there is only Sean Turner, Paul would like to add Mike Jones as the
expert for these six registries and the objection to approving Mike?

Paul: And I'm actually looking for another one because all the incoming
documents actually have Mike on as an author so I pinged Hannes as well, but I
haven't heard back from him yet.

Liz: 'm not hearing any objection to approving Mike, so we will call him
approved and if you have another one you want to add Paul, you can go ahead and
do that at any time. So we'll go ahead and get this official note sent to IANA
as well.

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

Liz: So that's the end of our regular business before we move on to the agenda
conflict resolution. Does anyone have any other business?

Mahesh: Sorry I just joined back so I wanted to make sure of anything I missed.
Was anything on my plate?

Liz: Yes, green is ready for approval, but we will just wait for your go ahead.
Roman said you still needed to make at least one small change, just a charter.

Mahesh: Yes

Liz: Great, so then it's approved and then as soon as you let us know it's
ready to go, we will send out the announcements.

Cindy: currently the Datatracker lists the mailing list for this as green-bof.
Do you want us to create a new mailing list that is just green?

Mahesh: That is correct.

Cindy: Ok. So we'll do that.

Roman: I just have a quick reminder of any other business. So I've been
accepting this is on the topic of the FAQ for the IETF 125 decision. I have
been responding to much of your feedback. I've been accepting changes,
rejecting change and comment on it. At this point, I have merged everything
that I think we have agreed to in the chat. I have to a degree possible left
the track changes on so you can see the changes I have made. I am going to ship
what is in there late Tuesday afternoon. So I'm giving everyone a couple of
days to take a kind of a breath from the telechat. We can do other business,
but whatever I have in there, I'm gonna ship Tuesday kind of afternoon to the
community with a note saying, hey, listen, we got a bunch of kind of questions.
We want to make sure that everyone benefits from the various answers we have
given them. Here is a slight revision to the explanation document. Please
consult the FAQ. So just hop into that document and make changes if you feel
you're comfortable with what's in there.

Francesca: Roman, thank you for the changes. I just want to bring up like I
unfortunately am not able to like suggest text but and Tommy can speak for
himself since he was the one who brought up that comment about how do you say
the tone we use, I guess? It's the the closest thing to say?  don't think that,
changes to like into the appendix will be as visible as the email itself rather
than an appendix in a PDF linked to an email announcement.

Tommy: I think the additions are good, I guess you could highlight button them
directly.

Francesca: If you're happy with that, then that's good.

Warren: Quick question, I had to step away to answer the door. I just want to
make sure that the renewing early allocation for
draft-ietf-sidrops-aspa-profile was approved?

Liz: Yes, it was.

6.1 IETF 121 Agenda Conflict Resolution (Liz & IESG)

The management item was discussed.