Skip to main content

Narrative Minutes interim-2023-iesg-15 2023-07-06 14:00

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

Narrative minutes for the 2023-07-06 IESG Teleconference

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

1. Administrivia
1.1 Roll call

Andrew Alston (Liquid Intelligent Technologies) /  Routing Area
Jenny Bui (AMS) / IETF Secretariat
Jay Daley / IETF Executive Director
Dhruv Dhody (Huawei) / IAB Liaison
Martin Duke (Google) / Transport Area
Liz Flynn (AMS) / IETF Secretariat, Narrative Scribe
Sandy Ginoza (AMS) / RFC Editor Liaison
Jim Guichard (Futurewei Technologies) / Routing Area
Erik Kline (Aalyria Technologies) / Internet Area
Mirja Kuehlewind (Ericsson) / IAB Chair
Warren Kumari (Google) / Operations and Management Area
Cindy Morgan (AMS) / IETF Secretariat
John Scudder (Juniper) / Routing Area
Sabrina Tanamal (ICANN) / IANA Liaison
Amy Vezza (AMS) / IETF Secretariat
Éric Vyncke (Cisco) / Internet Area
Paul Wouters (Aiven) /  Security Area

Lars Eggert (NetApp) / IETF Chair, General Area
Roman Danyliw (CERT/SEI) / Security Area
Murray Kucherawy (Meta) / Applications and Real-Time Area
Francesca Palombini (Ericsson) / Applications and Real-Time Area
Zaheduzzaman (Zahed) Sarker (Nokia) / Transport Area
Robert Wilton (Cisco Systems) / Operations and Management Area

Justin Iurman
Lee-Berkeley Shaw
Greg Wood

1.2 Bash the agenda

Amy: draft-ietf-bess-evpn-virtual-eth-segment-11 came off the agenda. Any other

1.3 Approval of the minutes of past telechats

Amy: Does anyone have an objection to the minutes of the June 22 teleconference
being approved? I'm hearing no objection, so those are approved. I saw final
narrative minutes go through; any objection to approving those? I'm hearing no
objection, so we will get both of those posted.

