Skip to main content

Narrative Minutes interim-2023-iesg-02 2023-01-19 15:00

Meeting Narrative Minutes Internet Engineering Steering Group (iesg) IETF
Date and time 2023-01-19 15:00
Title Narrative Minutes interim-2023-iesg-02 2023-01-19 15:00
State (None)
Other versions plain text
Last updated 2024-02-23

Narrative minutes for the 2023-01-19 IESG Teleconference

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

1. Administrivia
1.1 Roll call

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
Erik Kline (Aalyria Technologies) / Internet 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

Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Murray Kucherawy (Facebook) / Applications and Real-Time Area

Greg Wood

1.2 Bash the agenda

Amy: Does anyone want to add anything new to today's agenda? We have a new item
about retreat planning; anything else new? Any other changes?

1.3 Approval of the minutes of past telechats

Amy: Is there any objection to approving the minutes of the January 5
teleconference? I'm hearing no objection. I also saw final narrative minutes;
any objection to approving those? I'm hearing no objection there either.

1.4 List of remaining action items from last telechat


     o Francesca Palombini to find designated experts for RFC 8141 (Formal
       URN Namespaces, Informal URN Namespaces) [IANA #1263515]

Amy: Francesca, this is a new item for you. I think they suggested someone.

Francesca: Yes, I was trying to find the mail and I couldn't find it.

Amy: We'll see if we can dig up an email address for you, or maybe IANA can.

Sabrina: I can send it to you, Francesca.


     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.
       - On hold

     o Lars Eggert, Warren Kumari, Éric Vyncke, and Rob Wilton to discuss
       whether to reconstruct the document approval announcements to be
       more meaningful.

Warren: In progress.

     o Murray Kucherawy and Warren Kumari to coordinate with Barry Leiba
       and IANA about possibly updating text regarding IANA registries and
       expert review process detailed in RFC 8216.

Warren: This is in progress. I chatted with Barry yesterday and he's planning
on doing an update to BCP 26 anyway. We're thinking of something like "first
come first served but with documentation very strongly suggested" or something
like that. That's in progress and Barry is handling most of it.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-opsawg-sap-14  - IETF stream
   A YANG Network Model for Service Attachment Points (SAPs) (Proposed
   Token: Robert Wilton

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

Rob: I think so. I'd like to thank everyone for their reviews. I haven't
checked the last couple of comments that came in today so I think I'll just
check those first. I did see there was an updated version yesterday.

Amy: So it sounds like this will be Approved, Announcement to be Sent, AD

Rob: Yes, thank you.

 o draft-ietf-acme-subdomains-06  - IETF stream
   Automated Certificate Management Environment (ACME) for Subdomains
   (Proposed Standard)
   Token: Roman Danyliw

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

Roman: No we don't. We'll let the authors provide a response. Thank you to
everyone for their reviews, both for the Discuss and the comments. It'll need a
Revised I-D for sure.

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

 o draft-ietf-tcpm-rfc8312bis-14  - IETF stream
   CUBIC for Fast and Long-Distance Networks (Proposed Standard)
   Token: Martin Duke

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

Martin: It looks pretty clean to me, just a couple of nits. I'm sure we can get
those done without having to go through all the substates. Approved,
Announcement to be Sent, please.

Lars: There are two PRs coming, so this will need a revision.

Martin: Okay. Can we still make it Approved, Announcement to be Sent since
there are no substantive concerns?

Roman: It's my understanding that in the Datatracker if you make the status
Announcement to be Sent it will release the document to the RFC Editor. If
there are PRs waiting on the document, don't we want to get those in before?

Martin: Okay, Revised I-D Needed then and I can push the button when it's done.

2.1.2 Returning items

 o draft-ietf-ohai-ohttp-06  - IETF stream
   Oblivious HTTP (Proposed Standard)
   Token: Francesca Palombini

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

Francesca: I've seen answers for most of them. Éric, do you want to talk about
your Discuss about the charter?

Éric V: I read your email and replied a few minutes ago. It was pretty clear
and I remember discussion when we created the WG a couple of years ago that it
was not going through any web server but only modified web servers. Right?

Francesca: Right.

Éric V: And now with the combination of the relay and the gateway, basically
any web server can be reached and used through this. Which brings interesting
security properties, and it violates the charter, I'm sorry.

Francesca: The way I read it, and why I didn't have a problem with it, is that
I see this relay resource and gateway resource as logical entity. They can be
part of the server itself, so the gateway resource can be hosted on the server.
If you look at the example as well, there is one proxy that holds the relay
resource and then the actual server holds both the gateway resources and the
target resource. I didn't read this as this has to be different intermediaries.

Éric V: But it's nowhere in the document, and that's my problem. The
consequence with this, the protocol is there so someone can put the gateway
entity in any box over the internet, and then we can basically act as an open
relay to everything. If you have any kind of attack going from the client to
the relay, which is one party, to the gateway which is another party, to the
server which is a third party, you can run whatever you want like a DOS attack.

Francesca: Okay. Maybe we need to add more consideration about that.

Éric V: It's really really important. That's one security aspect. The other one
is that it really doesn't fit the charter, I'm sorry.

Warren: The more I think about that, the more I think I agree with Éric. It
seems like it needs a lot more discussion. As for the charter bit, I don't
really know because I didn't check.

Francesca: I hope the applicability statement in section 2.1 covered it. If it
doesn't, then we probably need to add something about this.

Éric V: The thing is that if we split, and I understand for writing a document
and for writing software, they split the target server and the gateway resource
in two when it should have been one, but it also means everyone now has the
keys to do whatever they want which is the part I don't like.

Francesca: I understand.

Martin: What's the threat model here, that there's an under-secured relay?

Éric V: A compromised client run through the relay and the gateway, which are
different parties, going to the target server. Target server, the only thing it
can do is run the IP address of the gateway.

Martin: There's language in there about the two relays policing this, right?
From clients?

Éric V: Policing is one thing, but if it's a single attack…policing is only
handling the DOS. A volume attack. What if it's a couple of low level attacks?

Warren: Also, yes there's language in there, but is it helpful to me if I'm the
person being attacked? If I'm running a web server and I keep getting annoying
requests from one IP address, I can block that user. If I'm now getting a bunch
of requests through a bunch of proxies, blocking the proxy presumably isn't
going to end well for me because that's not targeted to the abuser.

Martin: I see.

Francesca: I hope that this has been written this way for simplification of the
protocol, but that we can add text that will make it clear these are entities
that are supposed to be together. I see you shaking your head, Éric.

Éric V: Again, during the charter discussion, it has been very clear that this
technique cannot be used on any normal web servers. It only works for a very
dedicated one, and in this use case of the telemetry from Apple devices was
started when Chris was still at Apple. But it's no more the case in this

Erik K: Don't you need the DNS information for the target server? You need to
know how to encrypt a message to the target server?

Francesca: That's done by this gateway resource. Again, when I read this I read
it as this is all still at the server and this is one additional layer that you
have at the server. That's what you need for the server to support this HTTP

Erik K: This seems exactly as I imagined from the charter.

Warren: I think Éric was right, it was supposed to be used more for privacy
preserving and reporting and data collection.

Francesca: That should be hopefully clear in the applicability.

Éric V: The thing is that indeed, the technique and the draft can be used for
this very narrow use, but can be used for [something] much broader. That's
where my problem is coming from.

Warren: Saying something like here's a gun, don't use it for anything bad,
doesn't actually stop people from using guns for bad things. Here we're handing
people a potentially…we could solve almost all of the security issues on the
internet by saying "don't do anything bad."

Éric V: If I may, you want to put a limited domain on the application.

Warren: I kind of agree with that.

Francesca: Okay. I guess we can continue this by mail. I do hope there's a way
we can fix the document in order to make it clear how it should work.

Erik K: It's not clear to me that this does violate the charter. It seems to be
the intended purpose.

Éric V: They say one in the charter. The overall purpose is there; one
intermediary. Here we have two of them.

Francesca: These resources are not the same as full on intermediary or proxy.
That's what I was trying to say in my email.

Zahed: On the intermediary, I had a comment. It's not clear to me what the
intermediaries are. There was some text in the charter about it. In my
understanding this resource is a logical entity, not an intermediary that per
se we understand. This is not clear from the text and I'm listening to Éric
read it. It's not clear from the text they are a logical entity.

Francesca: That we can make clearer in the text.

Éric V: This is one part. The other part, if you look at the charter, you have
broad applicability, which is important, limited domain. It's "limited by
multiple factors, including the need for explicit server support of the
protocol." which is no more the case.

Francesca: If you consider that the target resource is what was originally the
unmodified server, that by itself will not work if you don't have the
equivalent of the gateway resource on the server.

Zahed: You need to have the target, um, hosting the target resource, saying a
particular URL or whatever it is that defines the resource criteria. if you
don't have it, It's not there. You cannot, you're listening for it to get any
kind of request. I'm split here. I understand what you are coming from Éric. I
think I have my mental map here that I might have missed. Reading it again, I
think that there should be a clear indication about your concerns. I think you
have a valid concern about the actual clarification part, but if it is
violating the charter, I'm not really sure, but obviously you need to work on
it to clarify this, francesca.

Francesca: I understand. Thank you everybody for the reviews. It's good that we
can have a conversation. This will need a Revised I-D anyway. We'll continue
this offline.

Paul: One second. Another issue that came up in this document is pretty minor.
The linkfest issue that every word is a link, and every link looks like an
external link to outside the RFC document. And there is an author that says
they will probably not fix it. Is this something that should be a concern to
the IESG in general? Do we want all of our documents to come in like this in
the future where every time people use "server" or "client" it links to a
section in the RFC? I'd really hate for this document to set a precedent.

Francesca: No, I definitely think it should be fixed. It's not easy to read as
it is with all those links. For the record, as I said, I don't think this is a
Discuss point but I think it needs to be fixed before publication.

Warren: One of the criteria for a Discuss point is about the quality and
readability of it. Some of it is also just the tone of the response of "No."

Mirja: Warren, I think you're over-interpreting this. He said he wouldn't fix
the tooling now, which I think is a reasonable response. What to do with this
document is a different question.

Warren: I didn't read it as 'wow, you've got a good point, I should make the
tooling better,' I read it as 'no, go away, I know best.' I guess the tone is
something I can just deal with.

Mirja: I think you're really over-interpreting it. He just said he wouldn't fix
it now.

Paul: No, he said something like 'I anticipate making no changes.' so he
definitely wants to push this through.

Lars: I'd suggest the AD checks with them.

Francesca: I will.

Lars: Finally, hopefully, there's one last thing about the downref to 9180. I
think that's the one Paul mentioned earlier that might be referenced by a bunch
of stuff so we should add that to the downref registry.

Francesca: Thank you for catching that.

Lars: It's a script, it's not me.

Francesca: Any objection to adding that to the downref registry?

Amy: If you want to add something to that, we'll need to know that at approval.
If the Datatracker didn't catch it, you'll have to call that out specifically
at approval.

Paul: There are two other documents in the queue with the same downref, so
it'll be a race.

Amy: Do you know if it was caught by the Datatracker in the other two
documents? Because a one-off is one thing, but if this downref wasn't caught by
three documents, that's something the Tools Team should know about.

Paul: It's an IRTF document, so maybe that's why it wasn't caught. 9180.

Warren: If the tooling isn't perfect now, maybe it's not worth too much time
now, because weren't we talking about changing the downref process?

Lars: That's been a longstanding issue. We're going to simplify downrefs
[eventually]. In the meantime, the review I have runs a different set of code
which finds some stuff the Datatracker doesn't. Even if we miss it this time,
my script will flag it next time. We don't need to spend more time on this.

Amy: Whichever document gets through first can call it out and then it will go
on that registry, so it may be a moot issue by the time this document comes
around to be approved. This document is going to stay in IESG Evaluation,
Revised I-D Needed.

2.2 Individual submissions
2.2.1 New items

 o draft-gont-numeric-ids-sec-considerations-10  - IETF stream
   Security Considerations for Transient Numeric Identifiers Employed
   in Network Protocols (Best Current Practice)
   Token: Paul Wouters

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

Paul: Yes, briefly. People are right, there was less consensus than I realized.
I think most of this will be fixed if we change the document to Informational
and also change the text so it doesn't look like everyone must do this before
publishing an RFC. Would that fix most problems?

Lars: I'm fine with the proposed text changes. Mirja is the person who knows
updates best, can an informational document update a BCP?

Mirja: There's nothing written down about it. I think there's an example for
every kind of update out there.

Alvaro: So if it updates 35whatever, what is the update? One of the problems I
have with this document is that the update seems to be that now we would
include considerations about identifiers in the security considerations.

Paul: I think the update goes away if we make this informational. Then it's
just saying you should do this stuff, it's good, but it doesn't really update

Alvaro: Correct. In my case it would help, but I don't think it would solve my
problems. I still think the document does not tell you much. It says sure, go
ahead and do something, but it doesn't really tell you what. I'm Discussing
mostly because if it's going to be a BCP, it needs to be very clear. If it's
Informational I wouldn't care so much and I'd probably abstain or something.

Paul: I think that this document is a little light on content is partially
because this document was split into three after earlier discussions. So all
the context from the larger document is missing from this document. I think you
do have to see it in the sense of that cluster of three.

Alvaro: And that's fine, but if the references to the other documents aren't
clear enough, it's not clear if that's the example we should follow. But if
it's Informational, my biggest concern, which is that it's not specific enough
to be a BCP, goes away.

Paul: I'll go back to the authors and see if we can fix this. Please put this
in Revised I-D Needed.

2.2.2 Returning items


2.3 Status changes
2.3.1 New items


2.3.2 Returning items


3. Document actions
3.1 WG submissions
3.1.1 New items

 o draft-ietf-opsec-indicators-of-compromise-03  - IETF stream
   Indicators of Compromise (IoCs) and Their Role in Attack Defence
   Token: Warren Kumari

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

Warren: Quickly, while Éric is still on the call. I think he and the authors
have something figured out. Once they address it with some IPv4/IPv6 stats, I
think it was, he's happy. Just to confirm that?

Éric V: Absolutely, where there are simply the statistics about the IPv4, the
IPv6 are also available. That's all I want and it's so easy to do. Revised I-D
and I'll put a Yes.

Warren: Excellent. Thank you, everyone, for reading it in the way this was

Roman: Warren, I'd ask if you could have the authors take a look at some of the
comments I had. I think the way they're framing things is a little bit
subjective. That's fine, if it's citable or more explained. I think I was
pretty detailed in pointing that out.

Warren: I'll ask them to have a look and I think they'll be happy to do so.

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

3.1.2 Returning items


3.2 Individual submissions via AD
3.2.1 New items


3.2.2 Returning items


3.3 Status changes
3.3.1 New items


3.3.2 Returning items


3.4 IRTF and Independent Submission stream documents
3.4.1 New items

 o conflict-review-irtf-nwcrg-tetrys-00
   IETF conflict review for draft-irtf-nwcrg-tetrys
     Tetrys, an On-the-Fly Network Coding Protocol (IRTF: Experimental)
   Token: Erik Kline

Amy: There are no Discusses in the tracker, so it looks like this response is
approved to go back to the IRSG.

Erik K: Zahed asked me to add another WG to the list, can I just edit that
right now? Will that cause everybody to have to re-vote?

Amy: No, you can go ahead and do that now.

Lars: The backstory here is that Tetrys is this network coding scheme that is
supposed to be IPR-free. I think IPR holders in the space disagree but it is
actually unencumbered.

Erik: I think that should be changed.

Amy: I see that we have added a WG. With the note that's currently in the
tracker, we'll send this back to the IRSG.

3.4.2 Returning items


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

 o Secure Asset Transfer Protocol (satp)

Amy: This was a BOF in the Security area and is now moving to ART and I think
Paul will be handing this off to Murray. I have no blocking comments for this
charter so unless there's an objection now, this can go for external review.

Paul: Wes did ping me a few minutes ago with some minor updates to make it more
readable, that aren't in yet. I don't know if that changes our process right
now or if that can go out later.

Amy: Do you want to make the changes? Since external review is approved, you
can either hold it until the changes are in the Datatracker and then we can
send the external review message after that, or it can go for external review
as-is and those changes can be made during the process. It's up to you.

Paul: Let's send it out then, we'll do it the second way you said.

Amy: Okay. Generally these get sent on Fridays, so this will go out tomorrow.
If you have the changes in by then, that's great, and if not, you can do it

4.1.2 Proposed for approval

 o Post-Quantum Use In Protocols (pquip)

Amy: I have no blocking comments, so unless there's an objection now it looks
like PQUIP is approved as a new WG.

Martin: I have a question. Are there circumstances where we would send a
document to PQUIP for review? Like, if we have new crypto we're baking, would
we want to do a post-con review, or is that not in scope?

Roman: That's a great question, and we talked about it. The easy answer is if
you have new crypto, we don't do crypto in the IETF. That's an IRTF crypto
panel matter. if you have an engineering conversation about crypto that already
got vetted by someone else, in a one-off fashion, yes. This WG is going to have
the aggregation of that expertise and especially if there's a lesson learned or
a pattern that would be great to have that discussion. But it's not going to
operate as a directorate. I asked that question when we did a side meeting on
it at 115, do we think we want that function. The consensus was we're not ready
for that.

Amy: Okay, PQUIP is approved and we'll get that sent tomorrow.

Roman: Thanks everyone for the review. We're ready to go with the charter, we
have chairs and a mailing list, and we're ready to go.

4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval


5. IAB news we can use

Warren: There was no IAB meeting yesterday; however, I believe the IAB has the
IESG slate from the NomCom so they will do whatever the IAB does and then pass
it back to the NomCom. That's the main IAB news. Also just a reminder about the
BOF discussions.

6. Management issues

6.1 [IANA #1263515] Designated experts for RFC 8141 (Uniform Resource Names
(URNs)) (IANA)

Amy: This is the action item we assigned to Francesca at the top of the call.

6.2 IESG Confirmation of NomCom selections for Trust and LLC (Lars Eggert)

Amy: This is just here to minute that you have confirmed the NomCom selections
for the IETF Trust and the LLC. Those are now public because the NomCom did not

6.3 Approval of updated IESG statement "Guidance on Face-to-Face and Virtual
Interim Meetings " (Lars Eggert)

Lars: I'm not quite ready to approve this, but if you scroll down the top part
is all fine. There's a bullet list where there's still some discussion. There
are also some wording changes I'll make afterwards. Zahed, you added that the
meetings shouldn't eliminate the need for in person meetings at an IETF. I
agree to some degree, in the sense that specifically in person interims
shouldn't replace meeting at the IETF, but in terms of virtual meetings I think
we want to give groups more leeway if that works for them. We should probably
say something that they should still try to occasionally meet at the IETF.

Zahed: I have been chair and also AD of TAPS WG, which has been making good
progress with interims and online meetings and now and then I have to jump in
and remind them that they should come to IETF week. Then some other groups like
TRILL, when they have a meeting during IETF they found it interesting that
people join even if they're first timers or newcomers, and they also get new
contributors and eyes on the documents. I don't think we should have some
statement saying if it's a virtual thing just do it whenever you like. We
should say something here that virtual meetings have practical benefits but
don't forget there's also benefit to the IETF week. I don't know how to do that
in a good way.

Alvaro: I made the comment that maybe this should be changed to say the meeting
should not be held for the purpose of avoiding the IETF week.

Zahed: You're not allowed to have virtual interim meetings during IETF week so
they all avoid it.

Alvaro: What I meant is that if you're having an interim meeting a couple of
weeks before the IETF, for example, that's fine. But for the intent of that
meeting to not have a meeting during IETF week. I'm starting to doubt myself
now. We want the WGs to make progress. How they make progress, I don't care.
Some WGs work better in a virtual way. Some people aren't ever going to show up
at IETF. Others will only make progress when they're there. For us to say don't
meet because we really want you to be at the IETF may result in limiting
progress. Even though I was suggesting to say you shouldn't meet for the
express objective of avoiding meeting at the IETF week, I think we should take
this out and let them meet whenever. If we have problems with any WGs the ADs
can address that.

Zahed: Then I actually miss calling it virtual interim meetings if we don't
care about having them come to IETF weeks. Then basically we're saying interims
are like regular IETF meetings that just happen to be another week. Why we're
making the distinction between a virtual interim and onsite interim is not
clear to me.

Martin: I think it has to be different for onsite because people have to choose
carefully about how many trips they're going to go on. It's one thing if you
need six meetings per year, but if you need three meetings per year and you
choose to do interims instead of IETFs, you're forcing many participants to
choose between going to interims and going to IETF. That seems like a real tax
on the community. Virtuals are obviously quite different; it's time, but costs
are not as large.

Zahed: I agree with that and that's where I'm coming from too. For onsite
meetings people are bounded by practical things. Perhaps we don't need to worry
about regulating that. For virtual, if we don't say anything and just let them
schedule whatever virtual interims they want, they might not end up having a
slot in any onsite IETF weeks. To be honest I think for virtual we should
understand the motive of it more. I have one WG chair who doesn't like
traveling and coming to IETF meetings. They just wanted to have everything
virtual meetings and it's very hard to convince them why they should come to
meetings. If we're going to have this statement we should cover those kinds of
things. Or we can just decide we don't care if they come to IETF week.

Warren: I have a number of chairs as well who are unable or unwilling to attend
a meeting. The meeting can still happen during the week and they can chair
remotely. A risk of having WGs only do virtual meetings or interims is that we
miss out on one of the big benefits of in person meetings, which is cross-area
and cross-WG pollination. SIDROPS never having physical meetings ends up with a
lot of siloing and people working without knowing what's going on in the rest
of the ecosystem. I support what Alvaro was saying; you shouldn't be using
interims to avoid actually meeting at an IETF, otherwise we're just a loose
collaboration of WGs.

Mirja: I wanted to slightly disagree with a few points that were made. First of
all I think it's great to have more virtual interims since the pandemic because
we can make more progress on some things. And meeting at an IETF week, if we
end up in a way that we can productively do our work without an IETF meeting
(which I doubt) then why have the meeting? If the WGs don't see a benefit of
meeting [in person] I'm not sure we need to push against it. What I did hear
though is that there have been a few cases where there's a preference from a
chair that's not interested in engaging in the rest of the IETF or traveling
and this preference from the chair enforces how the Wgs operate rather than
trying to figure out what the participants need. That's a chair management
problem. One more point; I think we should think about more actively
discouraging in-person meetings and doing virtual meetings. That means just
more travel. There's something different about needing additional meetings that
might be in person like QUIC. there might also be a point about whether we need
to have this in person or virtual. But what you want to say is rather than
traveling to 3 places a year just for this WG, it's better to travel three
places a year for the whole plenary meeting because that's less travel. I think
this is the real concern when you replace the plenary meeting with an in person
[interim] and then people just have additional travel. That should be

Zahed: I personally agree with discouraging traveling. If we can write
something about that it would be great. But I also don't think everything
should be happening virtually. If the WG wants and they have good intentions,
they can discuss with their ADs and then we know what's happening and why. The
WG needs to decide whether having everything virtually in interims is more
beneficial than meeting during IETF weeks. My mode of operation was that I let
them run everything in the interim but I'd like you to meet now and then, even
if it's virtually, during the IETF week. I'd like to enforce that somehow, not
control but some kind of awareness.

Mirja: I see the benefit of having this cross area review, but in a case like
TAPS which has been around for many years and has already had input from a lot
of people, encouraging them to use an agenda slot they don't really need
doesn't make sense.

Zahed: It makes sense to me, because when I forced them to do that, the
feedback was that it was great. I'm not here to force anyone but I want
something in this text to encourage them to meet during IETF week even if
everything is done virtually. Rather than every AD having their own view, if we
can agree on some kind of text to encourage them somehow meeting in IETF,
that's fine.

Lars: I think this is really a case by case decision that each WG and their AD
needs to take. We can't say anything in there other than something handwavy,
and in that case we might as well not do it. Whether you have a mixture of
interims that are in person or virtual, and/or happening at the IETF, it's up
to a WG and their AD to decide. Either we need to say a lot more than one
bullet point or I think we should cut this.

Zahed: We can cut it but I want to discuss it. I don't think there's benefit to
giving WGs the leeway to do everything virtually. I don't see the point. The
highlighted text there doesn't enforce anything.

Lars: If you have a WG that you think needs to meet, you can do what you did
and tell them to do it differently.

Rob: What if we just reword this sentence to just remind people of the benefits
of meeting in person?

Warren: this is a lowercase should not, it's general advice. Would it make
people happy if we tacked something on to the end about helping with cross area
collaboration if we want some justification? Maybe we have different sets of
views, but I think it would not be in the IETF's best interest if we only had
WGs meeting by themselves and doing interims, virtual or in person. A large
amount of the value of IETF is that people get together. The reason we all meet
together is there is value in that. Having WGs go off and do their own thing
without collaborating means that we don't end up with protocols that
interoperate well.

Zahed: You have a point. I know maybe one or two WGs doing this. But in the
future maybe a lot of them will and it will undermine the IETF meetings.

Warren: There are some WGs that don't really need to interoperate much with
each other because they're building their own little building block. If they
don't, it's not the end of the world. We don't have any force of law behind
this, it's a suggestion.

Martin: I'd be fine with striking it but I'm also comfortable with Rob's
suggestion that WGs should consider the advantages of meeting at IETF week,
blah blah.

Lars: I put a suggestion up at the top above the bullet list. Cut the stuff
before this and instead put the thing in red, possibly with Rob's addition.
Let's leave the special case of Covid out of this because it's general.

Zahed: I see the introduction of this. If you're comfortable with these lines,
why not put them in bullets? A lot of people will only read the bullets.

Lars: The bullets are specifically guidelines for interim meetings. This is a
guideline against interim meetings, kind of. I don't think it goes in the

Mirja: I would find it useful to say something like you should not have an in
person interim instead of going to the ETIF meeting because that adds
additional travel.

Lars: Okay. I'll wordsmith something and send a message to IESG when I think I
have a document that's ready to go out.

Warren: I think most of us assumed that WGs who had in person interims had so
much work to do they couldn't possibly get it done only at the 3 IETF meetings,
or they had something like a design team where they specifically wanted a small
set of interested parties to get together and chat.

Zahed: Lars, I think I buy your argument. That's fine.

Lars: Don't forget we're also in a situation where we're always low on agenda
slots. So maybe encouraging more people to come in person is the opposite of
what we want to do. But that's not for this document. I'll send around a link
when I've made some updates.

6.4 [IANA #1262465] renewing early allocation for
draft-ietf-pce-local-protection-enforcement (IANA)

John: This document is in pubreq, I just haven't gotten to it yet. We should
renew this, please.

Amy: Is there any objection to renewing this early allocation? I'm hearing no
objection, so it looks like this is approved to continue.

6.5 2023 Retreat Planning (Lars Eggert)

Lars: I sent around a poll with a lot of date options. There are some before
116 and some after, because we don't know yet how much churn there is going to
be on the IESG. Basically we're looking for three days. I forwarded this to the
IAB to suggest that if they want to we can collocate. Mirja and I will then
figure out what we have. I talked to Martin earlier and he said if we do it in
Seattle there's a good chance he can attend in person, at least mostly. I
haven't had a chance yet to talk to Francesca; Francesca, where are you in
terms of travel?

Francesca: I wanted to mention that I decided last week I'll have to be remote
for 116. I went back and forth but it's not possible. I filled in the poll and
there are some days I can do on a best-effort basis. Also starting in April,
I'll be on parental leave again until the end of summer. After that, depending
on NomCom decisions.

Lars: I guess even if we did it in Stockholm you wouldn't attend, right?

Francesca: Right.

Lars: That at least solves the problem of Stockholm vs. Seattle. If we can find
a week that works for Martin in Seattle that would be good; unless someone else
has travel issues I don't know about.

Martin: The next few months are a bit up in the air. Yokohama is probably not
going to happen but there's a chance I could buy a last minute ticket and show
up. If we do it here, it's just a question of getting people to drive the kids
around which I'm pretty confident I could do. I'm quite optimistic I could
attend almost all of it if it's in Seattle; if it's elsewhere, I would have to
do it remotely. Later in the year it's likely things will improve.

Warren: NANOG 88 is in Seattle from June 12-14, so if anyone wanted to combine
those that could be interesting.

Lars: Oh, that overlaps with ICANN [in Washington DC]. I have to be at ICANN.
Does anyone have any issues with Seattle or any other travel issues?

Rob: I'll have an operation that may stop me flying for about six weeks so
February [might be tough].

Lars: Okay, so fill out the poll and we'll see what happens. Next week also
we'll find out if there will be AD churn.

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

Lars: It will be announced soon but the social event in Yokohama will be on
Thursday, not Tuesday as usual. Basically it's going to be at a special venue
that's not open on Tuesdays and they won't open it for us. As soon as WIDE has
confirmed it we'll announce it to the community. I'm mentioning it to you
because you're probably already planning dinners and such.

Amy: A reminder that the BOF coordination call is set for February 1.

Lars: Looking at the BOF requests, there are two for DBOUND. Do we know which
is the real one? We don't need to talk about it now but maybe the ART ADs can
figure out what's going on there.