Narrative Minutes interim-2023-iesg-11 2023-05-25 14:00
narrative-minutes-interim-2023-iesg-11-202305251400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-05-25 IESG Teleconference

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

1. Administrivia
1.1 Roll call

ATTENDEES
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Roman Danyliw (CERT/SEI) / Security Area
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Lars Eggert (NetApp) / IETF Chair, General Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
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
Mirja Kuehlewind (Ericsson) / IAB Chair
Cindy Morgan (AMS) / IETF Secretariat
Zaheduzzaman (Zahed) Sarker (Ericsson) / Transport Area
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Robert Wilton (Cisco Systems) / Operations and Management Area
Paul Wouters (Aiven) /  Security Area

REGRETS
---------------------------------
Jay Daley / IETF Executive Director
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Warren Kumari (Google) / Operations and Management Area

OBSERVERS
---------------------------------
Lucas Pardue
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: Any changes or new items to today's agenda?

Martin: I don't see any action items from the retreat here.

Amy: Those haven't been pulled out of the retreat minutes yet.

1.3 Approval of the minutes of past telechats

Amy: Any objection to the minutes from April 27 and May 4 being approved? I'm
hearing no objection, so those are approved and we'll get those posted. Any
objection to the narrative minutes from April 27 and May 4 being approved? I'm
hearing no objection, so those are approved and we'll get those posted.