1.4 List of remaining action items from last telechat


     o Rob Wilton to find designated experts for RFC 9390 (Diameter Group
       Signaling) [IANA #1275381].

     o Éric Vyncke to find designated experts for RFC 9374 (Hierarchical
       HIT (HHIT) Prefixes) IANA #1275380].

Amy: This is on the agenda as a management item to approve experts.

     o Murray Kucherawy to find designated experts for RFC 9122 on IANA
       Registry for Sieve Actions IANA #1275603].

     o Roman Danyliw to find designated experts for RFC 9393 on Concise
       Software Identification Tags [IANA #1275658].


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

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

Warren: Still in progress.

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

     o Lars Eggert and Martin Duke to rewrite IESG statement to give more
       guidance about issuing LOIs for interim meetings.

     o One AD from each area to diagram their Area topology and send it to
       Martin Duke for collation.

Martin: I did get something from Éric, thank you Éric. Hoping to bring
something to our Sunday meeting at 117. The more information the better, but
having INT and Transport is enough to at least do something.

Éric V: It took me literally five minutes to do it.

Amy: Thanks Martin. You can pop it in the wiki as an agenda topic for 117.

     o Roman Danyliw to open a Datatracker issue suggesting a feature to
       better signal individual contributions

     o Martin Duke, Zahed Sarker, and John Scudder to work with Jay Daley
       and Brad Biddle to come up with canned IPR Disclosure text and
       possible proposals for other updates.

John: I think Jay sent an email closing that. Basically we decided there's
nothing to see here.

     o Lars Eggert to ask the LLC to come up with a proposal on how we can
       support a pre-configured remote participation option in side
       meeting rooms.

Amy: I know the Secretariat is looking into options for this, but we'll leave
this in progress for Lars so we don't lose it.

     o Lars Eggert to write an update to the Support Documents in IETF
       Working Groups statement.

     o Murray Kucherawy to respond to the email "RFC 1952: Any plan for a
       new extra field registry."

     o John Scudder to collect AD qualifications for NomCom.

John: I haven't checked in on the Google doc so I'm not sure. If you've looked
at the qualifications for your area and you think they're perfect, please leave
a comment in the document.

2. Protocol actions
2.1 WG submissions
2.1.1 New items

 o draft-ietf-sfc-multi-layer-oam-27  - IETF stream
   Active OAM for Service Function Chaining (SFC) (Proposed Standard)
   Token: Andrew Alston

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

Andrew: Can you put this in Revised ID Needed so I can make sure some comments
are addressed?

Amy: Okay, this will be Approved, Announcement to be Sent, Revised ID Needed.

Andrew: This is the final SFC document and SFC will be closed in the next day
or so.

Amy: It does have a downref to 7665, should we add that to the downref registry?

Andrew: Let me come back to you on that in the next couple of hours.

 o draft-ietf-spring-sr-replication-segment-15  - IETF stream
   SR Replication segment for Multi-point Service Delivery (Proposed
   Token: Jim Guichard

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

Jim: I'm not sure, to be honest. Right now I'm not sure how we move this
forward but it's a bigger issue because I'll get blocked on pretty much every
SPRING document. I think we need to have a wider conversation about that.
People are unhappy with the security of SRv6 and I don't know what to do about

Éric V: I can only suggest that you write a document about the security of SRv6
just to raise the issue.

Andrew: The limited aspect of this refers to filtering at the edge. I'm drawing
up a survey that will go out to NANOG, RIPE and some others, asking about what
filtering is actually being done and whether or not this is considered a viable
option. That will also give some guidance as to what the real status quo of the
current security posture is. That may help guide us. As i said the issue is if
you've got a serious security concern, something has to be done about it. What
that is, open to options. I've put one suggestion forward and I'm not tied to
it but something has to be done.

Warren: I agree that something has to be done. Something that could be done in
the meantime is many of the SPRING/SRV6 documents the entire security
considerations section seems to say there is no problem here. I think if the
security considerations sections in the documents were better/more complete,
that might make the documents easier to swallow. The risk from having a
replication service is larger than just having a regular SR routing service
because it can be used as a DOS amplifier. But the security considerations
section says that some other document says this can only be used in limited
domains and it's safe. That might be something to talk to SPRING about.
Pretending there aren't security problems doesn't make the document progress
better. Clearly documenting the risks is a better strategy.

Jim: I don't think more words are going to fix this. That's the problem. Sure,
I can push on the authors to put more words in the security considerations that
perhaps take care of Erik and Roman's DISCUSS, but it seems pointless putting
words in there to say deploy this at your own risk. I don't know how to get
them to address the problem.

Warren: A couple of us have tried complaining and been told these aren't
concerns and I should stop raising them.

Éric V: That's why I say to have a draft documenting the security problems.

Jim: As you know I was one of the SPRING chairs before I was AD and we've tried
very hard to get a security document into SPRING and nobody's interested.
That's one of the issues, you can't make someone write a document even though
it's important to the chairs. We didn't think it was appropriate for the chairs
to do it themselves.

Andrew: If people want me to do it, I'm prepared to take large segments of the
trusted domain SRv6 document and paste them into a security concerns document
and put that out there. The reason I haven't done that is because I feel there
are people who really don't want that document.

Warren: PPointing out the security concerns is useful. If we publish it and
people say they're not willing to discuss those concerns--

Andrew: I'm quite happy to do that. The concerns are pretty well documented in
the trusted domains draft. If you'd like me to paste those into a document I'm
happy to do that. Where would it go?

Warren: It depends. If it's just 'here are the concerns,' that's one thing. If
it's 'here are the concerns and the thing underlying it and how you could fix
it,' that's another thing.

Jim: There's a SPRING security considerations document that's been out there
for a long time, but we haven't gotten any interest in working on it.

Warren: That's very telling, the fact that this is a significant change to how
networks work. In many cases it's really interesting and useful, but the fact
that people are so unwilling to discuss the security concerns is an issue.

Jim: The problem is when you talk to the proponents they'll tell you that
they're deploying this all over the place and none of the operators they work
with have any concerns. It's hard to argue with that when you see deployments
going out.

Andrew: There are multiple operators on the SRv6 thread who clearly stated they
had issues, which was ignored by the vendors. When we tried to bring this to
discussion in V6OPS we were told it wasn't a V6OPS issue.

Jim: The operators who are making those comments aren't the ones deploying it.
I know of several very large deployments.

Andrew: This is where the problem is. You can't say that because someone said
it has a problem, therefore i'm not deploying it, that the problem isn't a
problem. Operators are prepared to say it's got problems, we've brought them
forward and they've been ignored, that's a condemnation of the IETF. That's an
even bigger problem when people bring concerns.

Jim: I'm backed into a corner here. They're not following the process. You
can't just go to a mic line and scream about an issue; if you have an objection
you should write a document, put it through the process, that's fine - but
that's not what's happening, I have nothing.

Martin: BEing unhappy with the direction of a WG and denying documents when
they come through is not the way to go. You should probably look at
rechartering this. One option is just to close it but to say this is what
you're going to work on and if no one's willing to do the work, we close the
WG. That's the way for the IESG to put conditions on what the WG is doing.
Today we have this relatively open charter that's letting them do what we don't
want them to do.

Warren: As Jim kept saying, there are people who are using and deploying this,
and I'm mostly fine with that. My concern is that these issues affect outside
networks. SR replication can convert an issue in one network into a big DOS
amplifier which attacks another. My concern on the earlier SR documents wasn't
just a concern that it might go poorly, but when an SR packet escapes the
network how do I trace it back to the source. If people want to deploy whatever
on their network, that's their choice, but the security considerations are
important for understanding the implications for the risk of the network. Words
might not be enough but from my reading of the security considerations, they
just say this only happens in a trusted domain. When i put my Abstain in i got
a reply saying how could it ever possibly happen that an attacker could have
access to a node in an SR network?

Jim: The issue with that one is that if you've got someone in the network,
you'v got bigger problems than SR replication.

Warren: That's true, but a fair bit of the SR architecture involves extending
it to your issues. People in your network is a serious issue but it's also
something we often cover in security considerations.

Martin: In the interest of moving things along, Roman's Discuss says to add
some words in here. If that can satisfy people then we should do it. I'd
suggest we consider rechartering or closing the group if that's what the
sentiment is.

Jim: I think we can address Erik and Roman's Discusses by putting some wording
in the security considerations, but with this particular document, I still
won't have enough positions to pass it. Unless Andrew or Warren is prepared to
move the Abstain, I think I'm in trouble on the document.

Martin: There's not a time limit other than terms rolling over. If in six or
eight months you can get yourself to ten, you can do that.

Jim: From a wider perspective I need to have a conversation with the chairs.

Andrew: i have a document in INTAREA right now where there are no technical

Warren: A lot of the tone of discussion has been really poor. There would be a
lot less difficulty in accepting some of this if it didn't feel as though it
was forced.

Jim: I'll talk to the chairs and I'll at least try to get these Discusses
addressed in the meantime.

Amy: It sounds like this document will need some work so we'll put this in
Revised I-D Needed and move on.

2.1.2 Returning items


2.2 Individual submissions
2.2.1 New items

 o draft-yee-ssh-iana-requirements-02  - IETF stream
   Update to the IANA SSH Protocol Parameters Registry Requirements
   (Proposed Standard)
   Token: Roman Danyliw

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

Paul: Maybe put it in AD Followup to give Roman a chance to check it?

Amy: We do that whenever someone isn't present, yes.

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-probe-attribution-07  - IETF stream
   Attribution of Internet Probes (Informational)
   Token: Warren Kumari

Amy: I'm going to set the Consensus for this as Yes. I do have a number of

Warren: I think it would be useful to discuss and we have one of the authors on
the call. Yes it's possible to do false flag attribution with this sort of
mechanism, however I still think it's better for someone receiving the traffic
to have some potential idea of what the traffic is than not. You can currently
already do false flag operations with spoof traffic.

Paul: This would be in the logs of people that would be specifically looking at
why someone is attacking you. The only thing they will trust is the IP address.
More or less everything else is untrustworthy data. I don't actually think this
adds anything, plus it can be a malicious source of information.

Warren: I agree the only trustable thing is the address, which is also not that
trustable. If I get a packet the primary thing I trust is the IP address but if
what's included in there is a link to a webpage which explains what they're
trying to do, I can at least have an idea.

Paul: What stops someone from using that pretty website link and pretending to
be them?

Warren: I'm not going to trust that packet based on that, but I can have more

Paul: Putting an IP address will give you a more reliable result than following
whatever the packet is telling you to follow it. But if the IESG thinks this is
not too bad an idea to continue, I'm fine with that and I can change my DISCUSS
to Abstain.

Warren: More information is useful, people shouldn't trust it blindly.  Even if
it's not trustable, it can be useful.

Éric V: Paul, I replied to you during your night so I'm not sure if you had
time to read it. Some people are testing BCP 38 anti spoofing filters. Honestly
it can be abused. Maybe in an executive session I can explain what happened to
me a few years ago which was basically raising the concerns in this draft. A
real serious issue I faced. A lot of people are scanning over the Internet, not
on a website, it's to see whether these packets are going through the Internet.
Some service providers are blocking it. Again, up to you, obviously.

Paul: It seems that HTTP was not really defined here. It seems to go on the
packet level, so maybe clarify that a bit more because to me that wasn't clear;
why don't you put something in the HTTP header if you want to do something in

Éric V: I will reply to you on this specific point; we tried to limit the text
and say it's only on layer three, but obviously we failed if you didn't read
that. We need to be clearer, point taken on this one. And a couple of other
points are valid, from you and Roman, and we will be acting on them. I would
love to turn yours to an Abstain so we get all the colors on this document.
Thanks for your time on this. And Paul, there is a paper presented on Monday
afternoon at ANRW that is a dissertation of this draft, if that is of interest
to you.

Amy: So it sounds like this will stay here and probably get a Revised I-D

Éric V: I think a revised I-D at least.

Paul: We've discussed this now so I can move mine to an Abstain. I'm not sure
about how Roman feels. I don't think it's harmful in a way I need to block it.

Warren: Okay, I think we have a path forward, we just need to chat with Roman.

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


3.4.2 Returning items


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


4.1.2 Proposed for approval


4.2 WG rechartering
4.2.1 Under evaluation for IETF review


4.2.2 Proposed for approval

 o Lightweight Authenticated Key Exchange (lake)

Amy: I have nothing blocking this recharter, so unless there's an objection
this is approved.

Paul: I think this is my first recharter; do I need to push any buttons?

Amy: You don't, but I do see a few comments here; if you want to spin a new
version to address those, I'll put this in Approved, Pending Edits, and you can
let us know when it's ready.

5. IAB news we can use

Mirja: The IAB is working on two new programs, one on identity management and
one on follow up from the E-impact workshop. The other thing we are discussing
over email is that we're working on outreach activities. We had a discussion at
the retreat and Dhruv is working on this and it's something we should discuss
with the IESG.

Dhruv: Let's have a discussion in the IAB first and then we can bring more
clarity to the IESG.

6. Management issues

6.1 [IANA #1275381] Designated experts for RFC 9390 (Diameter Group Signaling)

Amy: This has been assigned to Rob.

6.2 [IANA #1275380] Designated experts for RFC 9374 (Hierarchical HIT (HHIT)
Prefixes) (Éric Vyncke)

Amy: Éric has identified Adam Wiethuechter and Mohamed Boucadir; is there any
objection to naming these two experts? Hearing no objection, so they are
approved and we'll send that official note to IANA.

6.3 [IANA #1275603] Designated experts for RFC 9122 on IANA Registry for Sieve
Actions (IANA)

Amy: This one is assigned to Murray.

6.4 IANA #1275658] Designated experts for RFC 9393 on Concise Software
Identification Tags (IANA)

Amy: This is assigned to Roman.

6.5 [IANA #1274791] renewing early allocations for
draft-ietf-lsr-dynamic-flooding (IANA)

John: This document is coming up. I don't see any reason not to renew this and
I'd like to do so.

Amy: Any objection to renewing this early allocation? I'm hearing no objection,
so that is approved.

6.6 Appoint Wes Hardaker as ZONEMD expert (Warren Kumari)

Warren: IANA asked all the experts if they were willing to continue. ZONEMD
said they should have another one, and Wes said yes.

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

6.8 [IANA #1272387] renewing early allocation for
draft-ietf-bess-evpn-ipvpn-interworking (IANA)

Andrew: I had fairly long discussions with the BESS chairs about this. The
document itself is pending a negotiation between the IDR chairs and BESS. There
are implementations out there and I recommend renewing this.

Amy: Any objection to renewing this? I'm hearing no objections, so we'll send a
note to IANA.

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

Andrew: This is in my queue and there are implementations. I also recommend
renewing this.

Amy: Okay, I'm hearing no objections, so we'll send an official note to IANA.

6.10 Sunday Schedule at IETF 117 (Secretariat)

Amy: The IAB would prefer to have the afternoon slot on Sunday of 117, which
will give you the morning slot. Any objections?

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

Amy: There are only a couple of topics on the wiki for 117, so the Monday
morning meeting may not be necessary. Please add topics if you have them.

Mirja: The one joint item we have is Ryan from ISOC giving an update about the
policy program.

Warren: I managed to get open roaming working on my home network. I don't know
if anyone has any particular questions. I guess we are waiting for Lars to
decide [on the open roaming experiment at IETF 117].

6.7 Executive Session (Martin Duke and Andrew Alston)

An executive session was held.