Narrative Minutes interim-2023-iesg-07 2023-03-16 14:00
narrative-minutes-interim-2023-iesg-07-202303161400-00

INTERNET ENGINEERING STEERING GROUP (IESG)
Narrative minutes for the 2023-03-16 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
Jay Daley / IETF Executive Director
Roman Danyliw (CERT/SEI) / Security Area
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) / Incoming 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
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
---------------------------------
Warren Kumari (Google) / Operations and Management Area

OBSERVERS
---------------------------------
Heb
Oooonduke
Brian Campbell
Bob Hinden
Dimitris Maroulidis
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: We added some new management items shortly before the call. Any other
changes?

1.3 Approval of the minutes of past telechats

Amy: Any objection to approving the minutes from the March 2 telechat? I'm
hearing no objection, so those will be posted. I also saw final narrative
minutes; any objection to approving those? I'm hearing no objection. I also
have the BOF call minutes; any objection to approving those? Hearing no
objection there either.

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: Marking this in progress for Roman, who's not here yet.

     o John Scudder to find designated experts for draft-ietf-lsr-flex-
       algo-25 (IGP Flexible Algorithm) [IANA #1266560].

Amy: We have approval of some designated experts later on in today's agenda.

John: I might have to step out early so can we do this earlier in the call? Or
can you do it without me?

Amy: Usually those go smoothly unless there's an objection.

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

Murray: This is in progress.

     o Murray Kucherawy to find designated experts for RFC-ietf-jmap-
       blob-18 (JMAP Blob management extension) [IANA #1267309].

Murray: Also in progress.

   * 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 March 2023.

Amy: On hold;  let's pick this up in Yokohama.

     o Éric Vyncke to draft a proposal for the tools team to auto-populate
       the approval announcement text in the "ballot text" section
       (document abstract, responsible AD, document shepherd).

Éric V: It's been drafted so I suggest rephrasing this as Éric to follow up.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-teep-otrp-over-http-14  - IETF stream
   HTTP Transport for Trusted Execution Environment Provisioning:
   Agent Initiated Communication (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: Can you put it in AD Followup so I can read the comments?

Amy: Sure. This will be Approved, Announcement to be sent, AD Followup.

 o draft-ietf-pim-assert-packing-10  - IETF stream
   PIM Assert Message Packing (Proposed Standard)
   Token: Alvaro Retana

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

Alvaro: We just need the authors to work on clarifying the text. I'll hopefully
get them to do that by the time we get to Japan, so no. We're going to need a
revised I-D though.

Amy: So this stays in IESG Evaluation, Revised I-D Needed. Thanks.

 o draft-ietf-sfc-oam-packet-02  - IETF stream
   OAM Packet and Behavior in the Network Service Header (NSH)
   (Proposed Standard)
   Token: Andrew Alston

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

Andrew: Can we put it in Revised I-D needed? They're going to be addressing
some comments.

Amy: Sure. This will be Approved, Announcement to be sent, Revised I-D Needed.

 o draft-ietf-6man-rfc6874bis-05  - IETF stream
   Representing IPv6 Zone Identifiers in Address Literals and Uniform
   Resource Identifiers (Proposed Standard)
   Token: Erik Kline

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

Erik K: I think we should probably talk about some of these things. If the
Discuss holders want to.

Murray: The thing I wanted to discuss was the ARTART review was pretty serious.
It suggested that there wasn't enough interaction or that the feedback they got
was largely discarded and they wanted to go ahead with it anyway, without
giving clear reasons about why that is. There have been text changes as a
result of the ARTART review, but there's been no comment from the ARTART
reviewer or anyone else that it's either good enough or not good enough with
issues outstanding. The Discuss is to say that I'd like a moment to dig down
further and say if this is good enough or not. Something I noticed while I was
reviewing is that 6man is not chartered to do anything like this so what do we
want to do about that? If there was a bye given by the AD I don't see any
record of it. I'm concerned about that piece as well.

Erik K: Since it's a bis of a document we had previously produced I didn't
stress too much about whether it was in charter or out of charter.

Éric V: 6man is about maintenance, and this is maintenance.

Erik K: I think Murray's point is that it's not maintenance of the ipv6
protocol, it's something outside of it.

Murray: I'm not trying to be territorial by saying this but I don't know a
better way to say it. You have an INT area work area dabbling in an app space
without any coordination I could find. That's the main thing I'm worried about.

Erik K: Hang on a minute, there's lots of attempted coordination laid out in
the shepherd's review. There's not no coordination.

Murray: Sorry, I may have spoken a little aggressively. Someone pointed out
that the shepherd writeup claimed to have coordinated with httpbis and I could
find no evidence of that at all.

Erik K: bis or uri review?

Murray: There was a post to uri review that got a bunch of frankly useless
feedback from somebody and then no other review at all. They reached out but
didn't get any feedback. For httpbis, which was in the list of the places the
shepherd writeup claimed there was contact, I couldn't find any through some
basic searches. I'm not on the W3C list so I don't know what the discussion was
over there. Brian emailed me late last night to say the W3C tag review, he
largely dismissed what was in it. I'm just generally worried about how this
looks and I wanted to take a minute to make sure it's in the right state. This
whole thing made me want to pause and take a little longer to look at it. I
decided not to surprise everyone with a defer and do it this way instead.

Erik K: I understand. I'm looking at the shepherd writeup and I don't see where
it mentions asking httpbis.

Murray: She just said http, I assume she meant bis and not api.

Erik K: I don't see that. I opened the tag thing. The response was linked in
the shepherd review, but if you go there, it's a little thin and links to a
github agenda which then contains a link to minutes. The minutes for the zone
discussion basically amount to the stuff they put in the review. Which was
concluded unsatisfied. It's the comment from December 20 that says they suggest
the IETF continue to talk about it with the group in charge of 3986. The other
comments, the reason I tried to bring this forward was to get more eyeballs on
this. Most of the comments seemed to be problems with the original document
itself and not problems with this specific attempt at fixing that original
document. It does fix a small thing and the people who are presently
complaining aren't implementing the old thing, so…. I spoke to Martin in person
about his review when we were in London but that's not documented anywhere.

Murray: We don't have to take up more of the telechat talking about it. If
there are more opinions I'm happy to hear them or I can just follow up with you.

Erik K: I'd love to find a resolution to this. I will note that some of the
objections from browser implementers are that they are never going to implement
link-local addressing support because of link-local addresses, not because of
uri format issues. Security concerns, you can browse a local network, a bunch
of other stuff we can go into and there are replies to. Some of the core issues
are around network programming with ipv6 link-local addresses and not
specifically around the format of the URI. I don't know that those objections
necessarily apply to this document either, which was why I brought it forward.

Murray: It may be the case that we just have to add some text to clarify all
that so it doesn't look like you had two sides that were ignoring each other,
like we decided to plow through a stalemate. I'm a little sensitive to some of
the arguments about this being terrible optics if we proceed. There's probably
a cleaner way through that I'm happy to help you develop.

Erik K: That sounds great.

Rob: Did you want to discuss my Discuss? Effectively, my concern is that this
only works for a small number of devices, or certain categories of devices.

Erik K: I tried to reply to you in slack. I suspect that it currently doesn't
work. Or it currently does not obey the formal ABNF because all of this isn't
in the list of unreserved characters. I think 6874 and this bis are -

Rob: The current one allows you to encode them, does it not? And that's one
thing that's changed. There might be another reason why it doesn't work, like
case sensitivity. Before if you had those you could just percent encode them
but now you can't.

Erik K: Oh, youre saying that some of this would be percent encoded?

Rob: In the previous version, that's how I read it. It might be a different
issue. I can appreciate the design to make these things easy to use and cut and
paste, but I don't see that will work in these scenarios. Anything on a Cisco
or Juniper or Huawei device I'd thought would use interfaces that can't fit
into this format. I don't know what the answer is there other than changing the
encoding.

Erik K: I think there was some text at some point that said fundamentally
there's no clean resolution to this given that there was never a standard for
interface names. There doesn't seem to be a one size fits all, apart from just
using zone IDs. The interface names are particularly problematic.

Rob: I only sent this late yesterday, so maybe I'll wait for a comment from the
authors.

Erik K: And maybe with Murray's help there's a way through. Did Francesca's
Discuss….?

Murray: I think she just supported mine.

Francesca: Yes, I just supported Murray's.

Erik K: I was looking for three.

Francesca: By the way, I have just pinged Martin Thomson as a result of the
ARTART review discussion which was quite long and there were some text changes.
If there is additional input or if he has any insight about what Murray put in
his point 3, I think that's good for us to know. Maybe look out for that also,
Murray.

Murray: I feel a little sorry for Martin because I peppered him with stuff as
well. For Erik, I'm looking at the shepherd writeup and it says the following
reviews are benign requested, W3C TAG and the link you mentioned, URI review,
they did ask and like I said there was no useful discussion, art@ietf - I
remember looking at ART and not seeing it but I was looking in a lot of places
and may have missed it. Then it says HTTP WG review and I don't know in
retrospect if that's bis, or api, or something at W3C that I didn't think to
check.

Erik K: Yeah, the formatting got messed up. I see.

Francesca: There was no HTTP review requested or pointers in the mailing list.
There was one mail from Mark, httpbis chair. That mail was linked from Martin
Thomson's review. The ART discussion is probably from the ART review.

Erik K: So, ways forward? Continue discussion on the mail list and perhaps in
Yokohama?

Rob: For my part, I think that's correct. More discussion required.

Murray: I'm happy to work with you guys to get through this. We can't undo the
fact that the original work was outside the charter. I understand the use cases
but I just think there are a lot of loose ends to tie up. Over slack, email,
and in yokohama, all three of those are fine with me.

Lars: Take advantage of the time together coming up to get all the relevant
people around a table to hash it out.

Erik K: Sounds good. So I think this document does not change state.

Amy: It stays in IESG Evaluation, AD Followup.

 o draft-ietf-opsawg-add-encrypted-dns-11  - IETF stream
   RADIUS Extensions for DHCP Configured Services (Proposed Standard)
   Token: Robert Wilton

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

Rob: I don't think so. It looked like a fairly easy thing to resolve.

Éric V: I agree. It's basically an I that needs to be dotted and a t crossed;
nothing dramatic but it needs to be done.

Rob: Thank you all for the reviews, as always.

Amy: We'll put this in Revised I-D Needed.

 o draft-ietf-lpwan-schc-compound-ack-14  - IETF stream
   SCHC Compound ACK (Proposed Standard)
   Token: Éric Vyncke

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

Éric V: Let's do a Revised I-D. We tried to address the comment from Mirja
regarding the reference and the Yang stuff. … And Alvaro, by the way, the
original document was split into two parts. One turned into the sigfox document
and this one was removed from the sigfox document because it can be applied to
other technologies, so it doesn't replace it. So if you don't mind, I will not
follow up.

Alvaro: That's fine. I noticed that it was split and just wanted to keep the
traceability there. Up to you.

Éric V: It's perfectly fine, thank you for bringing it. Thank you everyone.

Amy: Okay, this goes into Approved, Announcement to be Sent, Revised I-D Needed.

2.1.2 Returning items

 NONE

2.2 Individual submissions
2.2.1 New items

 NONE

2.2.2 Returning items

 NONE

2.3 Status changes
2.3.1 New items

 NONE

2.3.2 Returning items

 NONE

3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-httpbis-client-cert-field-05  - IETF stream
   Client-Cert HTTP Header Field (Informational)
   Token: Francesca Palombini

Amy: I have a Consensus Unknown here, so I'm going to change that to Yes. There
are no Discusses in the tracker, so unless there's an objection now, it looks
like this is approved.

Francesca: With Revised I-D needed, please. Thank you everybody for the
reviews. I think the authors have been replying to all mails. There were a
couple of questions about shouldn't this be standards track. I just wanted to
confirm that during my AD review I also brought that up to the WG but I see
this is just meant to be the reference specification for two IANA registrations
that are specification required and the WG had consensus about informational.
Otherwise, Revised I-D Needed please. Thank you.

Amy: This is Approved, Announcement to be Sent, Revised I-D Needed.

 o draft-ietf-sidrops-roa-considerations-07  - IETF stream
   Avoidance for ROA Containing Multiple IP Prefixes (Informational)
   Token: Warren Kumari

Amy: I have a Discuss in the tracker; Warren can't be here today so we're just
going to put this in Revised I-D Needed for him, I think.

Paul: That sounds right. I did get a reply back on the question but I'm not
sure if they're going to add some clarifying text or not.

Andrew: The question about whether this is a BCP is actually quite an important
one.

Paul: That's the interesting part, there seems to be disagreement about who
should or should not use this but none of the discussion is in the document
itself. To me that belongs in the document.

Andrew: If this goes into Revised I-D Needed and it changes tracks like that,
does that cause any issues?

Alvaro: It would just need to do another Last Call. But to me the thing is that
the recommendation here, whether they put all the details or not, they're
recommending to not do what 9319 is recommending and that is a BCP. So it's
weird to say no, don't do the current practice, and we're not making this a
current practice. 9319 is similar to this one in that they recommend doing
things, they don't require doing anything. Similar circumstances you can say
the same thing; they're not telling everyone to do it, they're leaving it up to
people. I think this has to be a BCP.

John: Now that you mention it, it should also update 9319, shouldn't it?

Alvaro: It should at least be in the same BCP. Maybe it should update it. The
circumstances are a little bit different because of what they say about being
closer or further to the root. But yes, it should at least be close to 9319.

John: If you didn't put that in your ballot already I hope you will, or maybe I
will. Someone should capture it.

Alvaro: Why don't you hold it, because I'm stepping down anyway.

John: Got it.

Amy: Okay, so discussion here is ongoing and we'll put this in Revised I-D
Needed for Warren.

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

 o CONGestion RESponse and Signaling (congress)

Amy: There are a couple of blocks here so it sounds like this needs more
discussion.

Zahed: I think the discussion would be educational on what to do with this
charter. I'm grateful to get all these reviews and this is making the charter
text great. I haven't seen any technical concerns, it's more about
clarification of what it says at the end, the gap between the scope and
milestones, and the name. Let's just start with the gap between milestones and
scope. Let me ask one question, I have looked into the requirements and there I
saw a MUST for a set of milestones but there was no number. The message I was
giving to the chairs was to give me at least one milestone so we can proceed.
And I got one milestone. So that was a very low bar to meet and I thought that
was good enough, but the strongest comment said that the charter is pretty
broad and why is there only one milestone. Am I understanding right or wrong
that we don't need a complete set of milestones covering the entire scope of
the charter, or can it be just one milestone?

Éric V: If you expect a real definitive answer, you'll be disappointed. When I
see the scope includes this, this, this, and goes on for more than five points,
and a single milestone, yes you fit the letter of RFC blahblah, but come on. I
don't mind so much about milestones, but about work items. Work items are what
I really want to see. What will be delivered?

Lars: They're chartered to do a version of one RFC, and that RFC is not about
any of the things that are then coming as bullet items. It's inconsistent what
you want this group to do.

Zahed: That I completely agree with. If I see the history of the discussion we
started with this bis document as the main thing to happen and then when the
community started to talk about it they wanted to work on other things. There's
an intention to talk about it but I didn't see anyone saying we're prepared to
do this and that. The only thing I know the community wants to put their hands
on right now is the bis. But there are discussions and the bullets are combined
from many sources.

Lars: 5033 basically needs to be obsoleted or revised in order to have a WG
work on this. That's a prerequisite for doing anything. But this charter should
still talk about what it actually wants this group to do. The list puts some
stakes in the ground and says this is the rough area you're going to work in,
but it's not actually clear what you want them to work on. Specifically the
last line that it will not remain open simply because “in case” further work
comes along. It seems like no work has come along yet, so are you going to
close it? It's not clear.

Martin: As Lars and others know, there are some proposals in that space
floating around that might be ready to go over the next few years as a
standards track thing. At this point I think it's difficult, I wouldn't be
comfortable putting in milestones for anything else but we do need to do this
5033 thing. The hope is that we get 5033 done and then after that there's a
robust set of proposals that sustain this as a long-lived community, because we
don't think a place like TCPM is the right place to do congestion control work
anymore. It's possible that nothing materializes after we do 5033, in which
case we close it. That's really the reason the charter is written the way it is.

Zahed: You're right. My thinking was that we don't need a full and complete
list of milestones. It's clear we need this bis work to be done to do anything,
so we can start with that. The last sentence is supposed to mean that we're not
going to keep this open if the WG doesn't add new milestones. If this bis gets
done and nobody comes up with anything else, we'll close it. That's the
intention. Lars, what you said about the discrepancy between what the charter
is describing and it's not clear what we want this WG to do, that's a valid
point that we can work on. I understand that better.

Roman: I didn't block, but I put it as a comment. I'm not concerned about the
number of milestones, but it'd be helpful if the milestones were
representative. I see two buckets: the document update, I got it. Then there's
a very vague charter that covers everything I could think of, not being an
expert in congestion control; basically everything is in scope but it doesn't
look like there's any kind of followup plan. One management approach is to just
scope it as something else, but if there is congestion control to work on, it's
not so credible to make it within scope if you can't at chartering time say
that there's at least one instance of this very broad thing to work on.

Zahed: As Martin was saying, the aspiration is to work on this bis and in the
next couple of years the community will have matured a congestion control
algorithm that they'd like to put in standards track and publish. That was the
intention. We can say let's scope it down to just this bis and recharter if
there is more to do. I'm fine with that approach.

Martin: We can certainly turn this into a charter just for 5033bis but I think
the upshot of that is if there are other proposals that aren't blocked by
5033bis, they would then have to come back and recharter possibly in 3 to 6
months. We want to move forward on 5033bis so we need to have this chartered,
but I suspect other things are going to come in this area. We can do that rapid
recharter; it seems a little heavy, but if the IESG isn't comfortable giving
this WG this broad a scope without having specific documents in mind right now,
we can do that. This is kind of a long lived WG charter even though we're open
to the possibility that we can just shut it down after this one work item if
things don't materialize.

Zahed: My takeaway is the charter is too broad and if we don't see something
coming up while we're chartering, it's not worth putting in the scope. That's
kind of disappointing to the community because the congestion control work
itself is long lasting and I'm not sure when it's going to be in a mature
state. If you are in a mature state in 3 months from now, we might need
immediate rechartering to adopt any of this work. I'd love to see a broader
charter and put something in there that says if you're not adopting new
milestones this will be done. Let's see what the community thinks about it;
I'll work with the chairs. Now the other point is the name.

Rob: Just to go back on that. I quite like the charter as it is now. It seems
to me that trying to bring the congestion control stuff into one central place
is a sensible thing. Going through two steps of chartering for this seems like
bureaucracy. That's just my view.

John: I was okay with it too on the balance. Especially if that last sentence I
objected to gets turned into either "find some more milestones or close," that
seems enough for my purposes.

Martin: We certainly could rewrite that sentence to say what you just said. We
could do a low effort fix for that block. The question is to Paul and Éric, do
you want us to just make it 5033 and come back later or is this just a matter
of wordsmithing?

Éric V: You may want to do wordsmithing. The bullet points are not really in
scope but will be taken into account for rechartering, something like that.
Rechartering is easy, you just push a button, and nothing is preventing you
from working on individual drafts already. In some areas we need to be very
strict regarding the charter and in others not so much, so we need to get the
balance right.

Rob: Another question to ask here is, is this bringing new work into the IETF
or just moving existing work that's chartered in other places into a central
place?

Zahed: It's both. The bis will be the new work we need to do but also it's
trying to gather all the existing things happening in ICCRG, like that. We can
take on that work. If we don't put it in the text here this is only a bis
charter. That was the intention here to be both.

Martin: In terms of the kind of work that will come in, there are basically two
kinds. There's work that is blocked by 5033bis that will require a new
evaluation framework to move forward, which obviously can't be started until
we've gotten far down the road of this milestone. Then there are things that
are not necessarily blocked, Gorry has a document about advice about congestion
control that would fit nicely here. I don't think we're ready to adopt it or
put it in the charter. We could do this either way and I'm hearing support from
both sides; one is having a broad long lived charter with a clause to close, or
just focus on 5033bis and recharter as work comes in. Éric is suggesting that
we do the latter and Rob and John are maybe more comfortable with the former.

Zahed: What we can do is write clearly that we're going to do this bis work and
the rest of the bullet things we can discuss.

Martin: If that's the clear direction from the IESG, that's what we'll do.

Rob: If you do that I have no objection to having typed a charter, I'm just not
sure it's necessary.

Zahed: My proposal is to do another version and see if we satisfy most of you.
Does that make sense going forward? The other thing is the name. We discussed
the name. I kind of like CONGRESS. I haven't seen the community reacting to the
name. I'm not sure what is the clear miscommunication with the name. As most of
my colleagues here are not happy with the name, I'm willing to change it. I'd
really love to call it CONGRESS. So action points on us, we'll rewrite the
charter and also try to find a new name.

Martin: It sounds like the IESG liked ICECREAM?

Lars: You'll have to bring ice cream to the first meeting if you do that.

Amy: I don't have this going anywhere yet, we're just waiting for instructions
from you, Zahed. If you're going to change the name and acronym I suggest that
happen before this goes for external review.

Martin: We'd have to change the mailing list too. How hard is it to just copy
all this over and change everyone from one list to another?

Cindy: It's doable but it's not straightforward. We have to create a new
mailing list and re-subscribe everybody, and frequently people don't want to be
automatically subscribed to something new, so that needs to be communicated in
advance and then the old list has to be closed down.

Martin: Paul, is your objection serious enough that we should go through that
effort?

Paul: No, I guess not. I don't think ICECREAM is a better name either. I'll
lift my Discuss on the name.

Lars: I'd really suggest we rename it. I think it's going to set us up for
persistent confusion, especially with people that don't understand the IETF.
it's a cute acronym but anything other than that is better.

Martin: Okay.

Zahed: I understand but I don't personally agree. In a lot of places congress
doesn't mean anything.

Lars: In a lot of places it does, though.

Zahed: All right, we can change it. Let's not use more time on it now.

4.1.2 Proposed for approval

 o Static Context Header Compression (schc)

Amy: I have no blocks on this, so unless there's an objection now, this WG is
approved.

Éric V: Erik, you proposed a comment and it's already there in the -01. Paul,
[something in Dutch]. SCHC should be pronounced like French.

Amy: Okay, so this has everything we need. We have a new WG.

Lars: I have a question, are they meeting?

Éric V: They are meeting in the sense that it's the same group of people as
LPWAN. On the agenda is the LPWAN meeting.

Lars: You might be able to do a joint slot if you want to. I'll leave it to you
to figure out.

Éric V: If it's easy to meet as well in a shared session, let's do it.

Liz: We can only have one Datatracker session and one WG meeting host at a
time, but I can add a sub-heading note on the agenda indicating it's joint with
both groups.

Éric V: Okay, that's great. Thank you.

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

Lars: The IAB had a tech talk yesterday which was quite interesting, from Micah
Beck talking about this notion that you want to have very weak semantics in
terms of consistency and reliability if you want to build a ubiquitous
communication service, and there's a tradeoff between the stronger you make
your guarantees, the harder it is to deliver your network. He's basically spent
his entire career on this. It was a pretty nice talk and I wonder if there will
be some IRTF related work started. That's what I remember.

Mirja: Nothing else exciting.

6. Management issues

6.1 [IANA #1267642] Remove 84/TTP from Protocol Number Registry (IANA)

Amy: You started a discussion on this at the informal last week but I think
Sabrina was going to come back with some information.

Sabrina: I think that's for a different thing. We just wanted to confirm it
here for this one.

Amy: Right, confirming that the IESG wanted to do what you suggested.

Lars: Remove it and add a footnote, I think that's what was suggested that
everybody agreed with.

Amy: So we're just minuting that. Do you need an official note from us, Sabrina?

Sabrina: Yes please.

Amy: Okay, we'll send one.

6.2 RFC 8989 Year Two Report (Lars Eggert)

Amy: Lars, you added this to minute the decision on the draft text.

Lars: Yes I did. I just now looked at the Google document and it's still clean,
so there are no additional comments, and enough people have read it and
commented that I think we can go ahead. If you recall, this was the report that
Rich Salz has written and decided to publish this as an IESG statement because
that's what 8989 requires but basically add a note at the beginning to say
these are Rich's words. If you all agree, I'll have Greg make the webpage out
of it. Okay, I'm not hearing any objections, so let's do that.

Amy: To confirm, you want that sent as an IESG statement by email as usual?

Lars: We need to publish it as an IESG statement. We published the last one as
an IESG statement so it's consistent. It's a little unusual because it's not
written by an IESG member but I don't think anything prevents that. If you
want, I can give you some words to put into the announcement to make that clear.

Amy: Usually the announcement is short and just has a link to the webpage.

Lars: Okay, it's fine to do the normal thing then.

Mirja: Why is this a statement and not just a blog post? The only requirement
is that we have to publish something somewhere, right?

Lars: I think we can do a blog post. I Think it would be consistent with what
we did in the past, which was an IESG statement, right?

Mirja: But if it's not something the IESG actually wants to state to the
community, publishing it in a different format is fine.

Lars: It would be fine but then we'd have two reports on the same thing show up
in two places in the website, which is confusing.

Mirja: Not really, it's more or less the same place.

Lars: I don't think so. If I look at IESG statements I only see IESG statements.

Mirja: But it's all the same framework. Or you could publish a statement just
saying there's a blog post. Whatever.

Lars: Does anybody else care?

Mirja: The only thing I was caring about is that it's a little weird to have a
statement that's not really from the IESG and that the IESG doesn't really
stand behind. But it's not a real problem.

Lars: Let me see what 8989 actually says. It says the IESG must publish a
report.

Rob: I wasn't completely listening, but isnt an IESG statement going to sit
there forever as a list of things the IESG has made pronouncements on? If so,
that doesn't seem that helpful, and a blog post would mean it's done and goes
away.

Lars: Should we then republish the last one as a blog post?

Andrew: For consistency, that might be worth doing.

Rob: The IESG statements sometimes sit around for a long time and people refer
back to them. Some of them are useful, and some of them are point-in-time
things that probably would be best removed. I guess it's a different act for us
to go through statements and move ones that are no longer relevant to a
separate page.

Mirja: I agree the last one probably should not have been a statement but it
doesn't really matter.

Rob: I don't really care.

Lars: I'd suggest we do a statement for consistency. If we move the old one
that breaks URLs and might raise questions. Let's put it out as an IESG
statement as we discussed and we should talk later about the cleanup of old
statements.

6.3 [IANA #1268218] renewing early allocation for RFC 8111 (IANA)

Alvaro: Two things. One, we should renew this. Two, for background, it's an
early allocation to an RFC which is weird; we usually allocate to drafts. The
registry here is specification required, but this RFC is experimental. So LISP
has been working on all its documents and this one is next on the list.
Hopefully by next year they'll have a standard version of this document and we
won't have to do early allocations anymore.

Amy: Any objections to approving this early allocation renewal? I'm hearing no
objections, so this is approved and we'll send an official note to IANA.

6.4 Designated experts for draft-ietf-lsr-flex-algo-25 (IGP Flexible Algorithm)
[IANA #1266560] and other registries (John Scudder)

Amy: John has suggested Les Ginsberg, Chris Hopps, and Hannes Gredler for all
of these registries. Is there any objection to approving these experts for all
of these? Hearing no objection, so we'll send an official note to IANA.

6.5 Draft consultation on Removing Mask Wearing Requirement (Jay Daley and Lars
Eggert)

Jay: Sorry for doing this so late. This is for IETF 117. This is a very simple
proposal that from 117 onwards we drop all masking requirements and we revert
to doing what we are required to do. It originally said the word "legally" but
we've taken that out and just said required, because it could be the venue or
the local regulations. There's a bit in here that recognizes some people will
be excluded and as a result we will continue to invest in remote participation.
Otherwise this is pretty straightforward, that we revert to local regulations
from 117, continue to provide free tests and free masks for 117 and 118, but we
stop that at the end of the year. I'd like to get this out tomorrow, but if you
want more time because I've left it so late, we can do it a bit later.

Rob: Reading this now, I think it's all fine but I wonder if it's worth
emphasizing that folks are still welcome to wear masks if they wish to do so.

Jay: I could do. We've said we will continue to provide free masks and we can
welcome people who wish to wear one, I can do that.

Éric V: I just wonder about the timing of it. Do we need to issue this survey
this week or can we do it during the week of the IETF?

Jay: I'd prefer to get it out now because there are, as you know, some
particularly vociferous anti-mask people. Getting this out now might just calm
them down, and then it means that the consultation finishes two days after the
end of the meeting so when we open for 117 we have time to adjust the
documentation and registration.

Andrew: If we are going to release this now, it's worth including an explicit
note that we are not changing the rules for 116 as some people on the list seem
to think is a good idea. If we're going to release a statement now we need to
explicitly say that 116 stands.

Lars: We can put a pointer to the 116 announcement that went out today in there
and say this is about 117, see here for info about 116.

Jay: I don't mind doing that, but do you really think anyone will misread it?

Andrew: I think one particular individual is going to try to misread it.

Jay: I don't mind putting it in if you think it needs it, but it's fairly
carefully worded. I don't want to confuse people either.

Alvaro: You mentioned something about registration for 117. How long after
Yokohama is that? Most of the time when we do document last calls and things
during the meeting, we extend the period a little more because people are
traveling and may not read their email, etc. I'm wondering if there's time to
make this consultation another week longer.

Jay: That is possible, I think.

Amy: In the important dates the week of May 1 is when registration is supposed
to open.

Jay: Oh, so we have a whole four weeks. Then yes, we can absolutely extend it
by another week.

Rob: Presumably then we'll also ask about masks in the post-meeting survey?

Jay: No, I wasn't planning to. I was rather hoping this would all go away. If
we ask it in the survey it's because we want the information for some purpose
and I'm not sure what that purpose would be.

Éric V: If one survey contradicts the other one, what happens?

Rob: I was just checking that there aren't two surveys asking similar questions
at the same time.

Lars: There are multiple rationales for this proposal. One is that it's being
in line with local regulations and not anything more. It's also that the
negotiation of these extra measures requires a lot of administrative overhead.
Any additional measures we impose also cause us some work. That's a reason to
give that up. Even if the survey results would indicate that a few people want
to keep the masking policies in place, we'd need to ask if it's worth it given
the operational costs. And the real costs, because tests and masks are not
cheap.

Jay: I've deliberately not given a reason as to why we're doing this.

Lars: I don't want you to add it, just in response to Éric I was saying there
are multiple reasons.

Éric V: I would love some time to review the text.

Jay: If we can go longer, we can easily leave this until Tuesday or Wednesday
of next week if that's helpful.

Éric V: And the results will be published, I imagine? Should the text say
anything about a majority, if 51% say no masks we go to no masks? What will be
the metric used to decide?

Lars: It's not a vote, we're asking for feedback. It's not just quantity but
quality.

Éric V: Is the survey text clear on that? I haven't read it.

Jay: It's not a survey, it's a consultation on a proposal to drop these things.
Generally when we take a position like this we would amend based on feedback
but we'd only withdraw based on strong feedback and I don't think we're looking
at strong feedback here. I'll aim to send it on Wednesday then and I'll update
the text based on feedback and give some extra time.

6.6 Statement to the ITU on APN (Andrew Alston)

Andrew: There is a Google document on the IESG list. My recollection of this is
that we came to agreed wording and then the IAB was going to work on it. Then
they approved it but there are a whole bunch of other comments in here. Rob has
said I can clear his stuff, which means I can accept Mirja's suggestions in the
document. The only thing left outstanding then is between John and Warren and
I'm not sure what you want me to do there.

John: I'm not in front of a screen right now. Can I get back to you when I get
back to my desk?

Andrew: Sure. Does anyone else have any other comments before we close this?
Okay, I'll go with silence gives consent. John, I'll sort out your comments and
then I'll get it to Scott.

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

Éric V: If you remember, on last week's informal I was talking about other SDOs
regarding DRIP. I sent mail to IANA and Sabrina confirmed they are working on
it, so I expect to get more information soon.

Andrew: And one note from me, it seems that the MSR6 guys are going WG
shopping. I've set up something with them to take stuff to BIER first so we can
continue. They tried to get slots on the SPRING agenda but were rejected based
on the fact that there is work going on with BIER to sort that out.

Francesca: I also wanted to mention that I've started the rechartering process
for SEDATE. It's a very minor rechartering and it's on the agenda for after
IETF 116. Also, as a reminder, I'll be gone on parental leave right after IETF
116 for five months. I have started the process of informing chairs and
reviewers and everyone and I'll probably reach out by email for documents that
need shepherding. I started making a list that I can share with you. I probably
will need some volunteers and thank you in advance.

Roman: In the spirit of WG news, I've signaled to I2NSF that I'm closing them
after their next two work items, which should be coming to the IESG right after
116.

Andrew: I'll be adding one more document to the next telechat and that will be
the end for SFC as well.