Narrative Minutes interim-2024-iesg-25: Thu 15:00
narrative-minutes-interim-2024-iesg-25-202411211500-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-11-21 IESG Teleconference

These are not an official record of the meeting.
Narrative Scribe: Liz Flynn, Secretariat

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Jenny Bui (AMS) / IETF Secretariat
Deb Cooley (DHS CISA) / Security Area
Roman Danyliw (CERT/SEI) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Web and Internet Transport Area
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
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Warren Kumari (Google) / Operations and Management Area
Tommy Pauly (Apple) / IAB Chair
David Schinazi (Google) / IAB Liaison

OBSERVERS
---------------------------------
Greg Wood

1.2 Bash the agenda

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

Éric V: Time allowing, I'd love to discuss the next steps for DIEM and
DEEPSPACE.

1.3 Approval of the minutes of past telechats

Liz: We have two sets of minutes to approve today. Does anyone have an
objection to the minutes of the October 17 IESG Teleconference being approved?
I'm hearing no objection, so those are approved and they'll be posted.

Liz: Does anyone have an objection to the minutes of the October 24 IESG
Teleconference being approved?  I'm hearing no objection, so those are approved
and they'll be posted.

Liz: Does anyone have an objection to the narrative minutes of the October 17
IESG Teleconference being approved?  I'm hearing no objection, so those are
approved and they'll be posted.

Liz: Does anyone have an objection to the narrative minutes of the October 24
IESG Teleconference being approved?  I'm hearing no objection, so those are
approved and they'll be posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

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

Zahed: I've identified but I'm still waiting for one to respond. I should have
this by next time.

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