1.4 List of remaining action items from last telechat

   * DESIGNATED EXPERTS NEEDED

     o Roman Danyliw to find designated experts for RFC 9347, ESP
       AGGFRAG_PAYLOAD registry [IANA #1265971]

Amy: This is on today's agenda as a management item.

     o Murray Kucherawy to find designated experts for RFC 7462 (URNs for
       the Alert-Info Header Field of the Session Initiation Protocol
       [SIP])[IANA #1266696].
     o Murray Kucherawy to find designated experts for RFC-ietf-jmap-
       blob-18 (JMAP Blob management extension) [IANA #1267309].
     o Murray Kucherawy to find designated experts for Structured Syntax
       Suffixes (RFC 6838) IANA #1270651]

Murray: I have two people for JMAP Blob. For Structured Syntax Suffixes we were
going to have the media type reviewers as well. Let me come back to the top one.

Amy: If you can put the names for those in the slack channel, we can add it at
the end.

     o Martin Duke to find designated experts for draft-ietf-masque-
       connect-ip (Proxying IP in HTTP) [IANA #1272616]

Martin: This is done but I haven't emailed yet. I've just now done that so we
can add it to the end of the call.

   * OPEN ACTION ITEMS

     o Robert Wilton and Warren Kumari to report back to the IESG on the
       impact of COVID-19 to the IETF in July 2023.

On hold.

     o Warren Kumari to follow up on a bis document for RFC 8126 regarding
       designated experts.

Amy: Warren isn't with us today so we'll keep that on hold for him.

     o Rob Wilton to draft a proposal to the tools team for what the
       requested information regarding mail statistics should look like.

Rob: This might have been subsumed by the retreat, I'll have to check the
minutes.

     o Lars Eggert to send email to the LLC about Letters of Invitation
       for Interim Meetings and Retreats

Lars: I haven't sent this email yet but I need to double check with Jay.

     o Éric Vyncke to follow up on updating the title from "IESG Note" to
       "Public IESG Note."

Éric V: In progress.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-httpbis-digest-headers-12  - IETF stream
   Digest Fields (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a Discuss; do we need to discuss that today?

Murray: I don't need to. I'm not sure if Paul got an answer from the authors
yet.

Paul: I did; we're talking.

Murray: Can you put this in AD Followup?

Amy: We also have a downref; should that go in the downref registry?

Murray: Yes.

Amy: We'll make a note.

 o draft-ietf-cellar-matroska-16  - IETF stream
   Matroska Media Container Format Specifications (Proposed Standard)
   Token: Murray Kucherawy

Amy: I have a number of Discusses here; do we need to discuss any of those
today?

Murray: No; I've seen chairs and authors responding so I'll wait for this to
shake out. Let's do AD Followup for this one as well.

 o draft-ietf-rtgwg-yang-rib-extend-20  - IETF stream
   RIB Extension YANG Data Model (Proposed Standard)
   Token: Jim Guichard

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this one is approved.

Jim: This will need a Revised I-D; there are a couple of comments I'd like to
see addressed.

Amy: This will go into Approved, Announcement to be Sent, Revised I-D Needed
and you can let us know when that's ready to go.

 o draft-ietf-lsr-ospf-terminology-08  - IETF stream
   Update to OSPF Terminology (Proposed Standard)
   Token: John Scudder

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this one is approved.

John: I saw Lars flagged a bunch of downrefs which I'm embarrassed not to have
caught myself. What do you all think we should do about these? It's pretty
obvious the downrefs are fine. Although, why are they downrefs? I'm confused.

Lars: They're informational documents.

John: It's a standards track document that's referencing informational, so why
is it a downref?

Lars: It's referencing them normatively. I think it's fine and they should be
approved, the only question is whether they should be added to the registry.

John: It doesn't seem like a case that establishes they should be normatively
reference-able. My take would be let's just approve it and not add them to the
registry. I'm sorry I didn't catch that during IETF Last Call.

Lars: It's not your job, it's part of the shepherd writeup. But no worries; I
wouldn't catch these if I hadn't scripted it.

John: Okay. Can you put it in AD Followup?

Amy: This will go into Approved, Announcement to be Sent, AD Followup, and
we're not adding those downrefs to the registry. I'll note that the Last Call
was on version 3 and we're now on version 8 so I'm not even sure those were
downrefs at that time.

 o draft-ietf-babel-mac-relaxed-04  - IETF stream
   Relaxed Packet Counter Verification for Babel MAC Authentication
   (Proposed Standard)
   Token: Andrew Alston

Amy: I have no Discusses for this document, so unless there's an objection it
looks like this one is approved.

Andrew: Put that in AD Followup; there are a couple of comments I want to see
addressed.

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

 o draft-ietf-opsawg-ipfix-srv6-srh-13  - IETF stream
   Export of Segment Routing over IPv6 Information in IP Flow
   Information Export (IPFIX) (Proposed Standard)
   Token: Robert Wilton

Amy: I have a Discuss; do we need to discuss that today?

Rob:  I think it would be useful to have a quick discussion. This came fairly
late so I tried to get some background of why that text is there. My
understanding is this isn't trying to impose or define that you can have
multiple SRH headers, it's trying to give a definition of if you were to come
across this circumstance then it should be well defined what the behavior is. I
think that was why they put the text in. I think they sent this both to 6MAN
and SPRING and people were happy with it.

Andrew: Originally they had some other text in there which was kicked back
because they stated that 8200 endorsed multiple SRHs but it doesn't, it
prohibits that. If you're going to put in text that allows for a situation that
clearly violates 8200 you'll have to come up with more justification.

Erik K: It violates the spirit of 8200 but if you look at the language, 8200
never used any of the uppercase MUSTs.

Andrew: There is no reference to normative language in 8200, which is why I've
said 8200 was not written using normative language but I read it as such.

Erik K: The routing header section says there should be no more than one.

Andrew: What it says is "each extension should occur at most once, except for
destination options which should occur at most twice." The fact they've already
got an addition in there for another option to appear twice tells me that it's
meant as odd language.

Rob: I don't think you can read the should as a 2119 SHOULD.

Erik K: Even if you did read it as 2119 language, it would be SHOULD, not MUST.

Éric V: It's not really a Discuss point but I have the same issue as Andrew.
There's no point why we should export 2 SRHs. If they're in the packet,
whatever, but routers will act only on the first one. Why should IPFIX export
the second one? I don't have a problem with it, hence my yes because I like the
general idea.

Jim: From a SPRING perspective, carrying multiple SRHs in the packet is
actually illegal. Putting 8200 aside, there's nothing in segment routing that
allows you to carry multiple SRHs. you can encapsulate, that's fine, but what
you can't do is stack to SRHs like an MPLS header. I strongly agree with Andrew
on this point. I read 8200 as normative as well, and if it's not then it's
something we should look at from the RFC perspective. This is not very clear
because we have several ADs reading it differently.

John: Okay, if you want to stick something into the document for IPFIX will
cover this thing that's not explicitly prohibited even though it's not normal,
there's probably a large universe of other things that are not explicitly
prohibited. Should IPFIX also cover all of those? It doesn't really seem
reasonable.

Rob: The authors aren't going to die on this hill, they're happy to lose the
paragraph if it's going to block the document.

Andrew: If they're prepared to lose the paragraph, I'm prepared to lose the
Discuss. Beyond that, they're going to need to give better reasoning than
what's in there.

Rob: I'll follow up with the authors and see what they want to do. Thank you
all. This one stays in IESG Evaluation with AD Followup, please.

 o draft-ietf-lsr-rfc8920bis-04  - IETF stream
   OSPF Application-Specific Link Attributes (Proposed Standard)
   Token: John Scudder

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

John: Thank you everybody for making this an easy ride. Please put this and the
next document in AD Followup.

Murray: Thanks for putting that note in the Yes ballot, it saved us all a bunch
of trouble.

John: Two or three retreats back we had a discussion about patch documents vs
bis, and this was a test to see if we could do a focused bis instead of a
patch/update. This one has worked out pretty well and I hope it gives us the
confidence to do more.

 o draft-ietf-lsr-rfc8919bis-03  - IETF stream
   IS-IS Application-Specific Link Attributes (Proposed Standard)
   Token: John Scudder

Amy: This document should be in the same state, Approved, Announcement to be
Sent, AD Followup, is that right?

John: That's exactly right.

 o draft-ietf-cose-aes-ctr-and-cbc-05  - IETF stream
   CBOR Object Signing and Encryption (COSE): AES-CTR and AES-CBC
   (Proposed Standard)
   Token: Paul Wouters

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

Paul: Put it in AD Followup, I saw some discussion that Russ wanted to talk to
the chairs.

Éric V: After IETF Last Call?

Paul: There was some discussion about changes to the document, so there might
be a revised I-D but I'm not sure yet. This came out of discussion about the
IESG reviews.

Amy: Okay, this will be Approved, Announcement to be Sent, Revised I-D needed.

 o draft-ietf-pim-rfc8736bis-04  - IETF stream
   PIM Message Type Space Extension and Reserved Bits (Proposed
   Standard)
   Token: Jim Guichard

Amy: I have no Discusses in the tracker, so unless there's an objection now, it
looks like this is approved. There are currently no notes in the tracker, do we
need any or is this ready to go?

Jim: It's ready to go.

Amy: Great; this will be Approved, Announcement to be Sent and we'll send it on
Monday.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-ippm-explicit-flow-measurements-03  - IETF stream
   Explicit Host-to-Network Flow Measurements Techniques
   (Informational)
   Token: Martin Duke

Amy: The consensus here is  Unknown so I'm going to change this to Yes for you.
We have a couple of Discusses; do we need to discuss any of these today?

Martin: I don't think so. Jim, you and others have pointed out that this sounds
like it's using reserved bits, but it's not. We're going to have to make sure
that's clear. The other interesting suggestion is that this goes to IRTF, but
I'm not sure what the procedure would be at this point to do that. I can ask if
they're interested in that.

Jim: Based on the email exchange, as long as they remove the text that talks
about actual bits, we should be fine.

Martin: That's exactly what IESG review is supposed to catch, because I had the
context to know that's not what they meant, but it does communicate that they
mean it, so this should be fixed. So this is Revised I-D Needed.

Éric V: [crosstalk] … any things related to TCP and QUIC and generally speak
about any transport header, that would be even better.

Zahed: That's the idea. An experimental implementation and putting part of this
as a QUIC or TCP header, the authors are now saying they're going to move it
which changes the context of the document. Colin made some good comments, so
that's why I put a Discuss on it. When those changes are applied I think this
is a pretty harmless informational document to have. If someone wants to use
QUIC, they can talk to the QUIC WG and do whatever they want to do, but I think
they should move any discussion on header implementation and that's the plan.

Martin: Okay, Revised I-D Needed. Thank you.

Zahed: One question to you, Éric; you put Abstain. Are you going to change that
if they change the document?

Éric V: If they change it to be very generic, not about QUIC and TCP, then I
can move to a Yes.

Zahed: I was just curious if there was something else that needed to be
addressed like moving to IRTF.

Éric V: IRTF would be great, but it's a bit late. If my Abstain is blocking
anything, I can reconsider.

Martin: It's not blocking anything because this is informational. I don't know
if it's worth the work for you to look at it again.

Amy: This will stay in IESG Evaluation, Revised I-D Needed.

 o draft-ietf-httpapi-yaml-mediatypes-06  - IETF stream
   YAML Media Type (Informational)
   Token: Zaheduzzaman Sarker

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

Zahed: We had one thing that popped up about some downrefs. I think the chairs
and authors were wondering why it wasn't called out and I think it was kind of
a rookie mistake, not intentional. The question here is what to do now. Those
are stable specifications and I don't have a problem with those, but I took
this over from Francesca so I wasn't around for Last Call.

Roman: I also think we should approve it. I don't know how we do a YAML
document without referencing YAML.

Zahed: I'm not sure about adding it to the registry?

Roman: The way we've scoped it, I don't think we're currently putting non-IETF
documents in the downref registry.

Zahed: Okay. So I think we can approve it.

Amy: So it looks like this is Approved, Announcement to be Sent. Do you want to
add any notes?

Zahed: I think there are some nits to be addressed so let's put it in Revised
I-D Needed.

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-schanzen-gns-00
   IETF conflict review for draft-schanzen-gns
     draft-schanzen-gns-23
     The GNU Name System (ISE: Informational)
   Token: Warren Kumari

Amy: I have no Discusses in the tracker, so unless there's an objection we can
edit out the background and send the conclusion message to the ISE.

Paul: The ISE told me they might put a note in as well related to the abstain.

Amy: We'll send the standard no-problem message.

3.4.2 Returning items

 NONE

3.4.3 For action

 o conflict-review-urn-ddi-00
   IETF conflict review for draft-urn-ddi
     draft-urn-ddi-05
     A Uniform Resource Name (URN) Namespace for the Data
   Documentation Initiative (DDI) (ISE: Informational)
   Token: Lars Eggert

Lars: This smells like an ART thing but others can take it since ART is
understaffed.

Amy: Any takers?

Roman: I'll take it.

Amy: Thank you, Roman.

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

 o BPF/eBPF (bpf)

Amy: I have a block on this charter. Do we need to discuss it today?

Erik K: I think it's clear. I can add the status of every document, but I'm not
sure if there are any shortcuts. It makes it lengthy. To the second point,
discussion yes but there's no formal interaction. I don't want to rule it out
though.

Éric V: On the latest version of the charter it seems okay.

Erik K: I've been folding in some comments. I think I understand everything
needs to be done and I'm okay unless someone wants to talk about it. I'll
upload a -04.

Amy: We'll wait for your instruction. A version -04 will kick out the external
review once Éric has removed his block. It doesn't have to come back to a
telechat.

4.1.2 Proposed for approval

 NONE

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 o Serialising Extended Data About Times and Events (sedate)

Amy: No blocks for rechartering. Any objection to approving this? I'm hearing
no objection, so we'll send this recharter announcement.

Murray: This unblocks a document that's been sitting in AD Followup, so you'll
see that soon.

5. IAB news we can use

Roman: The IAB is thinking of creating a program or workshop around identity
management. They're working on a response to the European Commission around
sender-pays and responded to the IANA Function Review Team declining to appoint
someone as they've done before. Upcoming will be the publication of a document
summarizing the outcome of the M-TEN workshop.

Paul: Did they talk about NIST?

Roman: They did not.

Paul: I'll see if I can get something out for review today.

Roman: Mirja can also summarize how RIPE went.

Mirja: I think it was positive. I think we picked the right content. It was the
last session of the day so it was a little bit quiet and just a little
discussion at the end. I was able to catch up with some people afterward and a
few people came up to say it was very interesting and maybe they'll come to an
IETF meeting. It was overall positive; I'm not sure how much impact it had but
just being there and visible was good.

Éric V: There were a couple of points at the end about the IETF not listening
to operators. There were a few points where I think we could help and increase
collaboration. Maybe we could forward adoption calls and new work to some mail
lists. There's a demand to present once a year or something, maybe not for a
whole hour, about what's new.

Mirja: Mirjam, the chair of RIPE,  brought up the idea that we could be more
active on RIPE mailing lists. I'm not sure if we should actually send our calls
for adoptions there but I do think it would be nice to work closer. This is not
the only community we should reach out to but maybe there are some low level
steps like putting blog posts up at both organizations or announcing them on
mailing lists.

Rob: Do we have a RIPE liaison? Is there someone from that side we should just
provide updates to that they can present?

Mirja: That's not the role of a liaison; it's usually very formal in cases
where we need this formality to send liaison statements or access documents or
something. So that would be very different. And if we do it for one community
we should do it for others.

Rob: I was just thinking if rather than loading more work onto leadership, if
this is something we could delegate somehow.

Mirja: I want to get an overview about what the communities are that might be
relevant and reach out in some form.

Andrew: About sending Last Calls to external lists, the danger is you could end
up complicating the Last Call process quite a bit by suddenly introducing new
viewpoints, which might not be a bad thing, but there is a risk.

Mirja: I think the other problem is to understand what's relevant, which is us
making a judgment call, which was already hard when making these slides. I
wouldn't recommend that.

Dhruv: I sent one mail to the IESG regarding an IAB discussion at the retreat
to store the IAB feedback for rechartering. That kind of got lost. One
discussion we had was can we put this in the Datatracker so like the IESG
review, one IAB review of a charter is part of the datatracker. Before we send
a request to the tools team we wanted to get feedback from the IESG as well if
you had any concerns. I didn't get any replies, so if anyone wants to talk
about it now we could do that or reply to the email.

Lars: I didn't see the email, sorry. The concern here is optics, mostly. That
would look awfully much like the IAB has a formal role in the standards process
now, which it doesn't by design. That's my main objection.

Rob: I have an email that I haven't gotten around to sending with essentially
the same point as Lars. From a tooling perspective it would be nice to have it
there and see it, but it's the concern about the separation of the IAB and IESG
in the standards process.

Mirja: I think it definitely shouldn't look like the IESG review, it's probably
about how we design it. There are also all the directorate reviews and it
should be more on that level.

Lars: directorate reviews are on behalf of Area Directors. The IAB doesn't have
a role.

Mirja: We're chartered to review new work and provide guidance to the IESG.

Rob: Couldn't the IAB review be done on behalf of the responsible AD? It feels
a bit like it is.

Mirja: We only do these as a service to the IESG and the responsible AD.

Rob: I have no objection to this being in the Datatracker as long as it's
clearly scoped.

Dhruv: I think we can now discuss this with the Tools team and see if they have
an idea of how we could make this separate. We can bring it back to the IESG to
check what you think before actually making any changes. Does that sound like a
good plan?

Rob: That sounds reasonable to me.

Zahed: That would help me to decide how the optics would look like. If the idea
is to talk with the tools team and make a plan and talk again, that sounds good
to me.

Lars: One off the cuff idea would be simply to not show it to the public but
just to IESG members and the Secretariat.

Mirja: That was the initial question we had, would you prefer it to be public
or just to the IESG?

Zahed: I was thinking of it only for the IESG, not the public.

Rob: I'd prefer it go to the public unless the IAB has comments they don't want
to be made public, in which case they should email it to the IESG as they do
now.

Mirja: There are two steps of public, one is just having it in the datatracker
where if people know where to look they can find it, and another is to send it
out to some mailing lists.

Rob: As soon as you put it on the datatracker doesn't it imply that it would
get sent to the proponents?

Mirja: As an implementation question you could only send it to the IESG. But
let's talk to Robert and get a more concrete proposal and we'll send it to you.

Dhruv: Thanks.

6. Management issues

6.1 IANA #1272616] Designated expert for draft-ietf-masque-connect-ip (Proxying
IP in HTTP) (IANA)

Amy: Martin has confirmed that Tommy Pauly and Magnus Westerlund will be happy
to serve as designated experts for this registry unless there's an objection.
I'm hearing no objection, so we'll send the official note to IANA.

6.2 [IANA #1270829] renewing early allocations for
draft-ietf-idr-segment-routing-te-policy (IANA)

Amy: Unless there's an objection, we can send an official note to IANA
extending the early allocation to this document.

Lars: Where is the document in terms of publication?

Andrew: It's been moving for a while but it's progressing. It's still in the WG
and it's something that is actively used out there.

Amy: We'll send the official note to IANA approving this early allocation
renewal.

6.3 IETF 117 Networking Reception Information (Lee-Berkeley Shaw)

Lee-Berkeley: We are going to continue our experiment of hosting this
networking reception at the meetings in an attempt to attract new funders. We
had a very successful reception in Yokohama and thanks to everyone who
participated and suggested names. It seemed well received so we're going to
continue. We're preparing an invitation list and we want to think about who our
speakers might be. In Yokohama, Jun Murai played a big role. We asked Vint Cerf
if he'd be willing to do the same this time and he's unavailable, so I'd like
to ask you all to think of names who might be able to serve that role. I also
have links for an event prospectus and I welcome feedback or questions. There's
also a spreadsheet to brainstorm names of people who are funding decision
makers in the SF area or those who would be good connectors to potential
partners. If you've ever wondered why X company isn't involved, here's a good
opportunity to approach them.

Éric V: In this specific area it may be more useful to consolidate and make the
current sponsors very loyal to us. I'm pretty sure all our organizations wonder
why they pay a salary to ADs. I think it would be more useful to consolidate
and make this people who already support the IETF talking to each other.

Lee-Berkeley: I don't disagree, giving opportunities for face time with our
supporters is incredibly important and we especially try to do that with the
Global Hosts during the meeting. There's a need to make sure we are properly
stewarding those who already support. The intent would be to include some of
the sponsors in this, especially to you all who spend so much time, if there
are folks you'd like to hear a little more about the IETF, those are great
people to have. The intent is to bring in new people that then could become
funders, but we don't want to exclude those who already support. If it would be
useful to you to invite anyone you think deserves to feel a little love from
the IETF, this can be for that as well.

Rob: I'm not sure whether this is on topic. Someone from Swisscom is trying to
talk to the big data providers in San Francisco. He's trying to meet with them
before IETF and bring them to the meeting. They might be interested in working
with the IETF but I don't know. If that might roughly be of interest I can
forward the details along.

Lee-Berkeley: That sounds great. The intent here is for people to learn more
about the IETF, hopefully to someday fund us, but not necessarily. It feels
like that could be an opportunity.  I'll circle back with you after this. I'll
also just take this opportunity to thank everyone who did show up [in
Yokohama]. If you had any connections at that event that you haven't already
told me about, I'd love to know about them for follow-up. I'll circulate these
two documents and appreciate any thoughts you have. Thanks.

6.4 [IANA #1265971] Designated experts for RFC 9347, ESP AGGFRAG_PAYLOAD
registry (Roman Danyliw)

Amy: Christian Hopps has been identified as the expert for this registry. Any
objection to approving him? I'm hearing no objection, so we'll send an official
note to IANA.

6.5 IETF 117 experiment on meeting overflow slots (Roman Danyliw)

Roman: I have a couple of materials to revisit the conversation we had at the
retreat. The context is how we can support groups who want more slots during
the face to face meeting. This is primarily the OAUTH WG asking for more time,
trying to use side meetings, and we tossed around a couple of ideas at the
retreat. The task for me was to formally document a proposal for an experiment.
The problem here is there are certain groups, I don't know how many there are,
that want to meet more than the slots they can get. They've asked for adding
more tracks, or longer days. The experiment we talked about during the retreat
was notionally providing a special overflow slot that doesn't conflict with
anything else. Assuming we do the social on Tuesday and the plenary Wednesday,
and WGs are willing to accept inconvenient times, the proposed experiment is
that on Monday and Thursday, 30 minutes after whenever the normal meeting would
end, we make two rooms available for a 90 minute slot. Those rooms would have
all the Meetecho equipment like a normal slot and this would be the overflow
space for WGs who have already used their two slots and want more. We would not
use this to schedule anything else and the only way you could get into this
slot is if you've already used two and you want a third. The proposal for
deconfliction is that we'd go to the WG chairs mailing list and ask who wants
this inconvenient third slot but these WGs are willing to make the trade in
convenience.

Andrew: In the event we run out of overflow slots, so it's a first come first
served basis?

Roman: I have no sense for what that demand would look like, so that's my
guess. I'm proposing two 90 minute slots. If demand is so high we could add
another slot. I don't know whether we would encounter that. The alternative
would be to increase it to more slots. I also know this is inconvenient for
both Meetecho and the Secretariat also.

Andrew: It's also potentially inconvenient for the ADs if an AD ends up with
four groups at night.

Roman: There's no question. I told OAUTH I can't commit to attending but I
always have to trade between my WGs all the time anyway.

Lars: Can you say what you mean by a slot? Is it one room for 90 minutes or all
8 rooms?

Roman: I was saying one room. Two 90 minute meeting slots are two rooms in
parallel.

Lars: So basically four slots, two each day.

Roman: That's correct. Hypothetically a WG who really wanted this and there was
no contention could get up to four meeting slots.

Martin: Are we going to set expectations that this is like an interim in terms
of consensus calls?

Roman: No, that was not my thinking. The whole setup was that this would be
official meeting time with all the supports and all the decision making.
Otherwise this is back to only as good as a side meeting.

Martin: I don't mind having the support, but when we have groups that meet at
IETF and also meet at interims, there's a sense that the IETF meeting should be
things that are of most interest to the community whereas the interim meetings
are down in the weeds that aren't as accessible. I'd like to encourage the same
sort of vision of purpose here so as to not drag tourists into showing up on
Monday night. The stated purpose is that we want to spend an intensive week
working on this and I'd like to make sure the stuff happening at 9 pm is
intensive work for hardcore people.

Roman: I think that's fair. It sounded like what you were saying was to make
this slot a little less official, but I think what you're actually saying is if
you have 2 slots plus this extra one, optimize the things that you want to
reach the broadest community during the "normal" times and the things in the
weeds with perhaps less participation in this overflow slot.

Martin: I don't know how you'd make that a formal rule but we should write
something to that effect. I don't know if there's a way to highlight "for
enthusiasts only" on the agenda. I just don't want to put pressure on people to
feel like they're missing all the important stuff if they blow off these
meetings. It's a long day where people feel obligated to show up.

Zahed: This isn't for fun or relaxation. We're asking if people would really
like to meet and work, they should call for it. They're already asking for two
slots and they should have been done with their work, but this is if they need
more. This is not every WG who asks for two slots fighting for this, right?

Roman: When we socialized this, I have one WG that I have confirmed will want
this. I think I have another WG that may want that, I don't know. Beyond that,
I don't know what the appetite is for this. I suspect it's uncommon and if a
lot of WGs jump on this, we need to have a different conversation.

Zahed: My thinking is that I like what Martin said but I don't want to tell the
chairs we're telling them how to plan. It's not a choice for everybody, just
those who need it. I don't want groups to think, oh, if we ask for two, then we
can get a third.

Paul: That was my concern. We're basically saying buy two, get three. People
will do two slots just to get the overflow slot. We've been discouraging people
to get two slots and now we're actually giving them a discount to get three.

Roman: The reason why  I was proposing we set a bar that you need to have
already gotten two slots to get a third, I don't want to expand the overflow
time to make the whole agenda longer, where the overflow time is now in the
normal scheduling hours. This is the experiment.

Martin: Can we add a formal AD approval step here? We have all these conditions
and expectations for how this time should be used. I can imagine the TSVWG
chair saying, we have all these proposed individual drafts we don't have time
to present. That's not what this is for.

Zahed: That's exactly what I was thinking. TSVWG could use four or five slots
for that and we shouldn't encourage them.

Martin: I think an AD review step is sufficient to enforce  this and I'm highly
motivated to cut people off from doing it.

Roman: In the slides I've already added AD review as part of the steps.

Lars: An AD should definitely be in the loop. We don't want this to  be used
for regular stuff. If we do an experiment I wonder whether four sessions is too
few. We already know OAUTH wants two and if one other group wants to experiment
with this, there's now contention. Why not just err on the side of having more
rooms available, which will make the Secretariat and Meetecho overhead bigger.
But so be it for an experiment. But we need to have a writeup for the chairs
and maybe for the broader community, and we need that reasonably soon. We also
need to get a word from the Secretariat and Meetecho about what it would mean
for them and the LLC needs to know the cost to the organization.

Roman: You're absolutely right. Jay said you have to write it down so we can
think about whether we can administratively pull it off. If I'm hearing that
this is worth passing on to the LLC for that, I'll change it to four rooms and
write up an announcement text.

Lars: Give him the number of sessions you want. I have a feeling it's going to
be better organizationally to just do 8 rooms one night than 4 on two nights.
We can leave that open.

Andrew: The only issue is that if OAUTH wants four sessions, one night won't
work.

Lars: Well, this isn't just for OAUTH, right? It's also for other groups to
figure out what they want to do. We also need to make it manageable to the
people who run the meeting. Maybe you can give Jay options.

Roman: I don't know what's better, one or two, I guess that's the analysis Jay
needs to do. Any other comments? Hearing none, I'm saying we have consensus for
Jay to price this out and see if we can pull it off. Based on that I'll put it
in the back pocket to have an announcement prepped. Thank you.

6.6 Designated experts for RFC-ietf-jmap-blob-18 (Murray Kucherawy)

Amy: Murray has identified Ken Murchison and Neil Jenkins as experts. Any
objection to naming these experts? I'm hearing no objection, so they are
approved and we'll send the official note to IANA.

6.7 Designated experts for RFC 7462 (URNs for the Alert-Info Header Field of
the Session Initiation Protocol [SIP])[IANA #1266696] (Murray Kucherawy)

Amy: Murray has identified Dale Worley as the expert here. Any objection to
naming Dale?

Murray: I may bring up a second action item if I find a second volunteer, but I
wanted to get at least one in.

Amy: I'm hearing no objection, so we'll send this note to IANA.

6.8 Designated experts for Structured Syntax Suffixes (RFC 6838) IANA #1270651]
(Murray Kucherawy)

Amy: Murray has named the same experts as the Media Types experts: Alexey
Melnikov, Darrel Miller, and Murray Kucherawy as backup. Any objection to
listing these names as experts? Hearing no objection, so we'll send this note
to IANA.

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

Zahed: I have two things. First we are chartering CCWG and we're almost done
with the updates we want. I'm going to push it to the next telechat so everyone
can review it. What we want is a time slot at 117, but I'm not sure we'll be
done by then. I think someone has done that before by putting it in as a BOF
and then it gets scheduled if the WG is chartered before the meeting.

Amy: This is the old CONGRESS group, right? CONGRESS was approved for external
review pending the change of name and acronym. It sounds like you're ready for
it to go to external review with its new name and you want a session at 117.
I'd put it in as a placeholder BOF so we have everything we need to know for
scheduling and then we can put in the session request for it. The new group
isn't in the datatracker yet as a proposed WG so we can't do a session request
until that happens.

Zahed: Can I just rename CONGRESS to CCWG or do I need to start a new
chartering?

Amy: No, you need a completely new object in the Datatracker.

Zahed: Okay, I'll do that and put a request in as a BOF. My next thing is
something I wanted to give you a heads up. In DTN we are having a discussion
about IPN numbers for the nodes. There are two numbers, a node number and a
service number, and they're discussing what the service number is for. There's
now discussion of whether the management of this service number and IPN number
should be done in IANA or something like ICANN. I saw the discussion and
thought it needed broader discussion. The DTN WG wants to talk with the IESG to
discuss the possibilities and issues in more detail. I was thinking we could
give them 30 or 45 minutes at an informal. This needs a big discussion. They're
proposing June 15. If you have any concerns or you think it shouldn't be done
at an informal, let me know.

Lars: I think there's way too much stuff here. We need to talk about this on an
informal call first to understand what they're asking. It sounds like they're
asking for RIRs to take over some stuff they're not traditionally set up to
take over. This is not up to the WG to decide. Everything ends up with IANA,
with the exception of things that go to ICANN and the RIRs. Those are the only
two carveouts we have. If we want another, that's a pretty big deal.

Zahed: The WG was talking like they could decide.

Lars: Why do they not want to be with IANA?

Zahed: Some of them think it's fine with IANA, others think there will be too
many requests. I want them to talk to the IESG because they can explain the
problem better than me.

Lars: I have a pragmatic way forward. A, IANA handles enterprise identifiers
just fine. Second, why are we talking about this in the abstract now? Why don't
we wait until IANA tells us they're getting too many requests and they need to
change some? It's premature to have these discussions when there isn't a
problem here.

Andrew: Putting anything into the RIR system will be more complicated than
these guys have any idea. It wouldn't be one RIR, it would have to go to all of
them, which would require approval, which would require NRO approval, etc.

Erik K: I don't think RIRs are on the table. There are two separate
discussions. One is node numbers and one is about service numbers. There's a
draft looking at node numbers and proposing tha tIANA start to allocate chunks
of node number space to other registries. IANA's role in that would be to
create these ranges and hand them out to another entity. The other is the
service numbers, where they want to have well known service numbers for some
purposes. One possibility is to say this block of 100 service numbers out of 18
million trillion are defined over ECSDS type thing.

Lars: The one thing we're giving up when it moves away from IANA, at least
potentially, is transparency. If you hand out these chunks to other
organizations it's not clear these organizations would say publicly what is in
those spaces, and IANA would. Plus it's free to register, which these other
organizations might not want to have. We should have a discussion with the
proponents where they lay out their proposal and their motivations and we
explain why there are probably difficulties they haven't thought of.

Zahed: That was my thinking, because it was beyond me to handle the whole
discussion. Can we invite them to a discussion with us and we can give them
feedback.

Lars: Task them with outlining what the problem is and what they think the
solution should be, and why IANA isn't the answer. They can do a presentation
and then we can discuss.

Zahed: I've asked them to prepare a presentation and when that's ready I'll
share it with the IESG for a preview of what's coming so we can prepare. That
was all, thank you.

Lars: The 15th is during ICANN so people like me and Warren might not be
available. I will try. Let's do it first so they have a firm starting time.

Lars: I have a quick thing. Jay is having someone go around 117 and interview
female IETF participants and prepare a report for us on it. He's also planning
to ask her to give a half hour readout at the end of 117 to the IESG and IAB
and LLC. He also suggests we open that invitation to whoever wants to show up
from Systers. We're going to try and schedule that before the postmortem, so
there will be an extra half hour or so pop up on your calendars. This is about
the participation experience.