Narrative Minutes interim-2024-iesg-08: Thu 14:00
narrative-minutes-interim-2024-iesg-08-202404041400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2024-04-04 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 / 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
Mahesh Jethanandani (Arrcus) / Operations and Management Area
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Tommy Pauly (Apple) / IAB Chair
Zaheduzzaman (Zahed) Sarker (Nokia) / Web and Internet Transport Area
John Scudder (Juniper) / Routing Area
Orie Steele (Transmute) / Applications and Real-Time Area
Sabrina Tanamal (ICANN) / IANA Liaison
Gunter Van de Velde (Nokia) / Routing Area
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

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

OBSERVERS
---------------------------------
Richard Barnes
Mike Jones
Alexandr Viktor Marek Stepanovic
Marco Tiloca
Greg Wood

1.2 Bash the agenda

1.3 Approval of the minutes of past telechats

Liz: We have minutes from two telechats from before IETF 119 that need to be
approved today. First up: February 29. Does anyone have an objection to the
minutes of the February 29 IESG Teleconference being approved? I'm hearing no
objection.

Does anyone have an objection to the narrative minutes from February 29 being
approved? I'm hearing no objection.

Second: March 7. Does anyone have an objection to the minutes of the March 7
IESG Teleconference being approved? I'm hearing no objection.

Does anyone have an objection to the narrative minutes from March 7 being
approved? No objection there either -- we will get all of those minutes posted
in the Datatracker.

