Skip to main content

Narrative Minutes interim-2022-iesg-16 2022-07-14 14:00
narrative-minutes-interim-2022-iesg-16-202207141400-00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2022-07-14 14:00
Title Narrative Minutes interim-2022-iesg-16 2022-07-14 14:00
State (None)
Other versions plain text
Last updated 2024-02-23

narrative-minutes-interim-2022-iesg-16-202207141400-00
INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2022-07-14 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
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
Erik Kline (Aalyria Technologies) / Internet Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Alvaro Retana (Futurewei Technologies) / Routing Area
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
Qin Wu (Huawei) / IAB Liaison

REGRETS
---------------------------------
Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area

OBSERVERS
---------------------------------
Andrew Campling
Charles Eckel
David Lawrence
Ben Schwartz
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

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

Lars: I want to add a management item on discussing the WG side meetings that
have popped up during 114. There was a slack discussion earlier about some
things in the side meeting wiki that looked like WG meetings. If we have time,
let's see.

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 30 teleconference
being approved? I'm hearing no objection, so those are approved. I saw final
narrative minutes earlier this week; is there any objection to approving the
narrative minutes from June 30? I'm hearing no objection, so those are also
approved.

1.4 List of remaining action items from last telechat

     o Roman Danyliw to find designated experts for RFC 8809 (WebAuthn)
       [IANA #1229681].

Amy: Roman is not here today.

     o Murray Kucherawy to find designated experts for RFC 9248
       (Interoperability Profile for Relay User Equipment) [IANA #1232225].

Murray: I have one. Do we do that right now or at the end?

Amy: We do that as a management item. If you want to give us the name in Slack
we can add it.

     o Francesca Palombini to find designated experts for RFC 9246 (URI
       Signing for Content Delivery Network Interconnection (CDNI))[IANA
       #1232482]

Amy: This is on the agenda later as a management item to approve an expert.

     o Warren Kumari to find designated experts for RFC-ietf-dnsop-svcb-
       https (Service binding and parameter specification via the DNS)
       [IANA #1232944].

Amy: This is a brand new action item for Warren.

Lars: The ones that are already on the agenda as management items to approve,
can we drop them from this list? Those take about thirty seconds.

Amy: Sure. That would have been only one of these four because Murray hadn't
told us we had one. But sure, we can take those off the list in the future.

   * OPEN ACTION ITEMS

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

Amy: We have a management item on this one.

     o Lars Eggert to facilitate an update of the document shepherd writeup
       form.

Lars: Done.

     o Lars Eggert to ask the Tools Team to push the global whitelist out
       to WG mailing lists again.

Lars: That ended up with Cindy. I think it's almost done; there are a few lists
that we are waiting to hear if they can be closed.

Cindy: The WG lists all have it; it's the non-WG groups that are still in
process. This action item was for the WG lists only so it's done.

Paul: And based on the emails I sent out this week with my Discusses, it's
worked.

     o Murray Kucherawy to draft text for an IESG statement providing
       guidance about patch documents.

Murray: I owe some replies; this is in progress.

Amy: The action item was just for you to draft the text.

Murray: Okay, then it's done.

     o Lars Eggert to follow-up on the management of the IETF non-wg
       mailing lists.

Cindy: This is still open.

     o Lars Eggert to draft email about RFC8989 Path 1 for NomCom
       eligibility.

Amy: I've seen a lot of email on this.

Lars: It's drafted and sent; done.

2. Protocol actions

2.1 WG submissions
2.1.1 New items

 o draft-ietf-uta-rfc7525bis-09  - IETF stream
   Recommendations for Secure Use of Transport Layer Security (TLS)
   and Datagram Transport Layer Security (DTLS) (Best Current Practice)
   Token: Francesca Palombini

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

Francesca: I don't think so. I haven't seen answers from the authors yet to
Rob's Discuss but I've seen a lot of back and forth for other ADs' reviews and
on the SECDIR review as well. Rob, I don't know if you want to add anything.

Rob: One bit of text concerns me which is about saying if a TLS channel is
available, you must use that. It seems like you're saying all traffic must be
encrypted if there's a TLS channel available. I'm wondering if that was the
intention. I can imagine certain cases maybe within a datacenter or something
where they choose not to encrypt the traffic.

Paul: I interpreted that differently. I interpreted that like if you have star
TLS on the SMTP port you must use TLS there, because by now the time is over to
do plain text.

Rob: I was only reviewing the diff so maybe there's some context about it I
missed. It seemed broader than that and said if there's a TLS channel you have
to use it.

Francesca: Is this point 3 in your Discuss?

Rob: Yes.

Francesca: I would wait for the authors' reply on this if you're okay with
that. Thanks everybody for the review.

Rob: Okay.

Amy: So it sounds kind of like this is going to need a revision, is that right?

Francesca: Most likely. It's not going anywhere for now.

Amy: Okay, this will stay in IESG Evaluation, Revised ID Needed.

 o draft-ietf-ippm-rfc8889bis-02  - IETF stream
   Multipoint Alternate-Marking Clustered Method (Proposed Standard)
   Token: Martin Duke

Amy: I have a number of Discusses in the tracker; do we need to discuss any of
these today?

Martin: A lot of this makes sense. Some of the Discusses are pretty simple and
some are deeper. Do people think this document is fixable in a finite amount of
time or do we need to discuss alternate ideas?

John: Does it really need to be PS or can it be informational? It seemed like a
bunch of the Discusses hinged on that.

Martin: The reason we started on this great journey was because Erik K had a
document that normatively referenced 8321 and 8889 which are experimental. So
we said, we're going to make this PS and the WG said it was ready. I tried to
do that and then the last call list went bananas. Then the wg didn't want it so
I AD sponsored it for a while and read it like six times, and I realized there
were a lot of problems so I fixed a lot of the problems, and then I forced the
wg to take a look at it, and here we are. In retrospect this was way more work
and it would have been way easier to just put something in the downref
registry, so that's a lesson. If there's a finite amount of work and Giuseppe
is willing to do it, that's fine. I think informational would be a little silly
given that the original is experimental and worse. If people would feel better
about this as experimental and doing the downref, that's fine. If we want to
throw this in the ocean of 8889 being the last word, I don't have a huge
emotional attachment to this document although I think the original documents
were worse and I don't know how they made it through the IESG. But I'm open to
that. Giuseppe is pretty responsive and seems to be willing to do the work here
but if a few text changes aren't going to cut it we should talk about
alternatives.

Lars: Both of these docs, this and the other one, feel like they haven't
progressed from experimental to proposed standard. They have way too many
options and it's unclear what is the actual specification you're supposed to
do. They read like a research paper, which isn't surprising because they also
cite a lot of research papers. I'd feel more comfortable if they stayed
experimental and we did a one time downref because it feels like this stuff is
not quite there for proposed standard.

Martin: That's fair. Because of the AD sponsoring I've looked at this more than
usual. Ultimately there are only so many cycles you can go through that.

Alvaro: There are a couple of docs in bier that depend on this. The problem I
had with the original docs that were experimental is that explicitly in the
shepherd writeup and somewhere else it said this document is not ready for
primetime and the bier docs are standards. To me, putting a standard in the
downref that explicitly is not ready for anything is not the right thing to do.
It's the easy administrative thing, but it's just not the right thing to do if
we're going to standardize the use of this in something else.

Lars: Is this a mandatory to implement part of bier? Or is it an optional part
of bier?

Alvaro: For that specification, yes, it was mandatory. This doesn't actually
specify a protocol, it specifies a mechanism. In bier they said we can use this
mechanism to monitor the bier streams. It was mandatory to implement there for
the monitoring of the streams. At the time years ago I asked ippm if they were
still not ready and eventually it came through again with Martin. Bier is not
my wg anymore but they'll probably come around with that proposal again and I
don't think a downref is enough. Unless ippm says this is ready to be deployed
which then begs the question why arent we making it a standard. But I guess the
argument right now is that it's not ready for anything beyond experimental.

Martin: As Alvaro said this is a mechanism. The intent of components and other
fellow travelers is to have a gazillion implementations of this for all the
various encapsulations. At the heart of it this is a mechanism that I don't
think it's poorly designed, but it's not particularly well written.

John: It's not poorly designed but as far as I can tell, as an implementer I
could not sit down with that and write an implementation. I could have a
philosophical discussion between myself and the document about how I feel about
implementing it. Which I took to be the essence of Lars's Discuss.

Martin: I see where you're coming from. I don't know. I wonder is it best to
have half the IESG iterate with Giuseppe to try to clear these issues or do we
need to take this back?

John: I sort of reviewed them backwards because Erik had been beating the
bushes to try and get ballots on the v6 draft, so I went and reviewed that,
which is basically an instantiation of 8321. When I started reviewing the 8321
bis I thought okay this is an architecture document that's supposed to be
referenced by instantiations that provide all the details. That was the curve I
was grading on . I think it's okay in that context as long as the
instantiations then provide sufficient detail to implement it without having to
have a philosophical discussion.

Martin: My question would be to Lars and others who share his assessment. In
your review you'd identified a few things that have this ambiguity and when
Giuseppe fixes them they'll be fixed, or will it be an endless bring me a rock
thing to solve all of these problems where we need to go do some surgery?

Lars: It's hard to say without seeing a revision but if this was an academic
application I'd say major revision needed. The mechanism might be sound but the
way it's described, I think the authors have rewritten the text for so long
they can't see the forest for the trees anymore. They would really benefit from
rewriting it, just the piece that's actually supposed to be standardized. It's
a tall ask.

Erik: In the 6man case, there were 3 issues with the 6man document. The 6man
document was just a document about here's an option to hold some information
and this other RFC tells you what to do with the information. People got kind
of uppity about 3 different classifications of things. One was to get an option
in the registry you needed to have a PS or something better than experimental,
so update 8321; then there was a honking discussion about these things leaking
outside of controlled domains; the third thing was that there's not enough
information in the document to tell me how to implement it. I thought that was
absurd at the time because it's just an option with a bunch of bytes and it
points to other documents that tell you how to implement it. From an IPv6
perspective we had enough information to implement it because you just put the
bytes there.

Martin: I found the leaking thing a little mystifying. Typically this is an
encapsulation. I haven't read your document but I assume that's what it is. One
question is if that's a safe network you're running on, but if your
encapsulation doesn't terminate reliably to a decapsulation you're in a world
of hurt. That seems fundamental.

Erik: It's not an IP encaptor or something but it was defined to be an IPv6
option.

Martin: That has to be done end to end, right? You have to do an encapsulation?

Erik K: It had a destination only option mode.

John: If I remember right, resolving my Discuss got them to stick some text in
there that said you've got to have it in an overlay network with an
encapsulation. Or at least it's in there with a SHOULD. I think up until
recently it did not say that.

Martin: These documents I think it leaves open quic version 3 will have these
bits for networks to play with, which was not going to happen, but they leave
open the possibility of actually touching the user header. In general I think
we think encapsulation is going to be the vehicle for this to happen, whether
it's IP or something else. All right. I guess what I'm getting in terms of
moving forward is that we should probably work through the Discusses but at the
end of the day after a reasonable amount of editorial rounds Lars's Discuss
will stand that we need to clean up the ambiguity, and that is the concrete
work action where I'm going to have to go back with the authors and do a couple
more editorial passes. Does that seem like the right path to people? I'm seeing
nods. So this is Revised ID Needed, and so is 8321bis as they're very similar.
We can move on to the one after that.

 o draft-ietf-ippm-rfc8321bis-02  - IETF stream
   Alternate-Marking Method (Proposed Standard)
   Token: Martin Duke

Marking this Revised ID Needed along with the above 8889bis document.

 o draft-ietf-add-ddr-08  - IETF stream
   Discovery of Designated Resolvers (Proposed Standard)
   Token: Éric Vyncke

Amy: I have a couple of Discusses in the tracker; do we need to discuss either
of those today?

Éric V: Most probably. By the way, I gave the IESG four or five days to review
these; thank you for your review and I really appreciate this. The intent is to
keep this cluster of three together. On this specific one, Lars, it's okay for
the IANA. Paul, we can talk about the DDR and the DNR. As briefly discussed
over slack, I understand that you don't like the ADD wg for whatever reason.
I'm a little bit concerned that you will be blocking those two i-ds forever. A
couple of those points you put into your Discuss are valid. One I should have
spotted, so that's my bad. DDR and DNR do not fail in the same way. Why not
using a resolver.local rather than a resolver.arpa? That's a good question
because it's an issue of the forwarders and the reliance on the arpa zone. Many
of these in your Discuss, I really wonder if they are Discuss points. Sorry to
be direct. I don't know how to resolve all of this. We have the shepherd in the
call too, thank you Andrew. I don't know how to proceed, to be honest.

Paul: I'll need to think about some of that as well. It's not that I dislike
the ADD wg. I think the reality of people wanting to use the local resolver is
a lost cause and it's not happening. People join so many networks that it's not
realistic for them to give the DNS queries to the local network anymore. ITs
coffee shops or malls or whatever.  And people seem to be building more of a
trust relationship with a few trustworthy parties like Mozilla or Google DNS or
whatever. In that sense I feel this work isn't going anywhere, because that's
just not what is in the interest of the end user. But that's fine. That's no
reason to block people who want to use this to deploy. There's also no reason
for those who do use the local network unencrypted to bump them to DNS
encrypted. As long as this is not visible to the user in any way so the user
does not make any different decision because they think my DNS packets are
encrypted so now it's all safe. It's not, it's still going to a random coffee
shop that's local to you. So in that sense I think don't worry too much about
the overarching question I put in, I just wanted to share those views. There
are some more discuss items that I would like to see resolved just to make the
protocol work as the wg intends it to work.

Éric V: Okay. A couple of your Discuss points were really valid points and I
fully support those. So I suggest maybe that all the text that you say why you
don't like the protocol, move it from a discuss into a comment, and keep your
Discuss points. That's usually the procedure.

Paul: Sure, I can do that. That's fine.

Éric V: Thank you. So obviously, Revised ID Needed on this one.

 o draft-ietf-add-dnr-11  - IETF stream
   DHCP and Router Advertisement Options for the Discovery of
   Network-designated Resolvers (DNR) (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Just quickly again, thank you for the reviews in four days. Erik,
Martin, Rob, I see the author has replied to your concerns but today is
Bastille Day in France so Mohammed is not working. Same comment about Paul's; a
couple comments I fully support and a few of them I think are not really
Discuss level. Maybe that's my mistake to not see which are comments and which
are Discusses? Sorry to pick on you, Paul. Revised ID Needed, clearly.

Paul: I'll look it over again to see what are comments and what are Discusses.

Éric V: I see as well Andrew Campling was the document shepherd for both of
these documents. Andrew, if you want to say anything, you can unmute yourself.

Andrew Campling: No, I can pick up with the authors as well. As you said, Éric,
Revised IDs are needed anyway to resolve the outstanding items. I think the
authors have been pretty quick thus far to turn them around so if we maintain
that pace everything will catch up easily.

Warren: As a quick note, I balloted Discuss on one of the documents and the
authors replied almost immediately with a very kind helpful thing and I felt
bad because my Discuss was not written as politely as it could have been.

Amy: So it sounds like this one will also get a Revised ID and we can move on.

 o draft-ietf-add-svcb-dns-06  - IETF stream
   Service Binding Mapping for DNS Servers (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Just quickly as a reminder to Warren to fix the SVCB designated expert,
because IANA is blocking this based on waiting for an SVCB expert. As I said
these three will all be bundled together.

Warren: I'll do it.

Lars: For my Discusses I'll clear as soon as Sabrina tells me I can.

Éric V: Revised ID Needed. By the way the author Ben is on the call, if you
want to say anything?

Ben Schwartz: I don't have anything specific to add but I'm happy to answer any
questions about this.

Warren: Ben, would you be willing to be one of the designated experts for this?

Ben Schwartz: That would be great.

Warren: Great. David Lawrence, would you be willing to be one of the designated
experts for this?

David Lawrence: I am all about [it].

Warren: Awesome, there we go. I have found you your designated experts.

Amy: We will put this as a management item so the entire IESG can approve them.
And this document will go into Revised ID Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-shmoo-hackathon-07  - IETF stream
   Running an IETF Hackathon (Informational)
   Token: Lars Eggert

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

Lars: It's approved but it needs a new revision. I think Charles has some PRs
he wants to merge. Right, Charles?

Charles Eckel: Yes, I do have several pull requests out there. One question for
the group; in some cases, I didn't respond inline to the comments but instead I
just submitted a pull request that if you look at the diff, it's pretty clear
how I was resolving each of the comments. Then afterwards I thought oh, that
may not be appropriate or if it's better to not use github and a pull request
that way in order to address feedback which I thought about after the fact.
Then I started putting more detailed comments within my feedback in the pull
requests. I was just wondering if there is a preference here or does it matter?

Lars: I guess it depends on the individual AD. I would say if somebody feels
like their comments require an email reply they will probably nag you about it.
Do what you think works best for you, and if someone wants you to do something
else, they'll tell you.

John: If the PR speaks for itself, that's fine.

Lars: We haven't figured out how the github-IESG loop works yet. But thanks for
that. We're going revised ID needed.

Charles: The only thing I did not respond to yet was Murray, I didn't see your
review until today and you'd mentioned perhaps this wasn't necessarily dead on
as to the shmoo charter. I think that is true and this document had been
something that was sitting in the background before the pandemic, and then the
pandemic hit and we had to make a lot of changes to the hackathon and even
questioned if it's worthwhile to have a hackathon if we're not in person? It
was because of that I brought it to shmoo and then I asked the wg that I know
it's not specifically in charter but there are aspects of online only meetings
that are discussed in the document and changes we had to make because of that
so the wg was up for working on it with me. That's the history of how it ended
up in shmoo even though it's not really specifically targeting one of the
milestones.

Mirja: We recently rechartered and there was a point in the previous charter on
tooling and I think the discussion was that we could cover it at that point,
but we removed that point now. That shouldn't stop this document.

Lars: We did remove it because it was already in WGLC.

Murray: The reason I raised it was because we obstructed another document in I
can't remember which wg because it was clearly not in the charter of that wg.
If we were to do it over there we technically should be careful about doing it
here too. It seems like this slid through and I'm worried about the optics of
us doing it in some places and not in others. That's why I raised the point.
The other one has to do with crypto and this is more of a BCP about our own
stuff, so I didn't take a stronger position, but I do think we should be
careful.

Lars: That's a fair point. I shouldn't have rechartered it and dropped that
work item while it was still not completely done. My bad. Okay this will be
Revised ID 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

 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 Transfer dIGital cREdentialS Securely (tigress)

Amy: I have no blocks on the charter, so do we approve the tigress wg? Is there
any objection?

Lars: I think Roman wants to make some of the changes I suggested. I guess we
should let him make those changes.

Amy: Sure, it can be approved pending edits. I have chairs, and I have an email
list, so it looks like it's ready to go otherwise.

Lars: The email list will change to the tigress list with the chartering. I
asked Roman about it and he said they're not going to keep using the secret
list. Do you have that on your radar?

Amy: I didn't. Changing an email list in the datatracker is easy.

Cindy: You actually have to create the list first, though.

Francesca: And I assume we would want to subscribe everyone who's subscribed to
secret to the new list as well, right?

Amy: We'll need to get all those details worked out with Roman. The wg can be
chartered with the old list and then change the list later or it can happen at
the same time. It's up to Roman. It seemed like he was real urgent to get this
chartered before 114.

Lars: I think he'll basically make some minor changes whenever he has time and
then decide what he wants to do with the mailing list. I think he still has
enough runway to do it before 114.

Amy: It looks like this is approved and we will send the announcement after
Roman okays the edits he wants to make.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review

 NONE

4.2.2 Proposed for approval

 NONE

5. IAB news we can use

Warren: I missed the call this week.

Mirja: There was no call this week.

Warren: There was some interesting discussion the week before on the IETF 114
BoFs, including the IAB coverage for a number of the BoFs. The RFI on the IAB
response to the OSTP thing on advancing privacy enhancing technologies, which I
think everyone has seen, and some interesting discussion on the workshop
planning for measuring the in network support for troubleshooting and security
which got renamed to something I can no longer remember. There was also a
conflict of interest update where Wes Hardaker is going to be appointed as the
RSSAC representative to the ICANN board and there will be some overlap with his
IAB position which he will handle as one would expect a sane and ethical person
to do.

Mirja: The workshop was renamed to Management Technologies and Encrypted
Networks. I think Lars sent the latest call to the IESG list; the call is out
and if you want to participate in the workshop, please send us a contribution.
There is a second workshop coming up on sustainability so that probably goes
out the week of the IETF meeting or right after.

6. Management issues

6.1 [IANA #1232944] Designated experts for RFC-ietf-dnsop-svcb-https (Service
binding and parameter specification via the DNS) (IANA)

Amy: This item was for Warren to find these experts, which he has done during
the call. Is there any objection to approving Ben Schwartz and David Lawrence
as those experts? I'm hearing no objection, so they are approved and we'll send
the official note to IANA. Thank you very much.

6.2 [IANA #1232482] Designated experts for RFC 9246 (URI Signing for Content
Delivery Network Interconnection (CDNI)) (Francesca Palombini)

Amy: Francesca has identified Phil Sorber as the designated expert for these
registries. Is there any objection to naming Phil as the expert? I'm hearing no
objection, so it looks like this is approved and we'll send the official note
to IANA.

6.3 Suggested IETF 114 Sessions for Getting Familiar with New Topics (Greg Wood)

Greg: Thanks to everyone who has provided input so far. I've just reviewed the
document and made a few more tweaks and accepted all the suggestions that
people have made already. More eyeballs on it as a last take to make sure
nothing is missing would be great. I'll drop a link to the IESG shortly.

Amy: As a note, the preliminary agendas for the WG sessions at 114 were due
yesterday and there aren't many in the Datatracker. You might want to lean on
your chairs a little bit. I know some of you were waiting for agendas to know
if you should put something in the document for Greg.

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

Amy: It looks like this early allocation request will expire at the end of
August without an extension. Alvaro, this is one of yours; do you want to say
anything about it?

Alvaro: This document is already in my publication queue so it has already been
through WGLC, which means there are implementations, so we should definitely
approve the extension.

Amy: Thanks Alvaro. Any objection to approving this extension? I'm hearing no
objections, so it looks like we have approved this extension of this early
allocation and we will send that official note to IANA.

6.5 Impact of COVID 19 on the IETF - IETF Monthly Activity Report (Alvaro
Retana, Warren Kumari, Rob Wilton)

Alvaro: Thanks Amy. You're doing all the work here.

Warren: It is actually somewhat worrying, the results.

Mirja: The drafts are back to normal, just mails are down; which I think is a
good thing.

Alvaro: it looks like the -00 drafts are still kind of low. They're a little
higher right before this IETF. We've only had one meeting sort of back, and it
wasn't even half in person, so it's probably too early to say that the effect
has passed. Or that our theory of everything being down was because we were all
online. Ideally this will look better next time.

Warren: The bit that's more concerning to me than emails is the -00 drafts.
It's noticeably lower over time than before. Yes, covid, but we've had a bunch
of covid and one in person and it is still quite a lot lower than previous
years, including last year.

Rob: The number of bofs that we have has gone up so that's an encouraging sign.
People have been potentially waiting to get things started. The other thing I
looked at was the figures for the number of people who have signed up for 114,
[which] looks like it's still roughly 50/50 between in person and online. Maybe
slightly higher in person. It's nothing like back to anything before. I know
some key people in some wgs are just staying away at the moment and I'm not
sure how long that's going to take to resolve.

Mirja: Maybe it would also make sense to dig a little deeper into the numbers.
I'd be interested in the ratio of new -00 drafts that actually went into the
process and got a wg document -- is that down as well? Or is it just the
'useless' -00 drafts? Not that they're completely useless, but that they don't
get adopted?

Rob: We can look at that. That would be interesting to know, to split those in
terms of where they've gone. I don't know if that changes anything even if we
had more data, that data doesn't change the outcome. That's the thing we need
to be concerned about, should we be trying to take steps to change this or
should we just wait another few meetings and hope it picks up?

Mirja: The obvious conclusion from this data is that there is an impact from
the pandemic, but I'm not sure if this is the only impact. That's why I asked
this question. There might be more reasons there were more drafts at certain
points and less drafts at others.

Lars: There might also be a reason that we have the shorter days and the same
number of tracks, in the sense that wg time is squeezed and wgs typically
prioritize chartered work. I think we need to have a discussion of having more
time where people can present new work in working groups.

Warren: That's a very good point. In addition to that, it feels as though there
isn't as much time for people to interact with each other. We had a view that
once people are meeting again in person there will be an upswell of new ideas
as people bump into each other and chat, and at least for me at the last
meeting, it didn't seem as though there were as many people bumping into each
other and chatting. It seemed like panicking and running from one wg to
another. That might have just been me. Longer cookie breaks or something? Not
that designing a solution on the fly ever ends badly.

Lars: This is maybe foreshadowing the discussion we're going to have later on
side meetings but I think we're going to have to go back to a schedule that's
more like a pre-covid schedule with longer days or we're going to have to add
another track, for two reasons. I don't think there are any other options. If
the wgs are not getting creative and people don't have time to present their
ideas in the wg.

6.6 WG Side Meetings at IETF 114 (Lars Eggert)

Amy: I think we can segue into this topic if you need to.

Lars: Thanks Amy. I think we're seeing that the lingering effects of Covid are
not over and one of the ways we are still trying to cater to the remote
participants. It's a nice thing but it comes with downsides and this might be
one of them. What do we want to do, if anything, about this co-opting of the
side meetings by some wgs?

Alvaro: It's perfectly fine for a chair to say hey, I booked a room at 5 on
Thursday, if anyone wants to continue discussion. As an informal discussion
just like bumping into each other in the hall or something, just that we're
going to meet in that room. It's not an official meeting; I think that's the
part that needs to be clarified. And that because it's not an official meeting
it's not going to have Meetecho support and everything else.

Mirja: I think we should talk to these two groups because we did say you can't
have 2 slots but please have other meetings. I think what we meant is interim
meetings later but maybe they misunderstood and thought they should have  side
meetings instead. We should clarify what happened there.

Lars: Are both of these Roman's groups?

Francesca: Both are, I think.

Martin: I think this is the worst of all possible worlds. With no recordings,
no Meetecho support, etc, that's far worse for remote participants than having
additional tracks or a longer day with no ability to timeshift via a recording.
I would really encourage either forcing them out of IETF week or retconning the
whole one-meeting thing. Or something. But this is not good.

Rob: To Alvaro's and Martin's points, if they get through half of their agenda
in the official meeting and then push the rest to a side meeting, that becomes
even worse. Rather than having a separate focus.

Alvaro: Right, it depends on how they position it. If it's just a room for
people to get together that's okay. If it's to continue the agenda there and
make decisions and consensus and that stuff, that's snot good.

John: Since they're both Roman's groups, have we talked this part of it to
death and he should talk to his chairs to try to sort this out? If I remember
the past conversation Roman was the most passionate about being completely
consistent and fair if we're going to have just one meeting gper group. I trust
him to sort this out.

Lars: I'm fine with letting Roman deal with his working groups. I wonder though
if we want to have a discussion at the plenary or somewhere else about what we
should do going forward. All signals point to longer days.

John: I've had several chairs grouse to me in various ways about having to fit
themselves into a single slot and I'm sure most of you have too.

Francesca: That's what I wanted to say. If we start deciding how many side
meetings WGs can have, that's a slippery slope. I understand the point of it
being a side meeting and not an interim or official wg meeting but also if
people are there and in person and want to take a room and discuss things, we
shouldn't be stopping them. That seems like stopping progress.

John: To Lars's point, it's a signal from the community and they're voting with
their feet.

Francesca: We need more slots. That's roughly the outcome of this.

Mirja: This discussion was supposed to be in scope for shmoo but it doesn't
really happen. And I don't think we have a session anymore, do we?

Lars: Shmoo canceled because nobody proposed any topics.

Martin: Is shmoo chartered to do hybrid meeting stuff?

Lars: I'm talking to the heads of shmoo to close the group because I don't see
a lot of activity along with the chartered work items. And not having any
requests now is another signal that maybe we ran out of energy there. But this
is a decision we shouldnt necessarily leave up to shmoo. We need to talk about
this ourselves.

Éric V: Longer day or a Friday afternoon, right?

Lars: Friday afternoon isn't going to give us enough time. I Think it needs to
be longer days or another track. Or both.

Mirja: We need some community input on this somehow.

Francesca: I would like us to have a common message to our chairs. I, like
Roman, have also told my chairs we're not doing more than one session because
we don't have enough slots, but you're welcome to request side meetings or do
interims. The fact is that interims do not replace IETF week meetings
completely because participation is much lower, you get much less people, you
don't get the tourists or people who might get interested. It's not the same
thing. If now we are also discouraging side meetings, which have the advantage
of being in person so might potentially attract those people who might not call
into interims, then we're missing out on more. Just so that we have the same
message.

John: I thought Alvaro's way of framing it was exactly right. Does anybody
disagree with that? A side meeting is an opportunity to get in a room together
and talk but be aware that it does not form any part of the formal agenda, not
minuted, no remote.

Francesca: It could be minuted if the chairs want.

John: But it's not part of the proceedings.

Lars: It's not part of the standards process. That is the key thing. 2026
doesn't talk about side meetings, it talks about bofs and wg sessions and
mailing lists. That's where consensus is formed.

Alvaro: The other thing I think Éric brought up on the list is that we only
have so many slots for side meetings anyway so there are a lot of conflicts.
Even if these were real interim meetings, we're too late, because it's already
2 weeks before the IETF and we didn't announce any of these. According to our
process that's it -- we ran out of time and didn't announce the meetings on
time for them to actually be meetings.

Francesca: That sounds good. Having told our chairs you get one session but you
can do side meetings or interims and then suddenly say but side meetings don't
count…

Mirja: The message about moving things to interims is not quite like continuing
your session there. It's to figure out what you need to discuss at an in person
meeting and where you get benefits there, and figure out what else you can
discuss in an interim instead. Probably these items are not the same.

Lars: Is anyone interested in writing a draft we could send to wg chairs that
would clarify this? What side meetings are, how interims can be used most
effectively, and what should go on the agenda?

Mirja: There was a draft from Mark Nottingham about scheduling interim
meetings, which also talked a little bit about how to use them most
efficiently. For shmoo.

Lars: We can put a reference to it in an email but I think we should send an
email to wg chairs before 114, tomorrow or monday or something like that. So
since Roman isn't on the call and he needs to tell something to his chairs
anyway, maybe we suggest to him that he makes it general enough it can be an
email we send to all wg chairs. I'll send him an email tomorrow.

Erik K: Do we have any IESG statements on this?

Alvaro: I don't remember if it was a statement but we did send a message 2 or 3
years ago about what the side meetings are.

Mirja: I think we have a statement about how the note well applies to side
meetings. That's all I remember.

Erik: There are several guidelines on interim meetings.

Lars: There's a link to one I just put in the slack that seems to say a lot of
good things.

Erik K: There is one from 2016 and one from 2020.

Mirja: It does talk about interims and in person meetings but it doesn't talk
about side meetings.

Lars: It might have been an email to wg chairs.

Éric V: Or simply on the wiki page where you schedule side meetings.

Lars: I'll see if I can convince Roman to do this for us. The other thing I
wanted to ask is if I should put a question into the plenary slide deck to seed
the discussion at the open mic about this? This being more tracks or longer
days or neither of the two. Or a combination. Or something else.

Alvaro: We've been working on the assumption that because there are still going
to be a lot of remote people we have the shorter days to accommodate. Making
the decision for a longer day either assumes that it's too bad for the remote
people or we hope there are going to be a lot more in person people.

Lars: We could do another track but that increases conflicts across the board
which people  also hate.

Mirja: It depends on the venue because usually we can't have more rooms.

Lars: Exactly. Going parallel also means the meetings are probably going to be
smaller. Sometimes we have some flexibility. I guess if the secretariat knows
with enough leeway they can make arrangements. For London, if we told them we
wanted to add a track they could probably see if we can make it work.

Mirja: I don't think it's that easy because it's part of how we contracted the
hotel.

Amy: It's also not just the room space, it's the tech. The backup tech stuff,
all the Meetecho deployed stuff, I don't know how many extras we have.

Lars: So that means longer days is really the only option unless we find out
that we have enough for another track.

Mirja: We can remove the plenary and have wg sessions instead.

Lars: Maybe this is an email to wg chairs or even ietf-announce saying we are
considering creating more wg session time, and here are some of the options we
see, let us know what you think. Some people will reply by email and others
will line up at the microphone.

Erik K: Is it really creating more session time or is it restoring to the
previous set of session time? That's really what the change is, right

Lars: Yes it would be restoring to the pre pandemic schedule.

Mirja: This is not only a question for the chairs, but the whole community,
right?

Lars: Yes.

Martin: I don't object to asking for community input but it's going to be mixed.

Lars: But we'll get data and then we have to make a decision.

Mirja: I'm wondering if there's a better way to get feedback. Maybe a survey?

Lars: Should we tell Jay to stick it in the post meeting survey? It seems like
with a fresh impression of Philadelphia people might have an opinion.

Mirja: We could refine the questions there or we could go for a second survey
because I think this is really important.

Martin: I think the meeting survey is probably more likely to succeed than a
bespoke survey people might miss an email for. I like the idea of grappling on
with that.

Mirja: The other crazy idea I have is that we could use the opened up shmoo
spot and run a bof on that.

Lars: There are conflicts. It's too conflicted. Greg, does Jay do the survey or
is it you or both of you?

Greg: Jay generally takes the lead but I've taken a note to follow up with him
on this.

Lars: Okay so let's see if we can circle back and add something in there.

Martin: The choices would be status quo, longer day, or more tracks?

Lars: Or fill in your suggestion here. We would need to explain that the extra
track comes with issues that might make it more work than it appears. Like
equipment and potentially not being able to do it at the venues we've
contracted.

Martin: I don't know if we need people to adjudicate that. If we get
overwhelming feedback that we should add more tracks and we can't do it, we
can't do it, and we do the best we can. The question is, what does the
community want to do? I don't think we should muddy it with issues that are
orthogonal to the attendee xperience.

Lars: Fair point, but people who say they prefer more tracks need to understand
there's a certain time delay until we can do it consistently because we've
already contracted venues out into the next few years. If those venues can't
support that we can't do the extra track. Equipment we can buy or ask for from
sponsors but the venues are picked already. I'll put something into the Sunday
IESG agenda because Jay is going to be there for that and we can have a
discussion in the room. I'll also talk to Roman about mailing the chairs.

6.7 Designated experts for RFC 9248 (Interoperability Profile for Relay User
Equipment) [IANA #1232225] (Murray Kucherawy)

Amy: Murray has identified Brian Rosen as the designated expert for this
registry. Is there any objection to approving Brian? I'm hearing no objection,
so we will send that official note to IANA.

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

Lars: I'm using the 5 pm Monday slot for a side meeting on NomCom eligibility.
Martin, if you haven't seen that email, you'll probably be interested. This is
to find some common ground for the official session on this in gendispatch.
There have been some proposals of what they should do and we're probably going
to run out of time in gendispatch. Those of you who are interested, come to
that.