Narrative Minutes interim-2025-iesg-03: Thu 15:00
narrative-minutes-interim-2025-iesg-03-202502061500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2025-02-06 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Mike Bishop (Akamai)/ Incoming Web and Internet Transport Area
Mohamed Boucadair (Orange) / Incoming Operations and Management Area
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley (DHS CISA) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Gorry Fairhurst (Univ. of Aberdeen) / Incoming Web and Internet Transport 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
Jean Mahoney (AMS) / RFC Editor Liaison
Cindy Morgan (AMS) / IETF Secretariat
Andy Newton (ICANN) / Incoming Applications and Real-Time Area
Francesca Palombini (Ericsson) / Web and Internet Transport Area
Tommy Pauly (Apple) / IAB Chair
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
John Scudder (Juniper) / Routing Area
Orie Steele (mesur.io) / Applications and Real-Time Area
Ketan Talaulikar (Cisco) / Incoming Routing 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
Warren Kumari (Google) / Operations and Management Area
David Schinazi (Google) / IAB Liaison

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

Antony Antony
Marc Blanchet
Francois Clad
Nick Doty
Sandy Ginoza
Tommy Jensen
Felix Linker
Ronald in't Velt
Mauro Vignati
Greg Wood

1.2 Bash the agenda

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

1.3 Approval of the minutes of past telechats

Liz:  Does anyone have an objection to the minutes of the January 23
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 the January 23  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: February 4, 2025

   * DESIGNATED EXPERTS NEEDED

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