1.4 List of remaining action items from last telechat

   OUTSTANDING TASKS

        Last updated: March 18, 2024

   * DESIGNATED EXPERTS NEEDED

     o Murray Kucherawy to find designated experts for RFC 9422 (SMTP Server
       Limits) [IANA #1358457].
     o Murray Kucherawy to find designated experts for RFC 9530 (Digest
       Fields) [IANA #1359278].
     o Murray Kucherawy to find designated experts for RFC 9535 (JSONPath:
       Query Expressions for JSON)[IANA #1359744].
     o Murray Kucherawy to find designated experts for
     RFC-ietf-calext-jscontact-16
       (JSContact Properties)[IANA #1361734]

Liz: Murray, four of these are for you. Just to make sure you have these on
your radar.

Murray: Can we change the calext-jscontact one to Orie? He's now the AD for
that document.

Liz: Sure; we can update that and assign it to Orie.

     o Deb Cooley to find one more designated expert for "SMI Security for PKIX
     Module
       Identifier" registry of the group "Structure of Management Information
       (SMI) Numbers (MIB Module Registrations)"

Liz: This is a new item for Deb, and we already have a name, so we'll mark this
as provisionally done and do the approval as a management item.

     o Paul Wouters to find designated experts for RFC 7170 (TEAP TLV Types)
       [IANA #1361724]

Liz: Paul, this is a new one for you as well.

Paul: I thought there were already names for it?

Liz: IANA suggested two names; if you want to go ahead and approve them as the
experts today, we can do that when we get to the management items.

Paul: I already checked with them, so let's do that.

Liz: We'll mark this one as provisionally done then.

   * OPEN ACTION ITEMS

     o Lars Eggert and Warren Kumari to 1) draft a revision of RFC 4858,
       2) draft a revised IESG Statement on Document Shepherds (original
       statement October 2010), and 3) update the WG Chairs wiki to point
       to the new IESG Statement.

Liz: We need a new name instead of Lars; does anyone want to work on this?

Roman: You can add me. I'll talk to Warren and Lars as well. I don't remember
what we wanted to do here, given that we decided this so long ago. Why don't we
huddle and decide whether we're really still doing something.

Liz: I'll mark this in progress.

     o Jay Daley, Dhruv Dhody, Éric Vyncke, Orie Steele, Mahesh
       Jethanandani, Gunter Van de Velde to form a design team to gather
       community feedback about meeting in China.

Roman: For everyone listed here, you volunteered to be on the design team on
Sunday of 119. There's a Doodle poll coming your way soon to find a time that
accommodates everyone's time zone least badly.

Mahesh: It's been sent out already.

Roman: Oh. I didn't even notice. Awesome.

Liz: Great; so this one is officially in progress.

     o Francesca Palombini to come up with a v2 proposal for trying
       ALLDISPATCH again at IETF 120.

Liz: She's not here today so we'll go ahead and mark this in progress for
Francesca.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-core-oscore-edhoc-10  - IETF stream
   Using Ephemeral Diffie-Hellman Over COSE (EDHOC) with the
   Constrained Application Protocol (CoAP) and Object Security for
   Constrained RESTful Environments (OSCORE) (Proposed Standard)
   Token: Paul Wouters

Liz: We have no Discusses in the tracker, so unless there's an objection now,
it looks like this document is approved.

Paul: Just put it in AD Followup, please. There may be a new revision but I'm
not sure.

 o draft-ietf-pce-segment-routing-ipv6-24  - IETF stream
   Path Computation Element Communication Protocol (PCEP) Extensions
   for Segment Routing leveraging the IPv6 Data-plane (Proposed
   Standard)
   Token: John Scudder

Liz: We have no Discusses in the tracker, so unless there's an objection now,
it looks like this document is approved.

John: Thanks for all your reviews. It looks like at least Éric has some
outstanding comments, so let's put it in AD Followup. Thank you.

Liz: Okay, this is Approved, Announcement to be Sent, AD Followup and you can
let us know when it's ready to go.

 o draft-ietf-sframe-enc-07  - IETF stream
   Secure Frame (SFrame) (Proposed Standard)
   Token: Murray Kucherawy

Liz: We do have a Discuss here; do we want to discuss that today?

Murray: Briefly. Paul, there has been an answer; was that enough to satisfy
your points?

Paul: I haven't seen it yet. But I'm assuming it's not going to be a very big
problem.

Murray: That's fine. I'll follow up with you over Slack. Oh, and Richard is
here.

Richard Barnes: I don't know if I'm allowed to speak, but the tl;dr is that the
first and third of your issues were raised in other IESG comments so we already
have PRs on them. The tag thing is just media people being super sensitive
about bandwidth, so the idea there was to give them some options but put
appropriate guardrails around them.

Paul: Okay. We had something similar in ipsec, where there were different tag
sizes and then everybody abandoned them to just use the largest tag size.

Richard: There are specific quantitative issues here and some analysis in the
document I sent you a link to. It's definitely something the WG discussed.

Paul: Okay, that's fine. I'll clear my Discuss.

Murray: AD Followup then, until Paul clears.

Liz: Is this going to require a Revised I-D?

Murray: Yes, thanks.

Liz: Okay, we'll leave this in IESG Evaluation and you can let us know when
that's ready.

[Later in the telechat:]

Murray: Can we go back to the sframe document? Paul has cleared his Discuss.
Can you make that Approved, Revised I-D Needed?

Liz: Sure. There are now no Discusses on this document, so we can mark this
Approved, Announcement to be Sent, Revised I-D Needed. Thanks.

 o draft-ietf-jmap-sieve-20  - IETF stream
   JMAP for Sieve Scripts (Proposed Standard)
   Token: Murray Kucherawy

Liz: We have no Discusses in the tracker, so unless there's an objection now,
it looks like this document is approved.

Murray: Can we go to Approved, AD Followup?

Liz: We sure can. This will be in Approved, Announcement to be Sent, AD
Followup and you can let us know when it's ready.

 o draft-ietf-extra-imap-inprogress-05  - IETF stream
   IMAP4 Response Code for Command Progress Notifications. (Proposed
   Standard)
   Token: Murray Kucherawy

Liz: We have no Discusses in the tracker, so unless there's an objection now,
it looks like this document is approved.

Murray: Same with this one, please. Approved with AD Followup.

 o draft-ietf-opsawg-mud-acceptable-urls-11  - IETF stream
   Authorized update to MUD URLs (Proposed Standard)
   Token: Mahesh Jethanandani

Liz: We have a couple of Discusses for this document; do we want to discuss
these today?

Paul: I didn't Discuss, I abstained, but I think it might be worth discussing
something. It seems like some of these MUD related things are always borderline
on what we think we should do with them and they're stacking up into very
unspecified protocol things. I'm not sure what to do going forward. I was
thinking of holding my Discuss to let people override me but I decided to
abstain. I think there's some significant issues, like a lot of reputation
based things going on and a lot of firmware splitting where part of the
firmware is a MUD file but part of it is not, and it gets updated but not with
the firmware and then they get out of sync, and it gets quite messy. I'm not
sure that is fixable. That's why I abstained.

Mahesh: I tend to agree with you. This is another of those documents I
inherited. It's problematic to say the least. It's the same set of authors that
come up with these documents. I guess I could take it back to the authors and
try to rework it and address all these comments and see if it's fixable or not.

Paul: That's fair. I'm not blaming you personally.

Mahesh: Not taken either.

Deb: I think there are a lot of things that need to be fixed. There's no reason
not to send it back and let them work on it.

Paul: It's built on the assumption that having a firmware update and a mud
configuration URL being different things. That's not a fundamentally broken
design?

Deb: It's confusing. It needs to be clarified and simplified. I think they just
want to offer so many options for so many manufacturers. I was going to say
it's muddy but maybe that's a bad choice of words. It does need to be cleaned
up at least. There are errors in it.

Mahesh: Let's definitely mark it as Revised I-D Needed and I'll discuss with
the authors how they want to proceed.

Liz: So this will stay in IESG Evaluation, Revised I-D Needed.

 o draft-ietf-add-resolver-info-12  - IETF stream
   DNS Resolver Information (Proposed Standard)
   Token: Éric Vyncke

Liz: We have a couple of Discusses for this document; do we want to discuss
these today?

Éric V: I'm not sure. We can. First of all, thank you for the extensive and
very detailed Discuss points.

Warren: I did feel a little bad when I got towards the end and realized I'd
started sounding ranty. I think one of the issues with the document is the
people who are working on it seem to have a set of context in their heads and
that isn't reflected in the document. I haven't fully finished reading all of
the replies I got, but a lot of them say 'that's because this specific thing is
in the charter' and that's all fine and good, but--

Paul: No it's kind of not. The charter has this big red flag every time we
discuss an ADD document, that the client policy is out of scope because nobody
could agree about the client policy. Whenever there's a security item, like,
the server does something or the protocol defines something. If you say
wouldn't this be a security issue if the client blindly trusts this? The
response is that the client policy is out of scope. So that makes this really
problematic.

Warren: I wasn't speaking about that particular part of the charter, more like
I said what's the purpose of this document? And they said it's to answer item
number 7 in the charter. So oh, okay, well if you put that in the document I
would at least understand the purpose. So I agree, the client security issues
being out of scope is a major issue. I was talking specifically about the
purpose of this document. What's it supposed to do, why does my client need to
understand that the resolver supports QNAME minimization? It should be
invisible to me. And I think a lot of that context is stuff that people within
ADD know but haven't necessarily answered it.

Paul: And then that's the weird thing of the document too. The two things they
are conveying are kind of not important to the resolver end point. A regular
end user is not going to make different decisions based on the outcome of those
two things. And then this whole infrastructure is put into place for like yeah,
we will probably maybe add actually useful things later on. It's almost like
aren't you too soon with this document if you don't really have a use case for
it?

Warren: I think the eventual hope/plan is my client OS will go I want privacy,
so I will choose a resolver that does QNAME minimization over one that does
extended error. But there are a lot of open questions here.

Paul: They're not going to probe the network for the randomly assigned
Starbucks name server and whether they do privacy. That's where this whole
client policy comes in. for the record, I was not an AD at the time but I think
I was the only voice at the time that said a charter without the client policy
should not form a working group, and now with every document we see this
problem. But anyway, I'll either clear my Discuss or abstain or something.

Warren: I do think it would be very useful if this document in particular had
had some more Last Calls with DNSOP or something similar. Why these particular
capabilities…

Éric V: The DNS Directorate did a review on it. I don't remember whether they
forwarded the Last Call to DNSOP.

John: A lot of us love to hate on use case documents. At least in this
particular case, it really sounds like if they had published a use cases
document, they could have referenced it from this document, and Warren would
have been a lot happier.

Warren: Thank you. I'll reiterate that I really love use case and architecture
documents because it helps people understand how the bits are supposed to fit
together.

Éric V: But in this case, it's maybe useful to add more context and I agree
with you Warren. In this specific document rather than another document it may
be easier.

Roman: I supported the Discusses for exactly this issue. I saw a protocol
mechanism but I didn't recognize who on the client side was twiddling these
configuration settings and what they would do with them. Then on the back side,
why is the server doing that and what are their expectations? Some framing in
this document would have been good to demonstrate why these particular levers
were added irrespective of whether others would be added in the future. Like,
what is the IT department supposed to be doing? What is this thing that the DNS
server is now sending feedback and guidance to computers, where are those
resolvers? There was a conversation about browsers, operating systems…there are
a lot of moving parts.

Paul: it's worse actually because some of the information in that info URL
that's only supposed to be used for debugging is on a web server that is
independent of the DNS server, so if you change the DNS configuration you have
to remember to change the web server documentation too, which nobody will do,
so that information will get immediately out of sync.

Warren: You can provide a list of extended errors that the server can send, but
it's unclear what happens if a server sends additional ones? Is this a strict
list of only the ones that will be allowed? Again, this comes back to what is
the purpose/context of this document.

Paul: And where is the option saying I can do filtering for DNS answers for
malware. What does that mean if you don't have more information? Are these the
Russians filtering for malware?

Éric V: If you go for open DNS, or another public server, you can ask
filtering, right?

Paul: Yes you can ask filtering, but who's doing it? What kind of content
filter is it? Is it someone who will filter out the EFF or just sex? Without
knowing anything of the context, saying yes we will do filtering, the only
thing you signal is if you get DNS errors because of our filtering, you have to
believe that we're doing it because of the filtering. From a security point of
view the DNS client is just you're telling me I should expect DNS protocol and
believe them.

Éric V: How can you trust the reply or any kind of protection, yeah. One
additional point of view; if I'm not mistaken, all the major operating system
vendors do not intend to implement this on the receiving side. So it's kind of
an empty document. What I would suggest to the authors is to at least provide
context. Clearly there's a revised I-D needed, and we can see if the context is
enough for Warren and Paul and then go on. As it's a pretty heavy Discuss and I
agree with many of the points, we may want to put it on a telechat in one or
two months to get more discussion. I don't think I can take this with just
myself and the clearing of the Discusses, it's too specific and too important.

Warren: Thank you. And again, apologies to the authors. I know my tone got a
little ranty.

Éric V: You know the authors. It wasn't a perfect tone, to be honest, but they
are not newcomers and I don't think they were too offended.

Paul: It might also be useful to have a meeting with them.

Éric V: What about an interim? Would that be too much?

Paul: I'd be happy to attend and see what we can do there. I'm not sure if it
has to be a formal interim or just a meeting.

Warren: Some more DNSOP people trying to help frame it might be helpful also.

Éric V: Any input is welcome. So, Revised I-D Needed and expect this document
coming back in a month or two.

 o draft-ietf-cose-typ-header-parameter-04  - IETF stream
   COSE "typ" (type) Header Parameter (Proposed Standard)
   Token: Paul Wouters

Liz: We have no Discusses in the tracker, so unless there's an objection now,
it looks like this document is approved.

Paul: Please put it in AD Followup.

Liz: Okay, so this is Approved, Announcement to be Sent, AD Followup and you
can let us know when it's ready.

 o draft-ietf-extra-imap-list-metadata-05  - IETF stream
   IMAP4 Extension for Returning Mailbox METADATA in Extended LIST
   (Proposed Standard)
   Token: Murray Kucherawy

Liz: We have no Discusses in the tracker, so unless there's an objection now,
it looks like this document is approved.

Murray: Approved, AD Followup, please.

Liz: Okay, so this is Approved, Announcement to be Sent, AD Followup and you
can let us know when it's ready.

 o draft-ietf-lamps-norevavail-03  - IETF stream
   No Revocation Available for X.509 Public Key Certificates (Proposed
   Standard)
   Token: Roman Danyliw

Liz: We do have a Discuss in the tracker; do we need to discuss this today?

Roman: It's up to you, Paul.

Paul: No. I'm assuming Russ will come back and either tell me I'm wrong or fix
it.

Roman: In that case, thank you everyone for the reviews. I think this one will
need a revised I-D at least just to clarify some of the language.

Liz: Okay, this will stay in IESG Evaluation, 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

 o status-change-uplift-eap-akaquote-to-ps-00  - IETF stream
   Proposed Status Change for RFC 9048 (EAP-AKA') from Informational
   to Proposed Standard (None)
   Token: Paul Wouters

Liz: We don't have any Discusses, so unless there's an objection it looks like
this status change is approved.

Sandy: I have a question. When the status change comes through, can the status
be changed separately? I saw the status change mentioned also in
draft-ietf-emu-aka-pfs. Are those two separate things or should the status be
changed when that document comes through?

Paul: The PFS document should also have been resubmitted for Standard already.
It was initially informational. The whole point was that we'd make this one
Standard so that the update could also be Standard.

Sandy: Oh, so they're two separate things. Thank you.

Paul: The other one is still a draft, so it will be fixed before it becomes an
RFC.

Sandy: Understood. Sometimes there's a document that explains the status
change, so sometimes we do a status change when the document is published, but
this sounds like two totally separate things so we can just handle the status
change when it comes through.

Warren: I have a question. I feel like I should know this, but I don't. When we
do a status change like this, do we republish the RFC with a different number
and a new status, or do we just stick something in the Datatracker?

Sandy: The status change means the change happens to the metadata. There are no
changes to the actual document. It doesn't get a new number.

Warren: So it's just in the Datatracker but if you download the RFC it still
shows the old status.

Sandy: Correct.

Warren: Okay, thanks.

Liz: I didn't hear any objections, so it sounds like this status change is
approved. Paul, do you need to add any notes or anything, or is this ready to
go?

Paul: I think it's ready to go. What do people usually use for notes? This is
my first status change.

Cindy: Notes on this kind of thing are actually so rare there isn't even a
substate like AD Followup, so just sending it is the norm.

Paul: Okay, then I'll follow the masses and not have any notes.

Liz: Thanks Cindy. So this one is approved and 'well send the associated
announcements.

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-lsr-dynamic-flooding-17  - IETF stream
   Dynamic Flooding on Dense Graphs (Experimental)
   Token: John Scudder

Liz: We don't have any Discusses, so unless there's an objection it looks like
this document is approved. Okay, this is approved. John, is this ready to go or
does it need anything?

John: Let me do followup just to be sure.

Liz: This will be Approved, Announcement to be Sent, AD Followup and you can
let us know when that's ready.

 o draft-ietf-lsr-isis-fast-flooding-08  - IETF stream
   IS-IS Fast Flooding (Experimental)
   Token: John Scudder

Liz: We do have a Discuss in the tracker; do we need to discuss this today?

John: Yeah, let's use a minute. Zahed, for most of your Discuss I'm just going
to wait for the authors to respond. Am I right in understanding that your
comments on algorithm 2 are mostly, bro, this isn't an algorithm?

Zahed: Yeah. I think as I said in my Discuss, I can just stream the whole thing
with one sentence and what harm does it do? They're putting some guidelines,
which is good, but that's not an algorithm. You can't just call that an
algorithm. I don't know whether this transmission rate reduction is good
enough, or do I need a circuit breaker to stop sending anything to the network?

John: I sent an email response to you just before the meeting, so it's fine if
you haven't read it. Basically, about your what if we just took section 6.3 and
the word algorithm out and just called it a set of guidelines? The WG started
working on this before I was the AD and there was a lot of negotiation around
it, so I think it would be really painful to remove all of that and replace it
with one sentence, as you said. I think it would be a lot easier to wordsmith
around that and make it clear that it's not normative and it's not an algorithm.

Zahed: Something like that would be helpful. There is a depth of information
there that people can use to devise their own algorithm if they want, and that
should be clearly defined. This is another way of doing things.

John: I may be wrong but it's kind of tap dancing around a lot of vendors
saying we've already done this and we're not going to publish our internal
implementation details, but here are some hints.

Zahed: It starts with something that's an abstraction and that's confusing. If
you give me an algorithm and then say it's abstract, that's hard to follow.

John: Okay. Let's see what the authors say but it looks like we have a way
forward on the major pieces. Thank you.

Liz: It sounds like this one might require a revised I-D?

John: Yes.

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

 o draft-ietf-v6ops-dhcp-pd-per-device-08  - IETF stream
   Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large
   Broadcast Networks (Informational)
   Token: Warren Kumari

Liz: We don't have any Discusses, so unless there's an objection now, this one
is approved. Warren, is this ready to go or do you want to add anything?

Warren: I believe it's ready to go. The authors posted a new version with the
comments addressed this morning so it should be ready to ship.

Liz: Okay, then we'll just call this Approved, Announcement to be Sent, and
we'll send the announcement.

 o draft-ietf-extra-imap-uidonly-07  - IETF stream
   IMAP Extension for only using and returning UIDs (Experimental)
   Token: Murray Kucherawy

Liz: We have the consensus as Unknown here, so we'll set this to Yes for you.
We don't have any Discusses, so unless there's an objection now, this one is
approved.

Murray: Approved, AD Followup please.

3.1.2 Returning items

 NONE

3.2 Individual submissions via AD
3.2.1 New items

 o draft-zern-webp-14  - IETF stream
   WebP Image Format (Informational)
   Token: Murray Kucherawy

Liz: We don't have any Discusses, so unless there's an objection now, this one
is approved.

Murray: This one should be Approved, Revised I-D Needed. Thanks everybody for
the look; it changed so much in AUTH48 I just had to bring it back for another
ballot.

Roman: Thank you for being conscientious about bringing it back.

Liz: This is Approved, Announcement to be Sent: Revised I-D Needed, and Murray,
you can let us know when that's ready.

3.2.2 Returning items

 NONE

3.3 Status changes
3.3.1 New items

 NONE

3.3.2 Returning items

 NONE

3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 NONE

3.4.2 Returning items

 NONE

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

 o Mail Maintenance (mailmaint)

Liz: This is in the ART area and Murray is the AD. We have a few blocking
comments; do we want to discuss these now?

Murray: This is the part of the telechat where my luck ran out. There's a
little bit of staleness in this charter; the dispatch piece was created before
we did alldispatch, so I guess we have to rework that. Setting that piece
aside, the part that I'm trying to capture is that we keep getting this steady
over time stream of small documents that are just too small for their own WGs.
you could dispatch them but I would spend all my time AD sponsoring these
things. If I were to create a small WG, even if it never met, the
administrative load is not trivial, but the community of people who would be in
all these WGs is basically the same. I'd have to parallelize their time across
many WGs or serialize the work, and I don't want to do either of those things.
Even if I set aside the dispatch piece and find some way to clean that up, is
the rest of the theory sound to the people who are raising blocks? I'm just
trying to get some kind of path forward.

Roman: I think if the dispatch stuff was cleared up, some of the tone language
was cleared up and the definition of email was cleared up, we could get there.
I do have a scope clarifying question, and stop me here because I didn't just
look it up but I know every dispatch has a different version of this. Doesn't
the current ART dispatch allow for doing small documents?

Murray: It does, but that's a much larger community.

Roman: Let's say the alldispatch experiment fails and we go back to having just
dispatch. There's some judgment call you then need to make with your document
about whether you go to this WG or the normal dispatch?

Murray: Normal dispatch is chartered only to accept work that's little teeny
things like an IANA registration. It's not allowed to develop any protocols. So
I couldn't do it that way unless I changed ART dispatch's charter.

Roman: Is this going to do more protocol work than you would allow with
dispatch? I imagined this was like mail header stuff.

Murray: It's very clear that it's not allowed to touch base email protocols. If
you want to do a small extension to DKIM, this would be the place to do it
without rechartering DKIM in its entirety. It's more than just small
administrative actions like IANA registrations, but it's not huge project work
that would require a giant WG of its own. It's meant to be small things that
need some refinement and the right audience, and it's the same audience over
and over again. It's a little bit bigger than what art dispatch allows but not
a full size WG. in those cases, it's supposed to dispatch to create a full WG.
I can clean that part up.

Roman: Maybe the magic is in the cleanup of what the scope is. For example, you
can't touch base protocols? When I read the charter, I think the charter text
says it's strongly preferred not to but did not preclude it. I think this
charter has some work to do about how big is big and how small is small.

Murray: I can probably clean some of that stuff out. The specific objection was
the work that's being done in emailcore right now, when that group is done and
disbands, we don't want these other things to come in and change that scope. So
anything that's that scale is out of bounds. I can figure out how to take that
up.

Roman: If you have good text on, whether the dispatch text gets improved or you
say dispatch gets done someplace else, but this would be a landing spot, I
think we can land this charter.

Murray: Zahed and Éric, does that clear up yours as well?

Zahed: For me, I think that discussion is good. If you can work on that I can
look at it. My other thing was, what are the deliverables? Documents,
extensions, these kinds of things -- you can clean that up. I support the idea
but the scope should depict what we're expecting out of this WG. I see this as
trying to hold a lot of strings together.

Murray: There isn't a specific set of deliverables to start with. This is meant
to be a stream of stuff that comes in. I can't predict what the next thing is
going to be and there's no way to include that in the charter. Scoping like
Roman was talking about, that's absolutely possible: these things are too big,
these things are too small. But I couldn't tell you a set of deliverables and
then they're done. It's meant to be a standing WG that the area has wanted for
a long time.

Zahed: So this is basically meant to be a long lasting WG for all the things
that come in with a prefix of "email." Then that should be clear in the charter.

Roman: I need help citing the RFC, but if it's not a dispatch WG we don't
charter hypothetical WGs. There's either work to do, and a backlog of short
things we charter for, but we don't typically charter when there's work in the
future.

Éric V: Except if you specifically say there are no milestones in the charter
for a specific reason.

Roman: If there's no work we need to do right now, why now?

Murray: There's something to prime the pump, but there's no endgame.

Roman: My point is, if there are things to prime the pump, let's put those as
starter milestones; realizing at some point those milestones may disappear.
That might help crystallize scope.

Roman: Zahed, is that fine with you?

Zahed: Yes, something like that will help.

Éric V: My major problem was about the scope, not so much the milestones.

Murray: The last thing about the definition of email; can I just refer to the 2
core documents or do you want some other definition?

Éric V: THat's basically my issue with the scope. Obviously it's about SMTP,
IMAP, DKIM, but where do we stop?

Murray: If I were to say something like, if it's transported by SMTP or it fits
within the email format, which is in those 2 documents, then it's in scope. If
it has nothing to do with either of these two things, it's not in scope.

Éric V: So it would cover DKIM, for example?

Murray: DKIM fits within headers, which is covered in the header document, so
yes.

Éric V: Okay. And the same for IMAP, or is that different?

Murray: IMAP reads things that are in that format, so I'd say if I can tie it
to one of those two things then it's in scope. If not, you're in the wrong
place.

Éric V: Whatever the scope is, put it in, and I'll be happy.

Murray: I'll take another run at this. Do I need to bring it around for a new
initial ballot or is it enough to clean this up and move forward from here?

Éric V: I'd prefer to review it.

Roman: I think you can make charter updates and ask us to clear based on it,
but you have the lever to make us look at it by a particular date.

Murray: Okay, thanks. I'll use some discretion and I'll work on this.

Liz: We'll leave this where it is and Murray, you can let us know if you want
to bring it back.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 o A Semantic Definition Format for Data and Interactions of Things (asdf)

Liz: This is one of Francesca's groups, and she's not here but we do have a
couple of blocks. Do you want to discuss this without Francesca?

Roman: I'm holding one of the blocks and this is hard for me to discuss without
Francesca.

John: Same. I think mine is easy to fix anyway.

Liz: So let's leave this where it is and wait for Francesca to get back and
review it with you.

4.2.2 Proposed for approval

 o Multiplexed Application Substrate over QUIC Encryption (masque)

Liz: This is in the WIT area and Zahed is the AD. We have no blocking comments,
so unless there's an objection now, this recharter is approved.

Zahed: Thanks for this. MASQUE will go ahead and do their work.

Liz: Do you need to add anything or is this ready to be announced.

Zahed: It's ready.

Liz: Thank you, then we will go ahead and announce this.

5. IAB news we can use

John: We're losing our liaison to BBF and we don't have a replacement. If
anyone strongly feels we need one, I'm sure the IAB wouldn't mind assistance in
recruiting someone. Various appointments were discussed; the notable one is we
need a new IRTF chair because Colin is stepping down. Again, I expect that if
you have any recruiting ideas they wouldn't mind.

Éric V: The IRTF chair is named by the IAB?

Tommy: Correct.

John: There was some talk about sat-net stuff. There's some interest in setting
up some kind of liaison relationship with CCSDS; I don't know the acronym
expansion but I think it's talking shop with the various national space
agencies. Ed Birrane has been sort of an informal liaison but there's some
interest in having a more formal relationship.

Zahed: That's related to DTN. There was a biweekly meeting with CCSDS when we
were starting DTN, and they have a few RFCs, and so on. It would be beneficial
to have an official liaison but for DTN we already have a chair liaison thing
going on.

John: One more specific piece, the specific work item Alvaro was talking about
is some kind of architectural document either from CCSDS itself or from people
who know about it, talking about architectural considerations for their problem
space. Which sounds to me like it would be a useful document wherever published.

6. Management issues

6.1 [IANA #1361078] Designated experts for RFC 9508 (Information-Centric
Networking (ICN) Ping Protocol Specification) (IANA)

Liz: IANA needs designated experts for this registry but weren't sure who to
assign it to, since this was an IRTF document from the ICNRG RG. Do we have a
volunteer who could find experts for this registry?

Roman: Can someone refresh my memory; CCN is transport adjacent? INT adjacent?
I don't know what that tech is. This looks INT adjacent. Could I ask one of the
INT ADs to pick this up? Or tell me it's not [related].

Éric V: Pass me the ball for now. I'll work with Colin.

Roman: Thanks so much.

Liz: Thanks for volunteering; we'll assign this to you.

6.2 When should IANA be notified about document state changes? (IANA, Tools
Liaisons)

Sabrina: This is just specific to the IANA state change. For us, if we could be
notified of version changes post-IESG evaluation, that would be great.

Roman: I may not understand the issue fully. You're asking as the document
progresses through different states into IESG review, that you get an email?

Sabrina: Yes, but not for every change. Just after IESG evaluation, if there
are changes, we'd like to be notified. I'm not sure if that's possible.

Paul: Changes about the document content, like a text change in AUTH48?

Sabrina: Every time the IANA state changes to Version Changed - Review Needed,
if we could be notified of that, that would be great. Then we can just check
the IC section and make sure nothing has changed since IESG Evaluation before
it gets to approval.

Paul: I thought  you would already get automated emails for that.

Sabrina: Not at this time. If there are changes, we don't know about it until
the document is approved. For example, if we do need to do another expert
review, we want to be able to do that before approval. Between IESG Evaluation
and approval stage.

Paul: Okay, I understand.

Éric V: It's public information anyway, right, so it's just a tooling issue to
send you an email?

Paul: There's no formal state change in the Datatracker for this.

Éric V: Each time you submit a new I-D you trigger it. We receive triggers so
it's only a matter of adding IANA. I don't see any problem with this. Sabrina,
would you open a tool request to the tools team and we can approve it? Or how
do you see it?

Roman: I think the request is for the IESG to make the request, so for one of
the IESG tool reps -- Paul, Éric V, or Warren?

Sabrina: I think that's what we discussed at 119.

Roman: Okay, so Paul, Éric, or Warren, one of you will put that tool request in?

Paul: I can do it.

6.3 [IANA #1360712] renewing early allocations for draft-ietf-mpls-sr-epe-oam
(IANA)

Liz: This is one of Jim's documents  and they're requesting an early allocation
renewal. Jim, do you have anything you want to say about this?

Jim: It's the third renewal, but the document is in my queue. It's a hell of a
mess so I've sent a bunch of comments back to the authors which may or may not
require the document to go back to the WG. Normally this would be going into
Last Call right now. That's where we're at and why I put it forward; I think it
will end up coming through us but it's going to take a little bit of time.

Liz: Any objection to approving this early allocation renewal? I'm hearing
none, so this is approved and we will send that official note to IANA.

6.4 [IANA #1361724] Designated experts for draft-ietf-emu-rfc7170bis (TEAP TLV
Types) (IANA)

Liz: IANA suggested Margaret Cullen and Nancy Cam-Winget. Paul, do you want to
go ahead and put them forward for approval?

Paul: Yes, I pinged them and they agreed.

Liz: Okay, great. So is there any objection to approving Margaret and Nancy as
the designated experts for this registry? I'm hearing no objection, so they are
both approved and we'll send that official note to IANA.

6.5 [IANA #1361734] Designated experts for RFC-ietf-calext-jscontact-16
(JSContact Properties) (IANA)

Liz: This is the item we assigned to Murray at the top of the call.

Murray: Can you reassign this to Orie? It's his WG now.

Liz: Sure; we'll give this to Orie and update the action item list.

6.6 [IANA #1360708] renewing early allocation for RFC 8111 (IANA)

Liz: This is another one of Jim's.

Jim: This one was a little tricky too. The chairs had asked for the allocation
to be made permanent because there's another RFC that suggests it's permanent.
I pushed back and told them they needed to go back to 8111 and make it
Standard. That's back with the WG and we need to renew it while they fix the
RFC.

Liz: Any objection to approving this renewal? I'm hearing none, so we'll send
that official note to IANA.

6.7 Additional designated expert for SMI PKIX registries (Deb Cooley)

Liz: There was only one DE for these registries so we want to add a second one.
Deb has named Sean Turner; any objection to approving Sean as the DE for these
registries? I'm hearing none, so we'll send that official note to IANA.

6.8 Editorial IESG Statement Updates (Roman Danyliw)

Roman: Historically, IESG statements are set in stone and if we want to change
something we rev the statement. Here we have a request to be a little flexible
on an editorial thing to swap out an incorrect email address. I wanted to bring
this to the group as to whether we could swap out an email address on an older
statement.

Éric V: And keeping the date in the filename?

Roman: That's more of a tooling question. When we make updates, isn't there a
last updated field as well as the issue date?

Cindy: It's changed recently because this just moved into the Datatracker.
STatements now have a history field and we can put in an explicit comment
saying it was updated to change an email address.

John: I'm fine with that.

Warren: It seems fine to me as well. We might want to start dropping dates from
the IESG statements for future ones. Anyway, that's separate.

Roman: I'm happy to have that future conversation, decoupled from this
immediate need. IF you want a retreat topic to review statements we currently
have in flight, we can do that.

Liz: I don't hear any objections to this, so we can go ahead and make that
change.

6.9 Expedited Processing for draft-ietf-drip-auth (Éric Vyncke)

Éric V: This is a document we approved two or three months ago, the Drone
Remote ID protocol. There is a meeting of ASTM which is basically in charge of
a lot of standardization of drones both in the US and Europe. They have a
meeting on April 27 and they want to document this future RFC but they want to
refer to a stable RFC, not a draft. I'd love to expedite this and hopefully get
an RFC number before April 27. It would make the IETF a bit more visible in the
other SDO.

Paul: Seems reasonable.

John: Do it.

Roman: No objection, but even if you jump the queue, do you think we could get
it out by the 27th?

Éric V: If you jump the queue, as soon as it gets to the RFC Editor state, you
get a number.

Roman: Oh, and you just want the number. Got it.

Sandy: From our point of view, we'd move it to AUTH-48 before April 27 so the
number is released (although ideally not publicized until it's available and
the authors have approved it). But the number will be available before that
date.

Éric V: Thank you for the clarification. Thank you all.

Liz: Sandy, do we need to send you any official note for this or do you have
what you need?

Sandy: It would be helpful to have a note.

Liz: Okay, then we can send you an official note.

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

Murray: I have two of my designated expert action items resolved, is it too
late to add them now or can we put them on next time?

Liz: We need their names and emails and which registries, can you send us that?

Murray: I can. Or maybe instead of waiting for an email now would you rather do
it next time?

Liz: It would be simpler for me if we did this next time and you just send us
an email, but we can get it done now if you need.

Murray: No that's fine, I'll send you an email and we can do it next time.

Liz: One reminder from me, if you haven't already responded to the conflict of
interest email thread with your updated COI information, please do so.