Murray: In progress.

     o Erik Kline to find designated experts for RFC 9669 (BPF Instruction
       Set Architecture (ISA)) [IANA #1394753].

Erik K: I actually already have names for this one, should I send them to you?

Liz: Yes, please send the names to support@ietf.org and we'll add those to the
end of the agenda.

     o Gunter Van de Velde to find designated experts for RFC 9666 (Area
       Proxy for IS-IS) [IANA #1394691].

Liz: Gunter, this is a new one for you.

   * OPEN ACTION ITEMS

     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.

Liz: I know this one is done, because the statement has been published.

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

Murray: This needs one more round. We were going to do it in Dublin and didn't
have time, so I'll get to this. 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 prepare status changes or another way forward
       for the handful of obsoleted documents Pete Resnick emailed the
       IESG about on 2 Nov 2024.
     o Roman Danyliw to take a look at Datatracker documentation of
       document states and update as needed.

Roman: All of mine are in progress.

     o Secretariat to update non-wg list guidelines to include a link to
       IESG Statement on Disruptive Posting and detail on list moderation.

Liz: We haven't gotten to this yet; that's in progress.

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

Roman: Can you remind me what the context of this was?

Liz: I don't remember off the top of my head, but I can pull up this section of
the notes.

Paul: If I remember correctly, this was just that if authors wanted to do the
github experiment, that the ADs would always say yes. Not that we decide to do
all of it as an experiment, just that we would not be a blocking factor and
participate if others decided to do the experiment.

Roman: Thanks.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-ace-wg-coap-eap-11  - IETF stream
   EAP-based Authentication Service for CoAP (Proposed Standard)
   Token: Paul Wouters

Liz: We have a few Discusses here; do we want to discuss these today?

Paul: I don't know. Not me specifically, I didn't have time to look at it yet.

Francesca: Mine is quite easy and hopefully the authors can just respond. And
of course you haven't had time, I just posted it half an hour ago; sorry about
that.

Éric V: Mine is also very simple, mainly addressing the shepherd writeup
because he did not check the IPR and whether authors are willing to be authors.
Easy to fix as well.

Paul: Okay. Please put it in AD Followup.

Liz: Great; this one is staying in IESG Evaluation::AD Followup.

 o draft-ietf-lamps-header-protection-24  - IETF stream
   Header Protection for Cryptographically Protected E-mail (Proposed
   Standard)
   Token: Roman Danyliw

Liz: There are no Discusses in the tracker, so unless there's an objection now,
this is approved. Okay, this is approved. Roman, is this ready to go?

Roman: First I want to say thank you to everyone for the review of this very
long document. Can we please put it in Approved, AD Followup? There are some
comments there I want to understand. It's likely to be revised I-D needed but I
want to sweep through them first.

Liz: No problem; so this one will be Approved, Announcement to be Sent::AD
Followup.

 o draft-ietf-pce-stateful-pce-optional-10  - IETF stream
   Extension for Stateful PCE to allow Optional Processing of PCE
   Communication Protocol (PCEP) Objects (Proposed Standard)
   Token: Roman Danyliw

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

Roman: Again, thank you for everyone's feedback. There are a few things in the
comments I think should be reflected, so can we have this one Revised I-D
Needed?

Liz: Absolutely; this one is Approved, Announcement to be Sent::Revised I-D
Needed.

 o draft-ietf-nfsv4-layrec-02  - IETF stream
   Reporting of Errors via LAYOUTRETURN in NFSv4.2 (Proposed Standard)
   Token: Zaheduzzaman Sarker

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

Zahed: I think I've got some comments on the resilvering. I also picked that up
and was told by the nfsv4 chairs that this is a really well known terminology.
Maybe we can just describe it in another way so that others can understand.
Other than that, I don't have anything else. If this is approved now I will
just put it in AD Followup.

John: One of the authors replied to my comment and said he'd add a definition
for resilvering.

Zahed: That's great. It's pretty obvious for them because they use the term day
by day but just adding something would be great.

Deb: Is this the one with the terminology section where they point to another
RFC? It is in that other RFC.

Zahed: Yeah. But anyway, I think they can just be descriptive about it.

Liz: Okay, so this document is Approved, Announcement to be Sent::AD Followup.

Zahed: Thanks for the comments.

 o draft-ietf-cdni-capacity-insights-extensions-10  - IETF stream
   CDNI Capacity Capability Advertisement Extensions (Proposed
   Standard)
   Token: Francesca Palombini

Liz: This one does have a few Discusses; do we want to discuss these now?

Francesca: I don't think we need to discuss. I definitely agree with everyone
who has raised concerns about this text; I should have seen it. Initially there
were no designated expert guidelines. I expect the authors will make the
change; it's nothing controversial for me. Unless anyone wants to highlight
something, I think we can keep it where it is and wait for the authors to reply.

Paul: This is the one with lots of branding and advertising in the first
section, right?

Francesca: Yes, I saw you had a Discuss about that.

Éric V: On the other hand, it's not so much advertising; it's linked to other
SDOs somehow.

Paul: I think also commercial entities, right? I wondered if it came up during
the WG time or whether everyone just read past it.

Francesca: They are collaborating a lot with the SVTA. That's why they refer to
it in the introduction.

Zahed: I don't feel it's a lot of advertising going on, just that this work is
related to the SVTA.

John: I did my review after you made your comment, Paul, and I tried to imagine
reading that without any of the references to the other industry groups and it
didn't seem as clear. I think this has some practical use.

Francesca: They're trying to motivate the need for this document. I'm happy to
work with you, Paul, and the authors to see if there is anything superfluous.

Paul: Thanks.

Liz: Sounds like this one is revised I-D Needed?

Francesca: Definitely, yes.

Liz: Okay. This one stays in IESG Evaluation::Revised I-D Needed.

 o draft-ietf-suit-firmware-encryption-21  - IETF stream
   Encrypted Payloads in SUIT Manifests (Proposed Standard)
   Token: Deb Cooley

Liz: We have a Discuss here; do we need to discuss this today?

Deb: I'd like to wait for the authors to respond to the comments. I do think it
needs a revised I-D.

Liz: Okay, so this one stays in IESG Evaluation::Revised I-D Needed. And Deb, a
heads up for you; when it eventually gets to approval, there is a downref to
9053, so we'll need to know if that should be added to the downref registry.

Deb: Okay, thanks.

 o draft-ietf-pce-stateful-pce-vendor-12  - IETF stream
   Conveying Vendor-Specific Information in the Path Computation
   Element (PCE) Communication Protocol (PCEP) extensions for Stateful
   PCE. (Proposed Standard)
   Token: Roman Danyliw

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

Roman: Thanks for everyone's review. And thank you for some of the particular
text suggestions made. Can we mark this revised I-D needed?

Liz: No problem, so this is Approved, Announcement to be Sent::Revised I-D
Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 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

 NONE

3.4.2 Returning items

 NONE

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

 NONE

4.1.2 Proposed for approval

 o Update to IANA Considerations (ianabis)

Liz: This will be in the GEN Area with Murray as AD. Does anyone have any
objections to the creation of this WG? We had a block earlier, but it looks
like that's been resolved.

Murray: I'm curious what Zahed's comment was. Which documents are you referring
to?

Zahed: Basically the WG will come up with a new kind of text requirements for
DEs, and all the to-dos this group has. At some point this will be executed on
future drafts; but what impacts does it have on previous drafts? Will this WG
be talking about what's happening with already approved documents, or will
there be no impact?

Murray: the only intention is to update 8126 with more modern advice. That's
the only document we're planning to change and it shouldn't retroactively
affect anything.

Zahed: Okay. That's basically what I wanted to know; it wasn't clear in the
charter.

Murray: I don't think we've ever enacted a BCP update that affects already
approved documents, so I don't think we need to say it, but I'm happy to go
with consensus if others think we should.

Zahed: I don't have a strong opinion, I just wanted to know.

Murray: Okay. Mahesh isn't here; I was going to ask if he's happy. I replied to
his email and never heard anything further, so I'll assume that's settled. You
can create this, but I don't have chairs yet. I'm willing to chair it after
I've stepped down from the IESG, but I need someone to take it over first.
There's no urgency to get it done, so it's fine if that's what ends up
happening.

Liz: Do you want us to go ahead and send the WG creation announcements or do
you want us to wait a little bit?

Roman: We can't send the announcements without naming chairs.

Murray: Right, yeah. Let's hold this until I find a first chair, and then Orie
can add me as a second chair on my way out.

Liz: Okay, so this does have approval but we'll wait for instructions from you,
Murray, when it's ready to go.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o Routing Over Low power and Lossy networks (roll)

Liz: This is in the Routing area, with John as AD. There are no blocking
comments, so is this ready to go for external review? Or is external review not
needed?

John: My view is that external review was not needed, and nobody objected, so
I'm going to stick with that.

Éric V: Please read my comments; the charter includes WGs that are concluded.

John: That's fixed now. I think it's completely noncontroversial to take out
concluded WGs; if we start adding new ones, we may need to send it for external
review. I emailed the chairs to ask what they think and I want to leave a
little time for them to respond. Other than that, I think it's ready.

Liz: Okay, so this is approved without external review, but we'll wait for you
to let us know when it's ready to announce.

 o Source Packet Routing in Networking (spring)

Liz: This is in the Routing area and Jim is AD; we do have quite a few blocking
comments here. Do we want to discuss these now?

Jim: I think we probably should. One thing that's unclear to me is that a lot
of these blocks get removed if I get them to remove that one offending line out
of the charter. I wanted to get thoughts on that. Bear in mind, this recharter
was really done in response to the SRV6OPS; I promised we'd recharter to make
sure it was aligned with that, which it does. The chairs wanted to do this
experiment where they try to make it more difficult in the WG to adopt work
that's just getting +1s on the mailing list. We thought this was fine to use a
wiki because my stance was the chairs are welcome to run the WG however they
want as long as the work coming through is within charter. This text seems to
have started a bit of a firestorm. I don't know if just removing that works or
whether we need to add something to the charter, or what's the best way forward.

Paul: I'd ballot no objection if you just removed that one sentence.

Roman: I'd continue to block even if you remove that sentence. My concern is
that I don't understand what's in scope or out of scope. The way I currently
read the charter, it defines what spring is, makes some reference to the other
WGs, and then is silent on what it does. I don't know when to close the WG, how
to judge whether it's in scope beyond some pattern matching if it uses the word
spring. Then I have the architectural question as well.

Jim: I think your comments were different from the others. What I was trying to
do was clean up the easy ones first, which is getting rid of that sentence that
seems to clear Paul and I think Gunter as well.

Gunter: Yes. Removed or better defined.

Jim: Then once I've gotten rid of those, I can start looking at yours, Roman. I
think that's probably the way forward. Does that make sense?

Éric V: My block is very similar to Roman's. If you clear Roman's I think
you'll be clearing mine as well.

Roman: That makes sense to me, Jim.

John: Just an observation; Roman, you said you don't understand the scope or
when to close the group. I suspect the answer of when to close the group is
going to be never. Spring is a new data plane that the IETF maintains; we can
debate whether it is or isn't, but it has the characteristics of being another
data plane. Just like we wouldn't close 6man, I don't think we'd probably ever
close spring. We should keep that in mind when considering the charter.

Jim: There's a lot of work they're still doing. When I spoke to the chairs,
they felt like it was a lot of work to maintain milestones on work they've
already adopted into the WG. They want to use their wiki to manage that work,
and I'm fine with that. The text in the charter hasn't changed that much from
the previous charter; they haven't added anything. They've taken a bunch of
stuff away in an attempt to clean up the charter. It's not asking for new
stuff, but they may have gone a bit overboard in removing stuff. I would point
out there's nothing new being added.

Roman: My finesse is correct; they removed the limited bounds that were there,
so they've given themselves even more flexibility as I would read. In a
chartering conversation it could be good or bad; I'm kind of arguing that it
needs some bounding.

Jim: That's a conversation I'll have with them. If they need to put some text
back I don't think they'll have an issue with that. I'll clean up the other
stuff first so we can see what we have left.

Liz: Okay, so this will stay where it is for now, and Jim, we'll wait to hear
from you when this is ready to come back on another telechat.

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

John: Their whole session was in executive session [this week]. I saw they
reappointed Warren, which is great. I guess we'll find out as they announce
their appointments.

Roman: There's a whole lot of appointments that need to be happening, and
that's the process we're going through right now.

6. Management issues

6.1 IANA JSON Web Token Claims Registry (Deb Cooley)

Liz: Deb would like to make a change to the DEs on this registry, to remove
John and add Filip and Nat. Any objections to making this change? I'm not
hearing any objections, so this is approved and we will send an official note
to IANA.

6.2 Adding DEs to the IPN Allocator registry (Erik Kline)

Liz: Erik would like to add Ed Birrane and Rick Taylor as DEs for this
registry. Any objections to naming these folks? I'm not hearing any objections,
so this is approved and we will send an official note to IANA.

6.3 [IANA #1394753] Designated experts for RFC 9669 (BPF Instruction Set
Architecture (ISA)) (IANA)

Liz: This is the management issue to assign this task to Erik K; and we have
some names to approve at the end of the call.

6.4 [IANA #1394691] Designated experts for RFC 9666 (Area Proxy for IS-IS)
(IANA)

Liz: This is assigning the action item to Gunter to find DEs for this registry.

6.5 IESG Statement on the "IESG approval" allocation policy [IANA #1397447]
(John Scudder)

John: There's one edit I was hoping to make before the meeting and I didnt get
to it. Because of Francesca's comment I added this thing about 7120bis. Having
seen Amanda's followup, I think we should also cite the 8126bis efforts; it
makes sense to roll this into that document. I'd want to do that little update.
I'll also note that she basically said no objection to the statement. The
substance of her email was that it's weird to put this in 7120bis. I don't
think I saw any stop the presses from any of you, so I'd like to propose this
is agreed?

Roman: I was going to propose a stop the presses. I'm trying to remember, why
can't we just handle this in IANABIS? What's the pressure to put this out?

John: We could do it in 8126bis. Basically this was typed on the fly during our
meeting when we had an IESG approval code point. My sense of the room was that
it would make sense to do this as a temporary allocation, which will give us a
little rope to tell the applicant to come back with a spec. If I remember
correctly, the situation was the applicant came to us and said give me a code
point, here's an IOU for a spec.  Normally I would not do that with something
from another registry, so my preference would have been to do that as a
temporary allocation which gives the applicant plenty of time to pull together
their spec. There were several people in the room at the time who said we have
no history of doing temporary allocations with IESG approval and we don't even
know if we can do that, let's not invent this as we go. Generally, it's like
the anecdote about the farmer and the leaky roof. Hey farmer, why don't you fix
your leaky roof? Well, when it's not raining it's as good as anyone's, and when
it's raining, it's too wet to work. So my concern is that right now it's not
raining; we could fix the roof, or we could wait until the IESG has another
thing they'd like to do as a temporary allocation -- and that might never
happen. It doesn't really affect me anyway because I'm rotating out in a few
months so if people think it's not important enough to publish, that's fine. I
just don't know when 8126bis is actually going to be published, but I don't
think it's going to be soon.

Roman: What you're saying in terms of documenting process makes sense to me, if
we didnt have the WG. we were in the position of not knowing what to do and
what the process was, we're going to invent the process, and then we're going
to have a new WG to do it in. It seems like having the community consensus
process would be better. I appreciate all the work you did on this and it's
fabulous, but given that we have the WG, it might be worth just taking the risk
that we'll wait until a durable fix with community consensus.

Francesca: I totally agree with the content. I was also wondering about the
process, if this is the right way to handle this. I also think we shouldn't be
so restrictive with IESG statements. When you add the text about IANABIS and
revising RFCs, that's going to be the word of law. I'm totally in favor of also
publishing this IESG statement because who knows how long that will take and I
don't see any harm in doing more statements to let people know what the IESG
thinks. Count me in favor.

Éric V: John, thank you for taking the case. It was based on an IP protocol
number for Homa that we discussed on the Friday. Thank you for the followup. It
may not happen; I think it should be in 7120bis but like Franesca, we can
publish it as a statement if you want. It's ready, so why not send it? But we
need to keep it for IANABIS.

John: I hear a Discuss from Roman, a Yes from Francesca, and some No
Objections. Based on that I'd say we're not going forward.

Francesca: I also want to say, I haven't read Amanda's email in full. I'm
trusting you that her email is basically a NoObj. Maybe someone from IANA can
speak up.

Sabrina: Just to confirm, yes. We don't have any concerns about publishing the
statement but we do have some clarifying questions. It would be good if we
could get some guidance on how to handle this in the future. In terms of this,
we don't have an issue with publishing it at this time. To Eric's point, with
the recent request we weren't sure what to do there.

Roman: John, you were asking about the way ahead. If everyone else feels it
would be helpful to put this out there, I'll yield and just ask that we clarify
the note at the bottom and also mention that this may be revised by the future
WG but we feel the need to clarify where we are in place. Some weasel words
like that, in addition to whatever IANA wants as clarification.

Zahed: I was going to say something similar. I'm fine with putting it out, but
are we telling this new WG that this is what they should write in the bis? If
that's it, then we have an issue. The WG  can decide something totally
different. If we can say we have no intention of influencing the WG, then I'm
fine with it. We'd also need to say how the optics look like. I don't want to
say the IESG was telling the WG what to write in a bis document.

John: Formally speaking we do not have the authority to tell them what to
write. This is something we're offering to the WG for consideration, which the
WG can either carry forward or decide not to carry forward. Whatever RFC
eventually comes out of that WG supersedes whatever we write in a statement,
because that will be a consensus document. I think that's all captured in
existing process; maybe whatever that final paragraph gets revised to can give
you some additional comfort about it.

Zahed: I agree with everything you said, but people also push on the process
and point out when they think the IESG is misusing the process. I just want to
be clear on our intentions.

John: When I read that last sentence, it looks to me like it already reads what
you said; if it says something about the IANABIS wg isntead of 7120bis. Would
that cover the concern you have? It seems to me that it should.

Zahed: It should. What you should make clear is that if this bis is in progress
and we know about it, what's our intention to send the IESG statement. That
should do.

John: I think what I'm hearing is we go ahead with this, rewrite the final
paragraph. Roman, do you want to propose a rewrite of that paragraph, or should
I?

Roman: Would you mind taking the first stab at it?

John: Sure. Will do.

Liz: We'll wait to hear more details on that, thanks.

6.6 [IANA #1384918] renewing early allocations for
draft-ietf-ippm-ioam-data-integrity (IANA)

Liz: This is one of Warren's, and he's not on the call with us today. This does
expire in a couple of days so we need to make a decision. Any objection to
approving this early allocation renewal?

Éric V: Has anyone checked whether this draft is still active?

Sabrina: I can confirm that Warren did check with one of the authors and they
said it is progressing. I think they're hoping the document will be published
by the end of the year.

Éric V: Okay, perfect.

Liz: I'm not hearing any objections to approving this, so we can call this
approved and send that official note to IANA.

6.7 [IANA #1384950] renewing early allocation for
draft-ietf-bess-mvpn-evpn-sr-p2mp (IANA)

Liz: This is another early allocation renewal, and this is one of Gunter's.

Gunter: One of the requirements of this WG is to have multiple implementations
before it goes on. Both the chairs and I have said we should renew these code
points.

Liz: Any objection? Okay, we'll call this approved and send that official note
to IANA.

6.8 Important Dates for IETF 124 (Secretariat)

Liz: These are the same as usual except the final two have been pushed back a
little more because they were originally going to fall on US Thanksgiving and
right before Christmas, and since a person does actually have to push a few
buttons for those we've moved them a bit later. Also, now that we're opening
registration earlier, the registration opening date will probably change -- but
we don't yet know what the schedule will be for those, so we'll just change
that manually later. Any comments or concerns? Okay, hearing none, so we'll go
ahead and get those important dates published.

6.9 [IANA #1400018] Management Item: Acceptance of media type registrations
from Trusted Computing Group (TCG) (IANA)

Liz: Murray, I think you were looking into this one?

Murray: For people who weren't following the threads, TCG thinks they have a
liaison relationship to us. We do not have an official one back to them, but
TEEP is chartered to interact with the TCG on a regular basis.

Roman: TEEP has it in their charter, RATS has several documents that reference
specs normatively coming out of it, and NIA (?) in the past had some TCG
documents.

Murray: There's ample evidence to suggest this is legitimate and not someone
working out of their basement. I suggest this is approvable.

Roman: I concur.

Liz: As usual, there are two questions in here; 1, should IANA approve this
request, and 2, should they be added to the list of standards-related
organizations that have registered media types in the standards tree list. Are
we saying yes to both of those?

Murray: As long as the first step includes sending it through the DEs, yes.

Roman: I concur with that too.

Liz: Great, so we will send that official note to IANA.

6.10 De-assignment IANA port based on draft-boucadair-netconf-port-numbers
(Zahed Sarker)

Zahed: Mohamed wrote a draft saying we're going to deallocate some of the ports
that have been assigned to a particular registry. Then IANA responded saying
you don't have to write a draft, the ADs and IESG can just allow it. I was
thinking, if we have any kind of procedure of how to do that? I don't know if
anyone has looked into this netconf-port-numbers draft. There's a netconf port
number allocation registry with a bunch of entries with no use. So we can just
unassign them with IESG approval. Does anyone see a problem or a process
violation?

Murray: Is that document going to be published as an RFC? I haven't looked at
it.

Zahed: IANA's response was that they don't need the document at all.

Roman: I think there are 2 questions; do we need to, and do we want to?

Murray: If we do this without a document, it looks like the IESG decided to do
it ourselves. If we do publish it, then it was a consensus decision.

Roman: I'm exactly where you are, Murray.

Zahed: I don't really care.

Murray: Zahed, to turn this question abc to you; how appeal-proof do you want
this decision to be?

Zahed: Nobody is using the entries there, so it might be a waste of time. If we
approve it, IANA will free those up and put a note about what happened. That
could just do.

Murray: I'm fine with us doing whatever you decide, I'm just trying to give you
some suggestions about how to decide.

Zahed: Anyone else have any comments? I'll be looking at whether anyone has
deployed anything on those port numbers, but I have no way of getting a 100%
accurate answer to that.

Roman: Talking through the process concern, we had previously had a community
consensus action to do this allocation and now we're saying with IESG fiat, we
can reverse that community consensus to have these allocations.

Orie: Don't do that.

Roman: Personally, I think a document would be better.

Murray: I'll give you one last anecdote. When I came in, there was a suggestion
I inherited from Alexey to deallocate a port. I asked the community if people
wanted us to do it and I was roundly slapped and told I was nuts. So I would
definitely do the document if I were you.

Zahed: Okay, that's a solid direction. Does anyone from IANA want to add
anything?

Sabrina: Ordinarily to release or change registrations made by an RFC, we'd
ideally want another RFC to do that. In this case, I believe the RFC 6262
didn't tell us to actually register the UDP port. I think that's why we
suggested we could just ask an AD to sign off on it and we could list it as
reserved. That's our current practice, if we only assigned a TCP port we'd mark
the UDP as reserved. I believe the other two registrations were changed to
Historic back in 2012 but at the time we didn't make any changes to those. I'm
not sure exactly what happened then. If it would help to consult with the port
experts we can also do that.

Zahed: I wanted to know how the port was allocated. But to be sure, I'll ask if
anyone has deployed it and if there's community consensus to deregister this.
I'd like to have consensus and then we can escape all the other questions. I'll
say let's go ahead and work on the draft to publish an RFC for it. That's my
takeaway.

6.11 Next steps on DIEM and DEEPSPACE (Éric Vyncke)

Éric V: I'd love to talk about these two BOFs which may go forward. DIEM
currently has a narrow charter, but it's typically not in INT. I can help the
creation of the WG with my previous contacts and context, but right now the
chartering process needs to be done by the final AD, not me. I think it should
be either SEC or ART; sorry to pass the hot potato. If we could have a
volunteer AD today, or a process to select one, that would be cool.

Paul: I have some issues with whether this can actually move forward or not.
From what I can tell, there have been two BOFs, both with a complete split in
the room of what should be covered in a charter. I'm a little surprised it's
now marching on with an apparently revised charter that must clearly not
include half of the room, and continue to start a WG.

Éric V: I understand the confusion. There was a small use case, the ICRC thing,
and a much broader one. The charter right now is basically just the ICRC one.

Paul: But even that case was not really clear. Sure, there was a discussion
about medical vs journalism, but even the ICRC thing itself had complete
un-clarity and a split of 50/50 whether this should be physical assets or data
assets, and is a router data or physical, and is a database data or physical,
and is a hard disk data or physical. There seemed to be complete non-agreement
on everything.

Éric V: Have you read the discussion on the mailing list? Not everyone is fully
aligned on the charter, but I think it's converging.

Paul: Wouldn't the process normally be to have a third BOF?

Éric V: No no, we cannot. Suresh checked and we can only have two. No way.

Paul: That's a little weird to me. The second BOF gave no way out of the
fundamental problem, so how can you have a WG?

Éric V: Because we restrict the problem. If there's an objection to DIEM
continuing, let's stop the chartering process.

Roman: The way ahead would be one of potentially two things. You had your two
BOFs and now you need to work out consensus for a charter text on the mailing
list, or you could make a radical departure to say we learned a lot from the
BOF, we've now rescoped it to something else, and we want to start a whole new
process around it.

Orie: To Paul's point, after the BOF, the discussion on the list did seem to
address the BOF questions on the digital or analog topic for assets. They
included new text in the charter to account for that. The narrowing piece of
this is to the inspection case where the asset isn' aware that its emblem is
being inspected. They've narrowed descriptively around the approach, but they
haven't narrowed specifically to eliminate one of these use cases like press or
humanitarian relief. They haven't narrowed to distinguish between digital or
analog/physical assets. To the question of area, to me this seems similar to
WIMSE in the beginning. If WIMSE was going to be doing fundamentally new
security work, it should have maybe been in the security area. If it's just
using off the shelf building blocks that have been built in other parts of th
eIETF and assembling them into an application protocol without making major
security changes to them, it does seem more properly ART than SEC. I have the
same concerns as you, Paul, in terms of continuing with the numbers we had at
the end of the BOF. My only other comment is that this is another WG looking at
this pseudo-three party model scenario without picking a specific technology.
One way to handle the fact they've been through 2 bofs is good news, you're not
inventing any new security work, there are WGs that maintain the security
building blocks you're intending to use and you could take this as a use case
to one of those groups. I don't know which of those paths is recommended for
this charter, but as the ART person speaking, I'm happy to entertain the idea
of this being in the ART area if that's where folks think it belongs.

Éric V: So Orie, can we say that you have the ball right now, with my support?

Orie: I'll take it, but I'd also like to understand how the rest of the IESG
thinks we should handle this; there have been 2 BOFs, the charter is in this
state, and there's silence on the list. I can kick the list but in what
direction should I be prodding them to think about proceeding?

Francesca: You kick the list, you get them to react to a charter, and then you
bring it to the IESG. then discuss it more from there. If the proponents and
the people who are involved are happy with the text, then it's internal review,
IETF wide review, and IESG again.

Paul: Would it be possible that a WG would pick up both tracks and see if they
could make something work? Looking at both digital and analog assets, and maybe
one of those two legs will fail, but then you've got everybody in the room and
some kind of consensus for working on both of those things.

Orie: Do you mean a new WG, or an existing WG?

Paul: One new DIEM WG that would work on both.

Orie: I think the way the charter is framed right now is to support that. Both
digital and analog assets are in scope, and the only constraint on the use case
is that the asset can't be aware of its emblem being inspected. An interactive
authentication model wouldn't work.

Paul: So in a way it's pretty similar to DULT; we basically have a tracker
that's broadcasting things.

Roman: I think one of the critical differences between this and DULT is that
before we chartered, we defined the architecture. When we chartered DULT, we
had most of the ecosystem of implementers on board.

Éric V: That's a big difference. So Orie, you are up for probing the list?

Orie: I'll take the draft charter from here and come back to the list. If it
seems like there's agreement within the list and proponents that it's ready for
wider review, we can proceed. I agree with your comment, Roman, on implementers
and ecosystem being in the room for this. At this point, if they're not on the
list and they're not part of the wider review piece, I'm not sure how we would
address that point.

Éric V: Okay. Let's go to the last one, where the implementers point can also
apply here; DEEPSPACE. This one could stay in INT, even if just for parity with
DTN. The name needs to be changed. I would suggest that I try to find, with the
help of the list, a nice acronym that's less ambiguous as DEEPSPACE and start
the chartering process as AD.

Paul: Before we get to that part, it was unclear to me being in the BOF whether
there was agreement on this end to end principle. It seemed that all the
manufacturers/deployers of satellite things dint really see a use for end to
end. It seems like some people in the IETF are like, end to end is cool, let's
do this in space. I didn't feel the BOF actually addressed that question, that
this is something someone wants. I think that would need to be answered before
we start chartering a WG.

Éric V: So you want something about end to end in the charter so we know the
scope?

Paul: I think there was some question about the architecture, whether it would
be completely end to end or whether there would be some use of the existing
bundle protocol that would then get attached to an IP layer protocol.

Éric V: I was hoping this one would be easy. I see time is flying; the appeal
is more important than this right now. I'll bring this back to the next formal,
if everyone agrees. And think about an acronym for the WG, meanwhile. Thank you.

6.12 Designated experts for RFC 9669 (Erik Kline)

Liz: Erik has identified David Vernet and Alexeiy Starovoitov as designated
experts for this registry. Any objection to approving them? I'm not hearing any
objection, so they are approved and we'll send the official note to IANA.

6.13 Executive Session: Changes to the IANA CBOR Tags Registry (Orie Steele)

Discussed in executive session with IESG, Secretariat, and Sabrina Tanamal
(IANA Liaison).

6.14 Executive Session: Appeal Discussion (Roman Danyliw)

Discussed in executive session with IESG and Secretariat.

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