Paul: I'll try to send them a DM at the end of the meeting.

     o Erik Kline to find designated experts for RFC-ietf-ntp-update-registries
       (Updating the NTP Registries)[IANA #1412130].

Erik: In progress. I'm collecting a list of victims.

   * OPEN ACTION ITEMS

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

Murray: I will finish before I step down, but it's still in progress.

     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 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.

Roman: So for the next couple are mine, those are in progress. I'm gonna take
ownership of the last bullet based on, I think two informals ago. I need to
talk to Jean about what is the experiment the RPC wants, and if we can't
quantify the experiment, then we're gonna kind of defer it, but I think we'll
probably be able to do that so mark the next three in progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-manet-dlep-credit-flow-control-17  - IETF stream
   Dynamic Link Exchange Protocol (DLEP) Credit-Based Flow Control
   Messages and Data Items (Proposed Standard)
   Token: Jim Guichard

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

Jim: I don't think so. It looks like there's some exchange through email going
on. I think we'll just let that play out and and frankly, the next three
documents are the same. So unless anybody wants to bring anything up
specifically, these four were difficult because there's two of the authors are
now deceased, so we've been trying for quite some time to kind of clear these
out of their queue and my intention is to to to figure out whether we keep this
working group open or not. We've been having that discussion, but there's a
lack of engagement and these documents are kind of like the last piece of the
work they've been doing for quite some time.

Paul: If it wasn't for that, I would have probably suggested somehow rewriting
some of these documents into one to avoid all the duplicated intro of all the
documents where basically the entire document is like one IANA registration,
but i'm not sure I want to do that know with the deceased authors there.

Jim: To be honest with the working group itself, it's pretty much the chairs
that are helping to get this pushed along, so the engagement is almost
nonexistent. I've got Donald Eastlake has kind of picked up on it, so, and he's
one of the chairs and he'll get the work done. So I think most of this will
just get fleshed out through the email and then we'll have the conversation
about what to do with the working group.

Sandy: Sorry, quick question. This is Sandy. Are the diseased authors still
listed as authors on the documents?

Jim: I've got an editor on there, so it was all very complicated because
actually getting the documents published was difficult because we had to do
some jiggery pokery with the XML itself to actually get it to even work so
there's a long history behind.

Sandy: Get all of it. Understood. So we can rely, we'll work with the editor
once the documents are in the queue and hopefully you would approve in place of
the of the other authors that were listed.

Jim: Yes.

Liz: so Jim, this one's gonna stay in IESG evaluation for that discussed. Do
you want it in AD follow up or revised ID needed?

Jim: It's gonna be revised ID needed and I suspect the next three documents are
the same so put them in,
 actually put it in AD follow up for all four, I think.

Liz: This one is going to stay in IESG evaluation with a substate of AD follow
up, and then just for completeness and so we make sure we know what we're
doing, let's just go ahead and take a look at all of these even if they're all
gonna have the same outcome.

 o draft-ietf-manet-dlep-traffic-classification-13  - IETF stream
   Dynamic Link Exchange Protocol (DLEP) Traffic Classification Data
   Item (Proposed Standard)
   Token: Jim Guichard

Liz: We do have a few discusses here, so this one's also gonna stay in IESG
evaluation and to go AD follow up?

Jim: Yes, please.

 o draft-ietf-manet-dlep-da-credit-extension-20  - IETF stream
   DLEP DiffServ Aware Credit Window Extension (Proposed Standard)
   Token: Jim Guichard

Liz: We have one discuss on this one, this one is also IESG evaluation with AD
follow-up.

 o draft-ietf-manet-dlep-ether-credit-extension-08  - IETF stream
   DLEP IEEE 802.1Q Aware Credit Window Extension (Proposed Standard)
   Token: Jim Guichard

Liz: This one doesn't have any discusses.

Jim: Right, but it's reliant on the other three documents really. So that
they're kind of like a package of four. So just put this in AD follow up. I'll
release it once the other three are sorted out.

Liz: This one will be approve announcement to be sent; AD follow up so Jim you
can treat all those as a group.

 o draft-ietf-spring-srv6-srh-compression-22  - IETF stream
   Compressed SRv6 Segment List Encoding (CSID) (Proposed Standard)
   Token: Gunter Van de Velde

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

Gunter: Which one is this? So I think there is a new version just released -22.
I have a suspicion that it is all clear right now.

John: I reviewed that version to release my own discuss and it it looks to me
like it also satisfies what Erik was complaining about, but of course Erik
should be the one to say that.

Erik: I just cleared my discuss. 7AM brain, it took me a little while to read.

Liz: Look at that. We no longer have a discuss on this one.

Erik: THanks everyone for circling the issue.

Liz: So that means with no discusses left, this one goes to approved;
announcement to be sent. Gunter, do you want this in AD follow up?

Gunter: Yes, AD follow up, please. I want to because there were there were
quite some comments I wanna double check if everything actually has been
addressed or at least responded towards it so thank you.

Liz: This one will be in approve announcement to be sent; AD follow up and you
can let us know when it's ready.

 o draft-ietf-idr-sr-policy-safi-13  - IETF stream
   Advertising Segment Routing Policies in BGP (Proposed Standard)
   Token: Roman Danyliw

Liz: There are no discusses, so unless there's an objection now this one is
approved. Ok. This one is approved, Roman, do you want to move it straight on
through or do you want some more time with it?

Roman: I very much appreciate everyone's kind of thoughtful review. There's a
number of comments I'd like to to look at. I haven't had the opportunity to
look at the diffs because I know there's been updates, so if we could just put
it in approved announcement to be sent; AD follow up, please.

Liz: Of course, so this one will be approve announcement to be sent; AD follow
up. Roman, this document does have two down refs, so once we get to the final
steps, we're gonna ask you if you want to add these two to the down ref
registry. That's 4272 and 6950.

Roman: Will do. Thanks.

 o draft-ietf-lsr-flex-algo-bw-con-19  - IETF stream
   Flexible Algorithms: Bandwidth, Delay, Metrics and Constraints
   (Proposed Standard)
   Token: Gunter Van de Velde

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

Gunter: I don't think that necessarily has been discussions and communication
going back and forward. The authors are working on an updated draft. I was
assuming it would have been like released before the telechat, but apparently,
they didn't make it so, but I think everything looks good going forward. So
unless anybody who mentioned to discuss something else to say, please do so.

Liz: I think there has been a new version within the last couple of hours, I
think, but I don't know if anyone's had time to look at it yet. This one will
stay in IESG evaluation and do you wanna put it in AD follow up?

Gunter: AD follow-up for the moment, I'll figure out what to do.

Liz: This one is staying in IESG evaluation with the substate of AD follow up.

 o draft-ietf-bess-evpn-redundant-mcast-source-14  - IETF stream
   Multicast Source Redundancy in EVPN Networks (Proposed Standard)
   Token: Gunter Van de Velde

 Liz: This one does not have any discusses, unless there's an objection now,
 this one is approved. Ok. I think this one is approved. Gunter, is it ready to
 go or do you want to put it in AD follow-up?

Gunter: AD follow-up, please.

Liz: This one is approve announcement to be sent; AD follow up and you can let
us know when it's ready.

 o draft-ietf-dmarc-dmarcbis-38  - IETF stream
   Domain-based Message Authentication, Reporting, and Conformance
   (DMARC) (Proposed Standard)
   Token: Murray Kucherawy

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

Murray: I don't need to so I guess AD follow-up.

Liz: This one will stay in IESG evaluation with the substate of AD follow up,
and Murray as an FYI, once this gets to the eventual approval, this one does
have two down refs, so we will want to know if 7489 and 7960 should be added to
the down ref.

Murray: This is oh this is the obsoleting 7489, so does it have to down ref it?
This is the one that Roman you and you emailed Elliot about.

Roman: Talk me through the thinking between the link of the the obsoleting
versus kind of getting approval from the ISE to do this. That was what the
that's what I meant with the permission from the ISE.

Murray: Right, they happen to be the same document, the linkage is very weak.
I'm reminding you that we're talking about the same reference here. The issue
is that 7049 is a reference, but also we're not depending on it normatively for
anything. It's more like this was the document that was there before. Do you
have to make it a down ref for that?

Liz: Well, you definitely don't have to add it to the down rough registry, so
the answer to my question can be no.

Francesca: It's a down ref right now because it is normatively referenced. That
makes it a down ref.

Murray: I might want to do back and have that changed to informative. Let me
look into that, but it's being obsoleted and if it doesn't say that it really
should. Alright, I'll follow up on that point too.

Deb: It doesn't have to be in the registry, you just have to down ref it.
That's not a problem, right?

Murray: No, I don't think so. I'm just trying to be neat and tidy, that's all.

Eric: But if it's obsoleted, there's no point adding it to the down ref
registry anyways.

Murray: Right. Nothing else should have to down ref this.

Eric: So don't put it there.

Francesca: I guess the question is, if you're obsoleting it, do you want it as
a normative reference for the document that is obsoleting it. That's the
question.

Murray: Right. That's the other tidy, that's the other way to tidy this up.

 o draft-ietf-ipsecme-g-ikev2-20  - IETF stream
   Group Key Management using IKEv2 (Proposed Standard)
   Token: Deb Cooley

Liz: We have a couple of discusses, do we want these now?

Deb: I think it's fine, the discussion si already happening behind the scenes
so I think we need this in revised ID needed.

Paul: Most of my discussions points have already been addressed by Valery in
email. I just have to go through and clean up, but this will be done like in
the next two days.

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

 o draft-ietf-ipsecme-ikev2-rename-esn-03  - IETF stream
   Renaming Extended Sequence Number (ESN) Transform Type in the
   Internet Key Exchange Protocol Version 2 (IKEv2) (Proposed Standard)
   Token: Deb Cooley

Liz: This one doesn't have any discussions though unless there's an objection
now, this one is approved.

Deb: Put this in revised ID needed.

Liz: So this one is approve announcement to be sent; revised ID needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 o status-change-ntpv2-ntpv3-to-historic-01  - IETF stream
   Status Change of NTPv2 and NTPv3 to Historic (None)
   Token: Erik Kline

Liz: There were no objections to this so I think this is ready to go through.
Does anyone have anything else they want to discuss about it?

Francesca: No objections. This is what some of those brought up by Pete. Erik?

Erik: Yes, this was one of the inconsistencies that Pete Resnick observed.

Francesca: Right.  I just want to say that you know the the other documents I
took the action items not so not on this status change, but  I started the
status change last call on on the other documents that Pete had suggested that
we move to historic and it has created a bit more discussion than I expected,
so I need to really carefully read through the last couple of comments before I
bring it to the telechat. I hope to do it before I step down. But if I don't,
then I will need someone to take over that.

Erik: Even this generated a little bit of discussion in the NTP group working
group, but it was almost entirely around what does historic mean, what do words
mean.

Francesca: It's sort of the same on, on the other one and it was more about,
oh, but it seems we have a bigger problem and why don't we fix the bigger
problem and this is confusing and high level comments like that.

Roman: One narrow difference I observe between the bigger one you're talking
about Francesca and the one on deck here is that we have an active working
group here and they're reasoning about that, and as I understood some of the
larger kind of conversation, it's exactly how you framed it. It's a more
general problem, maybe there's the working group maybe kind of there's not,
it's really a question of how to handle that status for everything
holistically. And that's throwing it out.

Francesca:  I'll try to bring it back. I might bring it as a management item
rather than a status change to discuss more widely with the rest of you guys.

Liz:  Erik, this one is approved, is this ready to ship?

Erik: I saw no comments, so I guess I don't know what the next step is.

Liz: The next step is either we go ahead and send the announcements or you take
some more time to check it over and make sure that it's ready.

Erik: I would change nothing, so I guess let's proceed into the fire.

Liz: So approved announcement to be sent, announcement to be sent, and we will
get that all taken care of.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 NONE

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 NONE

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-irtf-nmrg-green-ps-00
   IETF conflict review for draft-irtf-nmrg-green-ps
     draft-irtf-nmrg-green-ps-04
     Challenges and Opportunities in Management for Green Networking
   (IRTF: Informational)
   Token: Mahesh Jethanandani

Liz: We have a discuss here, i'm guessing we want to discuss this now?

Mahesh: Sorry for the confusion around this document, this is the 1st time I
was dealing with a conflict review. So I put my own document in and discuss
which well I just wanted to have a discussion around the conflict. I naturally
thought it was put it in discuss when I could have left it in yes and still had
the document reviewed. So from a process perspective, my first confusion was
with the response. So there in the choice of responses basically was don't
publish because there's a conflict or publish go ahead, not a problem. And what
I was trying to articulate in my conflict was something in between and I
mentioned that even on the chat. So that was a bit of a confusion on my part,
not understanding how to articulate the fact that there is some ballot text
that it will explain. Anyway, it invoked that response from Alex about wanting
to challenge the decision which we are still only discussing now. So that is
from a process perspective, then from a content perspective, as I'm as I feel I
think the document has some overlap with the text in Green or the charter in
Green, so that's I think even Roman saw that in the document and I did discuss
it with Colin. Colin agreed and said that yes, he thinks the document needs to
be revised. And so we that's the conclusion we left with. But now it's a
question of I guess waiting for the document to be updated.

Roman: Let me jump in here with process, I'm gonna step back and repeat what I
think some people know, because we something we infrequently run the conflict
group process, but we don't often end up with the results not published, so
kind of let me level set us here. So what's gonna ultimately gonna happen here
is we're gonna come to a conflict review result. Once we get to the point of
clearing the ballot to make a decision, Colin and the authors can kind of
process it. Of course, the authors in Colin can watch what it is that we're
talking about. But the question for us is, can we as the IESG get to a decided
on conflict review position? And to get that we have a proposed conflict review
position which is not to publish kind of at this time. So my question to you,
Mahesh cause I'm just looking at because everyone else did no objection or yes,
which means they support the conflict review position of not to publish. You
have a discuss which procedurally means you disagree with the conflict review
position of not to publish, so what I'm asking you is not to change your mind,
but what it sounds like is you agree with the do not publish decision that you
put in. But what you're trying to do is put some text in to explain why you're
holding the position very much the same way I wrote to explain my position. So
I think procedurally, if your intent is to say, I agree with this conflict
reposition, let me explain why I think that way, then your position is not
discussed because in this case like it's not like a document might discuss
holds the document here then you're supporting the position of not to proceed
and so the ballot is comment or yes or whatever is that then we get a decision
from the IESG and then can be actioned. If that makes sense.

Mahesh: So it’s clearly a case of too many double negatives that got me off.

Roman: So that's the succinct way of putting it. This is a double negative
situation.

Mahesh: So yes, my position would be a yes, and then now it's a question of
what text we want to agree on.

Roman: I mean if we say don't kinda publish, I mean it's very helpful to be
concrete on what it is that is raising concern because that provides options
practically to Colin and the authors to figure out how they respond to us and
procedurally I wanted to everyone, this is ultimately a recommendation to the
other stream. They can choose to ignore this as I recollect the process, this
will go back to Colin so being more specific helps and provides options.

Zahed:  I kind of viewed Mahesh on doing the review and he's also discussing
his own decision. So I thought like what we could do here is Mahesh goes to no
objection or yes and then puts his comment. He kind of explained why he has
this conclusion like the recommended text and that is basically the reason I
mean, do we need to be more specific than what Mahesh says and what you said
also because you have been more
 specific giving suggestions. Is this not good enough for the RG chairs to
 reconsider?

Roman: Again, I want to be very sensitive to the separation of kind of power
here. Like I am an AD just like the rest of you equally validating, so I am not
in a position to tell you what to ballot. I am just being persuasive and
explaining the process. So do you want to be more specific? You don't have to
be. But I recommend that you would if you think you need to be, and then
procedurally, I think what needs to happen is if you and now I'm looking back
at you Mahesh. If your position is you support it, like you gotta flip your
ballot because flipping the ballot, is how you you it's deconflicts the double
negative situation that we've ended up in. So if you can be more specific
that's winning you don't need to be more specific.

Zahed: This is a recommendation from you to be more specific, but I think
process wise as I think Mahesh keep this double negative because I think there
was some confusion I think anyway, he doesn't want to discuss his own
 decision there. So I think you need to change your ballot, Mahesh.

Roman: Sorry, I didn't start a kind of a queue. You have a suggestion kind of
Paul, but Deb I think you were trying to jump in to comment on what side was
doing, so if we can just keep the thread and then we'll pick you up Paul and
I'll start the queue so we can better balance.

Deb:  I thought there was a provision in the conflict reviewed statement that
allowed you to add optional text.

Mahesh: You can do that in the ballot text.

Deb: That's what I meant.

Eric: I think you can put it below. The first line is basically publish or not
published. Then after you can put something below, I think.

Mahesh: maybe when I pulled up the template I think it was one of those
template responses and then something that IANA can add. I didn't think that
that was the place for me to add extra text. What Roman and I discussed Roman
said put it in ballot text. So that's when I went and put it in the ballot text.

Eric: Both are OK for me.

Deb:  I don't know which is correct because I thought I saw a provision for
making optional comments when you did a conflict review. But I mean I've only
done a couple so maybe i'm wrong.

Cindy: It's a boilerplate response that goes out includes a line that says
something to be effect of the IESG would also like the IRTF to review the
comments in the Datatracker and then it points to the ballot.

Mahesh: That was my understanding.

Deb: I understand, I think.

Eric: What basically matters is Colin getting our comments and the authors.

Roman: Paul, you had a proposal for us.

Paul: I didn't ballot because I was confused by the situation and I think I
want to have some time to reinterpret this now with with Mahesh's vote changed
to yes because I am leaning actually towards that I want this to be published,
so I wanna think about this some more now that we've changed the context. So,
can we punt this to the next telechat?

Roman: So procedural levers, if I can just be reminded. Can Paul just hit the
defer button now?

Cindy: Yeah, a document discussion can be deferred during a telechat. He can
hit that button or we can do that. That's fine.

Roman: And that's procedurally, OK?

Cindy: Yes. Shall we go ahead and do that for you?

Paul: Yes unless there's people who have stronger objections to coming back to
this next week.
 I don't think there's an urgency here.

Roman: But again, kind of separation, any AD can say I need more time, and so
if you are saying you need more time, it's your prerogative to hit kind of
defer.

Paul: Okay, well let me hit the defer so the record shows that I am to blame.

Cindy: I just wanna double check because the states for conflict review are
slightly different. There may not actually be an official defer on this. Let me
see if that's true or not. Oh, there is, ok, so yes, you should be able to.

Roman: There is a defer ballot. I've never done it before, i've never seen it
before, but I think we have the lever.

Liz: If the button works.

Cindy: If it doesn't work, we'll sort it out, but just know that like the some
of the the point raised et cetera, states aren't always there for conflict
review stuff. But if defer is there, then yes, Paul, if you could hit that
button, then that would be great.

Liz: Paul is deferring this one and we will put it back on the next telechat
for further discussion.

 o conflict-review-irtf-cfrg-kangarootwelve-00
   IETF conflict review for draft-irtf-cfrg-kangarootwelve
     draft-irtf-cfrg-kangarootwelve-16
     KangarooTwelve and TurboSHAKE (IRTF: Informational)
   Token: Deb Cooley

Liz: There are no objections here, so unless anyone has a comment now. It looks
like now this is approved and can go back to IRSG.

Deb: Unless Eric V has actual comments on this, I think it's ready.

Eric: Let me check my comment that I put there.

Deb: There is a third order PPM relies on a VDAF draft, which is also a CFRG
draft, which relies on this draft, also a CFRG draft so there's a very indirect
link to PPM. I did check with PPM just to make sure, so that's why I put it on
there.

Eric: Okay, anyway, you can put this into a conflict. I don't see a conflict,
but if you think there is a conflict or an overlap, that's fine. Anyway, it
doesn't prevent publication.

Deb: Exactly. It just says there's a relationship there. It doesn't say there's
any reason to not publish.

Liz: This conflict review is approved and Deb, is this ready to send?

Deb: Ship it.

Liz: Approved announcement to be sent, to be sent.

3.4.2 Returning items

 NONE

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

 o Domain Keys Identified Mail (dkim)

Liz:  I don't see any blocking comments. Is there any objection now to sending
this for external review?

Murray: i've got nothing pending on it, if that's it then let it rip.

Liz: We will go ahead and send this external review announcements with a
separate message to New Work and we will put it back on the agenda for the next
telechat for approval.

 o RESTful Provisioning Protocol (rpp)

Liz: Is this ready for external review, we have no blocking comments?

Orie: I hope it's ready. I believe it's ready. First time getting to this
stage, so any process advice for me?

Liz: I don't think so. If you want to take a minute and just double check it
and make sure it's ready, we can hold off or if you think it's ready to go, we
can just go ahead and send the external review announcement now.

Roman: I haven't looked at it and I haven't looked at it where I always like to
check the markdown that it's rendering right.

Orie: Okay, I'll do a final check on the markdown and I'll follow up sometime
later today.

(later during the telechat)

Orie: On the RPP charter, I looked at the markdown and it looks good to send so
I don't want to wait for another round of cycling before approving that.

Liz: OK great. We will go ahead and announce the RPP external review now
without waiting for anything

 o Digital Emblems (diem)

Liz: We do have a couple of blocking comments here, do we want to talk about
this now?

Orie: Yeah, I would like to chat a little bit about it. So first of all, I
appreciate the comments from everyone who's left them on the document. The two
abstained positions sort of align well with what Paul had said. I think and
also I think basically everyone is saying the same thing about the document.
There's some history here in how we got to this point for the document. I think
it is possible to be more precise in narrowing the charter on use case or
narrowing the charter on technologies that it's gonna be supporting, and
there's sort of, maybe a pros and cons for taking either approach here. But I
wonder if for any of the folks who've left a block comment whether they have an
intuition on what the right path forward would be.

Paul: So speaking for me, I actually don't have any idea because like I was at
both BoFs and the room was completely split over what to do. And I thought the
charter would then pick a subset of it and say like let's do this first and do
the other one maybe later. But the way it's been phrased now, it sort of
included everything again with like sort of weird weasel wording, and so now
I'm not sure because now you're hitting the point where the reason why I half
the room set no to some of this was because they thought that one  solution
couldn't basically target both of them. So you cannot have one solution that
targets digital assets and also physical assets and it's sort of being merged
into one now. And I have no idea how that would work and then specifically what
I said too, one of the conditions I heard during the BoF was like a validator
should be able to validate things without being known that he's there so that,
an army can do a reconnaissance flight, see what medical things are there
without telling them that they're about to bomb the area around the medical
stuff. That seems to have been sort of dropped off and that falls squarely into
the digital versus analog asset and what's the media, is it the QR code? Do you
need to be physically near or is it the broadcast that goes over the entire
city? And with all of those sort of unresolved I'm not sure if the working
group can actually get work done.

Roman: Since you're asking Orie procedurally I want to open with like it's up
to the community to decide
 how they wanna do that. From my perspective, like Paul, like at the BoF I
 heard we had two very clear camps. One of them seemed to have very much more
 narrow use case, which could actually explain what a digital kind of emblem is.
It constrained it very tightly. They had what sounded like a very descriptive
and clear use case as to what the deployment would look like. And then we have
something else that I think was this is more the digital case. It certainly was
more kind of sweeping, more comprehensive and some of the ambiguity as you said
is because we put those together and let's be very, very fair to the different
proponent camps. The IESG told them to do that, to put them together. Now
having having seen them to attempt to put them together, I wonder whether we
should revisit that decision and the different camps should make a pitch,
perhaps using the word hard fork, for different charters on their perspectives
and would those distinct charters to satisfies those different use cases. Could
they bring us to the next step? Would that bring us to the next step that some
of that work could be done in existing working groups? I'm thinking kind of
SPICE, maybe we're doing a bit of a compare and contrast with a new charter,
help us tease out what are the specifics here and what's the novelty here that
might get us to the next step. But I think
 it would be very hard to clarify what I heard on the BoFs, some of the
 questions that got posed here, but I'm open to rereading.

Paul: So just one clarification on that Roman. You mentioned SPICE, but SPICE
is very much a interactive protocol, right? You get like a client server
responses back, I think and in this case, it is very much more of a broadcast
data and receive it. I don't see that as much related to.

Orie: So SPICE has a line in its charter about creating profiles for different
credential use cases and the classic JWT and CWT credential formats that SPICE
is sort of targeting extending. There is a bearer mode of them. I tend to think
of these digital emblems as basically bearer tokens that are displayed very
publicly. That's just my my take on the technology side of it. I think we could
potentially be a little bit more precise in terms of the interaction model, the
media, the transports in the charter, and still keep the use cases sort of open
for DIEM.  I think in order to do that
 and to get consensus, we would have to be much more precise about like,
 securing mechanisms or, discovery,
like we would have to use text in the maybe in the body of the charter to
constrain that part of what the work would do and then leave the data modeling,
and attribute extension stuff sort of open.

Roman: The other possibility to build on what you're talking about is that the
work, the workgroup as chartered right now could just be less ambitious. It
could target where there is consensus and the rest would be out of scope after
the after progress has been made on some subset of that. And I know it tries to
do that now, but with an ill defined in my assessment version of kind of what a
first MVP would look like for a particular use case, but I'm arguing maybe
 even be less ambitious to not really solve everything for one use case or
 perhaps that's option A option B might be, well,
wake, we're not even gonna do any new protocol work. We're gonna really nail
down the notional architecture use cases and requirements to hammer on it
further, but we're gonna need a recharter to do anything more. I don't know
what's gonna what's gonna proceed but that's some more additional options.

Orie:  The last part, I've not seen a working group charter that only did,
informational or architecture documents, but, are you saying that perhaps some
of the protocol data format pieces of DIEM could be done in other working
groups and DIEM would just cover an interaction model informationally or what
do you mean by that?

Roman: So everyone else is gonna help me because these are all working groups
in your area, but I think like IP wave, as I recollect didn't have protocol
work in scope. I think Eric, I'm looking at you like MEDINAS was really only
doing requirements architectures, is it through MOPS?

Eric: To come back to Orie, I was the responsible ADs for the two BoFs so thank
you Orie for taking the lead there. If we do create a working group only doing
informational documents basically and the IETF provide nothing to the use case,
I am really concerned that the people will go outside of the IETF. So we think
we need to deliver a charter with something concrete usable, operationally and
securely, of course, after. So I would really we may reduce the use case, but
please deliver something with proposed standards there. And if we narrow the
charter, we can start immediately and approve it maybe next telechat. We can
approve a second charter on the same BoF. That could be this one complete
informational.

Orie: One of the the challenges that I've been having with this work is it it
doesn't there's a security component to it, but it's not a living well within
an existing security community working group, like it's not CMS, it's not JOSE,
it's not COSE, it's not, PGP. That would really help me a lot to sort of see
some narrowing on those dimensions. I don't know what security ADs in
particular is that the kind of thing that you think would help here or, is that
maybe not the right place to try and narrow on the technology front? Like I'd
like to come back with a charter that narrows both use cases and technology.

Paul: I think right now we don't know enough of where it would go to actually
pick the right technology. Like are we just looking at like presenting a signed
certificate with a non refreshness and then looking at like is this still
acceptable on the validator or do we need something else that that like I think
it really depends on on other things also it doesn't have to go over Bluetooth
or something? There might be transport constrictions there that like sort of
interfere with things as well. So I don't think you can right now say  which
security technology you want to use. Unfortunately that is going to be a large
part of the actually working group work.

Orie: Thanks for the comments here. I think what I'll do is I'll have a chat
with proponents and I'll try and get a sense as to where we can do a narrowing,
and I'll try and prepare a revised charter that narrows. I would like for it to
narrow on use cases and technologies. I think we do know a little bit about the
intended deployment model here enough to pick among some of the securing
technologies at this point.

Paul: And I think if you can limit it to physical assets, that would help too,
because this whole online asset thing is really kind of weird because an online
asset also doesn't have a location and so that makes things really super
complicated. And you can always and you can always say like, this is the uplink
modem of the hospital. So it's a physical asset even though you really mean
that you're protecting the online connectivity.

Eric:  But on the other end, right, I could see during a TLS handshake to a web
server or somehow, this is one that is protected by international law. This is
an easy win.

Orie: I think right now the there is a general alignment that at least some new
RR type or _prefix, and I'm looking at you, Paul, might be something where
there could be consensus and maybe just constraining them to one proposed
standard document in that space is a good starting point for an initial charter.

Roman: So I don't know whether this is useful Orie, but you were talking about
narrowing maybe I think that that's certainly an approach to the other set of
words I would use is provide specificity, even if you're not narrowing. I think
Eric just brought up like a really good one. If you were able to provide
specificity that, and maybe this is the equivalent of narrowing I I'm kind of
not sure like if you actually define what an emblem is, it's or you define it
that an asset is things protected by international laws that might help us
iterate us to a solution. With large caveats that recharters are possible, but
we gotta start somewhere.

Orie: Understood. Thank you for the comments. I'll try and provide a revised
charter as soon as I can.

Paul: Feel free to reach out to me for a draft text or questions.

Eric: Do we have a placeholder for IETF 122 for DIEM?

Orie: Ee have a placeholder BoF request, but this is a group that's already
bought multiple times. So I think, procedurally what we're on right now is we
have this charter we need to do some revising on top of it. If we can get the
charter to the point where we feel like it's ready for external review, great.
If we can't get the working group landed in time for 122, there won't be a
meeting of the working group at 122 and there won't be a BoF. Perhaps there
could be a group of proponents that can still chat about where we are in the
process and all of that and i'm happy to support on that front, but that's kind
of where we are in the process.

Liz: I will probably though, just because it's always easier to take away a
session than fit in a new one, so I probably will put in a session request for
it and schedule it as if it's gonna happen and then just take it away if it's,
if it's not gonna go as opposed to the other way around cause then the
conflicts would be a mess, so you will probably see a session request for it,
but that doesn't mean  we still won't know for sure if it's going to be
scheduled or not unless we know it's going to be approved.

Orie: Awesome. Thank you.

Liz: So we will just leave this where it is for now, Orie and you can let us
know when it's ready to maybe come back another chat or what you want to do
with it.

4.1.2 Proposed for approval

 o Taking IP To Other Planets (tiptop)

Liz: There are no blocking comments, any last minute objections to approving
this charter?

Eric: And if not, thank you so much for bearing with me all the the revision of
this working group specifically for Paul, Roman and David if he's on the call.
I think now the charter is pretty clear. We never intended to change TLS and I
would guess if they want to do security or transport work in the working group,
there will be no security except really if Paul and Deb wants us to do it, but
under your supervision.

Paul: No, I mostly just wanted to point out that  you don't want to be too
quick to just say 'oh, we can use QUIC on this.' Because like it is there's a
reason for the bundle protocol outside with these people. To batch things up
and send them because that just works better over large distances. So I just
wanted to make sure that, you're not committing yourself to using QUIC, whether
it is QUIC or a changed version of QUIC. So that was my main point.

Eric: The working group could be no QUIC is not workable or it's workable to
the moon, let's say or but not to mars. So that's a useful thing to do. I mean,
it's a pointing but useful thing to do.

Erik: Well, that kind of question seems like it could have been answered in a
research group, but they didn't want a research group. They wanted a working
group and they didn't want to do the work in DTN. We began to open up the
charter of DTN to see if we could include the work there, but they decidedly
we're not interested in doing DTN. And the charter has text it won't interfere
with DTN, so that seems fine.

Liz: Eric, is this charter text ready to go or do you wanna make any other
changes to it?

Eric: I would not dare to make any changes to it now. Let's ship it.

Liz: The text is approved, but we still do need chairs.

Eric: I got a couple of suggestions I'm finalizing with them tomorrow and to be
honest, I think I can say it right now. One of the chair could be one of the
active outgoing AD. So I'm not sure whether I can already select a chair which
is an outgoing AD in Dataracker.

Cindy: Funnily enough, we're gonna have another discussion later. I think
technically, we can, it's it's a question of optics and I would suggest if you
have multiple chairs, it is cleaner if you wait until after the plenary to name
an outgoing AD as chair.

Eric: That was my plan.

Roman: I 100% agree on that.

Eric: That was also my plan. You will get a chair tomorrow afternoon, my time.

Liz: After we get the chair, who is not an AD we will go ahead and send the
announcements.

 o Heuristics and Algorithms to Prioritize Protocol deploYment (happy)

Liz: There are no blocking comments, so it looks like it's approved unless
anyone has any final objections.

Zahed: I'm getting really good at creating new working groups and creating
charters, but I think a very good run on this one. I don't see like anything
that I should be editing. I think this should be very focused and it has got
some other people who are interested looked into that one. So it's ready unless
somebody has a complaint right now.

Liz: I'm not hearing any, so I think we can go ahead and call this one
approved. Zahed, is this ready to go or do you wanna make any more final edits?

Zahed: You need chairs, right? So I need to pick chairs. I'll get it to you as
soon as possible.

Liz: Ok great. Approved but pending the addition of chairs, and we will wait
for those from Zahed.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o IP Security Maintenance and Extensions (ipsecme)

Liz: There are NO blocking comments here, so any objections to approving this
recharter?

Deb: Eric V posted two comments, and both Tero and I replied to him as long as
he think those are OK.

Eric: That's ok anyway, you could fairly ignore it. No problem.

Deb: It's ready to go.

Liz: This is approved and ready to go, so we will go ahead and send the working
group action recharter announcement.

 o Link State Vector Routing (lsvr)

Liz: There are no blocking comments for this either, so does anyone have any
final objections to approving this recharter? I'm not hearing any objections so
I think it's ready to go. Jim, is this ready to be announced?

Jim: It is, please ship it.

Liz: We will go ahead and send out this recharter announcement.

5. IAB news we can use

John: That always catches me by surprise, news we might Well, anyway, the news
that I noted down are, one is the IAB was having a long and involved discussion
about whether they need to have security considerations in their documents
instead of putting any of this section left blank, they'll decide whatever they
decide, they believe decided to have a second IABopen session at 122 just to
talk about WSIS which is the World Summit on the Information Society. And other
than that scheduling meetings is hard across global time zones, which they're
even worse often than we are. Anything to add, anybody?

Tommy: We will have that second WSIS session at the next IETF meeting. These
are both gonna be short meetings, so we don't want to take up too much agenda
time. The only other thing to mention is we should be sending along the ISOC
board of trustee appointment for IESG confirmation soon. So you'll see that
coming to you.

Liz: And just the detail on the time zone comment for whoever might want to be
the liaison to the IAB in March, so their meetings are gonna be moving one hour
earlier, at least for the first six months or so, maybe reassess at the next
daylight savings in the North American Fall, but so their meetings are gonna be
on Wednesday at one hour earlier than these telechats start so take note if you
want to IAB liaison.

6. Management issues

6.1 Final BoF Approvals for IETF 122 (All)

The management issue was discussed. See the minutes of the IETF 122 BOF Call
meeting for details.

6.2 [IANA #1412130] Designated experts for RFC-ietf-ntp-update-registries
(Updating the NTP Registries)

Liz: This is just the official action item assigning this to Erik Kline.

6.3 IANABIS Scheduling at IETF 122 (Murray)

Liz: IANABIS was approved back at the end of last year, but it's still listed
as proposed in the Datatracker because there aren't chairs and so Murray will
become a chair once he steps down, but if we want to schedule a session for
this at 122, it gets a little complicated.

Roman: So Murray, is the fix here you make me responsible AD for this? I find
or we find, a chair to sit with you and then we can do this switch after?

Murray: I think the something close to that, I can't be AD and chair, but
someone could appoint me chair or we could find someone who's just we tell them
you are the chair, you don't actually have to do anything. This will change
after Wednesday. We just need a name there that isn't an AD.

(crosstalk)

Francesca: But Murray, you would have a co-chair, right?

Murray: Yes, but we don't need that to get started, but I haven't identified a
co chair yet, so that's kind of why we're stuck. I don't have a co-chair.

Francesca: I think you should find a co-chair.

Murray: I mean Harald's been running mediaman by himself for all this time, so
let me try to find one and that would solve this problem. I’ve just been parked
on me being the start that for so long, I haven't even thought about it.

Deb: Are you claiming to be as good as Alvestrand?

Roman: Murray, i'll give you a hand on this. We can work this on this offline
because we definitely want a co-chair either way.

Murray: I've exhausted my usual suspects, that's all I was going to say.

Francesca: I was going to say is I don't think it's any problem to have Murray
like assigned as chair even if he's finishing his AD duties as long as he's not
the responsible AD. It's a bad look if an AD is chair, but given that he's
stepping down as AD, it's obvious and they have their first meeting at 122.
It's really not like there's really not anything that he can do that is going
to be a bad look.

Roman: I mean the responsible AD that's outgoing, delegating themselves the
working group chair is a very bad look.

Francesca: I'm saying once he's not the responsible AD.

Eric: We were just talking about TIPTOP in the same situation, and I will
defer. You do whatever you want. I don't mind but be consistent here.

Roman: The right answer is we should have a co-chair irrespective of who is the
other chair that might be Murray. We will work on that.

Murray: I'll look around. How soon do we have to pull this off, Liz? Before we
can't schedule it.

Liz: I mean hopefully as soon as possible I think I can put in a session
request. Actually, I'm not sure if I can put in
 a session request for it right now. I will look into that.

Murray: Do we need to create a fake BoF placeholder just so the  Datatracker is
happy?

Cindy: There's already a Datatracker group for this so you should be able to
create the session request and I think that
 like if it's not sorted out by the time the preliminary agenda is published,
 it's gonna have that new proposed tag on
it that shows up on the agenda. I think then you just have to figure out at
what point you want to pull it when you don't have the chair stuff sorted out.

Liz: I can just go ahead and submit a session request for it now. I don't need
you to do a BoF placeholder, but just before we know who the chair is, it's
hard to know what conflicts are gonna be so the scheduling and it has to be on
Thursday because, you'll be AD until Wednesday so yeah it might get a little
tricky with scheduling, but I can go ahead and pretend like it's gonna be real
and scheduled as it will be real.

Murray: I'll work this out with Roman. I'm already pinging a couple of people.

Liz: Should we go ahead and change the responsible AD for that group now or
just wait?

Murray: Roman, this is a GEN area thing anyway?

Roman: Yeah, you can give it back to me. Murray was giving me a hand which I
greatly appreciate to move this ball forward because he knows the most about
this, but regardless, it's GEN. Murray is rotating out whether he takes another
leadership role or not.

Liz: We will make Roman the responsible AD, and I will put in a session request
for it. We will wait to hear about chairs.

6.4 Retreat Logistics (Cindy)

The management issue was discussed. IESG agreed to move forward with proposal 2.

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

Francesca: The next informal that the you guys secretariat is doing the
presentation?

Cindy: No, that will be on the 27th. The next formal has the agenda
deconfliction on it.

Francesca: Just making sure that the new ADs are on for both, I guess. They
should definitely join your presentation and they probably should also join the
agenda, they're deconflicting since they will be a part of it, correct?

Cindy: Certainly for the onboarding one.

Liz: For agenda deconfliction, it's always nice to observe one before you have
to do one. It might be confusing but it's good to observe next week.

Cindy: Depending when in the week a working group is scheduled also the
incoming ADs may be the ones who have the conflicts.

Francesca: Please join if you can.

Roman: Any other topics? As a reminder that the next formal telechat two weeks
from now, it's a little over 500 pages so next week might be a good reading
week. We want to blow the back log out.