Minutes IETF111: iabopen
minutes-111-iabopen-00

# IABOpen at IETF111

When: Thursday, July 29, 2021, 16:30-17:30 UTC-7

Chairs: Mirja Kühlewind, Jared Mauch

## Welcome and Status Update (10 mins) - Mirja/Jared

[Slides: Status
Update](https://datatracker.ietf.org/doc/slides-111-iabopen-status-update-jaredmirja/)

- Document Updates
-- RFC 9075: Report from the IAB COVID-19 Network Impacts Workshop 2020
-- Approved for publication: draft-iab-arpa-authoritative-servers: Nameservers
for the Address and Routing Parameter Area (“arpa”) Domain -- Close to
publication: draft-iab-use-it-or-lose-it: Long-term Viability of Protocol
Extension Mechanisms (in EDM) - Program Updates -- model-t

## Evolvability, Deployability, & Maintainability (EDM) Program (10 mins) -
Tommy

[Slides: EDM Program
Update](https://datatracker.ietf.org/doc/slides-111-iabopen-edm-program-update/)

- Documents under consideration
-- draft-iab-protocol-maintenance
-- draft-iab-use-it-or-lose-it

Jeffrey Haas: One of the headaches is that extensibility is hard to prove until
you've tried to do the first version of that extension. BGP being a flexible
protocol,, we have to do a lot of inner work to make sure you can do the next
thing for the extension. One thing I would encourage is to find a way to prove
out the n+1 case.

Bob Hinden: We have a lot experience in IPv6 with extensions headers,
hop-by-hop headers, and it's not been a wild success. I think the particular
problem in hop by hop headers, but the worst is middleboxes that filter and
don't want to look at the whole packet. It's a really hard problem and I am
supportive of this work, but it's going to be challenging.

Eliot Lear: I had a look at this draft when it initially came out, and I
reviewed it again. If we didn't have the reserve space, I'm not sure we'd know
what to do about multicast. I think what you've done in the IAB in this doc is
more applicable at the upper layers than the lower ones. It's hard to know
what's in use where. I think it's worth developing that concept a bit in your
work.

Toerless Eckert: I think it's good getting that example with the multicast. The
layer difference between 3 and 4 is probably the unit of time that is in the
time of "use it" may be orders of magnitude larger. Putting the undesirable
middleboxes out of scope, maybe then we can figure out if it's p2p or multicast.

Tommy Pauly: In previous calls, we did talk about the nature of the problem and
what "use" means is different at different layers. I think that's something we
can capture.

Martin Thomson: The draft intro addresses this; it's predominantly at higher
layers of the stack. We do have some examples at lower layers, but they are not
necessarily very good. The IP extension header discussion is an ongoing one
that I don't think we can really draw from at this point. I think we're getting
there, but I am not enthusiastic about trying to formalize the difference. One
thing is that the cadence at which updates occur may shape the response you
have, but that doesn't mean they are fundamentally different.

Bob Hinden: I think a way to characterize this is, it's much easier to update
or extend when you only have to change 2 hosts. QUIC is a good example of this.
It's harder when you have to change everything along the path in order to do
it. It's not layering, but how many things have to change. With VRRP, it's 2
boxes. For IPv6, you have to do it globally. There is different kinds of
scaling to think about here.

## Updates on Liaison Management (10 mins) - Tommy

[Slides: Liaison
Coordination](https://datatracker.ietf.org/doc/slides-111-iabopen-liaison-coordination/)

## Considerations on Application - Network Collaboration Using Path Signals (10
mins) - Jari

[Slides: Path
Signals](https://datatracker.ietf.org/doc/slides-111-iabopen-path-signals/)

- draft-arkko-iab-path-signals-collaboration

Adrian Farrel: Thanks, that was helpful and clarified a lot for me from the
draft. In slide 4, there were 2 things that struck me. One was that the middle
box (of the chart), the info that is needed for the task is a really dangerous
door to open, because one person's need is another person's bad idea. That
leads to the consent of parties thing. We see that with the geolocation stuff.
An application's decision is not the same as user consent, and user consent
isn't necessarily the user understanding what they are doing. Please bring
these thoughts to the APN BOF, because it's pertinent.

Jari Arkko: Yes, that was one of the inspirations for this.

Toerless Eckert: It very much looks like what is important but difficult is to
make these work over the most difficult scenario, so it would be useful to have
a list of different categories of scenarios, from everyone trusts everyone, to
the open Internet. We've done a lot more security for these limited domain
networks, the ANIMA work, hop-by-hop link encryption, secure nodes. There are a
lot of options here and would be nice to not only focus on the ones for the
Internet. Humongous number of private and limited use domain networks.

Jari Arkko: There is something here about the future that we need to do as
well. Thank you.

Jeffrey Haas: I think there is a place in between here that I'm not sure was
covered. Part of the problem for the signals is it's a matter of scoping. Many
are designed to go end-to-end and it may vary depending on where you are in the
network. Maybe that should be called out as an explicit point.

Ted Hardie: I want to talk to points also being made in chat. In a lot of
cases, when we are talking about path signals, we are talking about ones where
actions taken as a result of a signal are advisory, not a command. The decision
on what action to take is not set in stone. I think in a lot of the cases, what
we are trying to work out is what are signals that are useful to send across
the path, and are useful to both ends of the flow as well. The most
controversial one is the source quench issue; the Internet had it at one point,
but it was dangerous so it was dropped. In a well-constructed protocol, the
sending side will know that's happening at some interval and there will be a
withdrawal of consent. The question is, if you have a bad sender, is there any
advisory mechanism to send to the path to say this is being dropped? The
critical thing that stopped this work is it's difficult to know what signal you
can send that isn't subject to an injection attack. Letting the path know that
it's not an injection attack is very difficult indeed. It's an "area for
research" instead of "engineering" for a good reason, to figure out if there is
a mechanism to let those advisory mechanisms demonstrate that they can take the
action that they are claiming to take. That's why there's not a proposal I-D on
this yet. Thanks.

## Open Mic (10 mins)

Mark McFadden: I wanted to react to the characterization of Model-T. I went
back and looked and the last time the IAB convened a Model-T meeting was
exactly a year ago. In that year, the IAB hasn't convened a meeting, but
members of the community have worked on drafts. I think what is missing is
rather than an IAB review of the program, putting some energy back into having
Model-T meet. There are community members who are willing to contribute.

Mirja Kühlewind: That is true, the leads of the program haven't set up a
meeting and the IAB hasn't been much involved, but that is also part of the
review that the IAB wants to take, because an IAB program needs IAB backing.
It's not a pure community group; we need to have some interest from the IAB to
keep it driving. That's the purpose of the review.

Jari Arkko: I agree with the characterization that it's a leadership problem
for the program, and I'm part of the leadership there. So let's fix the
leadership and do something.

Watson Ladd: In Model-T, there was a big gap in participation, and discussion
has really dwindled, and there is little prospect of progress towards those
issues. I'd like to see some path forward before we say another round of
whatever is going fix it.

Jari Arkko: I also agree with this statement. I think there has been a gap on
what exactly it is we're doing. There is no progress toward a solution. No
agreement on what should be produced; there are many alternatives. I am in
favor of short high-level RFCs from the IAB. But there has been a lot of
interest in looking at the detailed technical solutions. But it's also a
problematic area, so many dependencies, and it's not an easy thing to tackle.
Part of this is baked into the problem.

Mirja Kühlewind: We didn't have an extensive report on this program because we
haven't had the IAB review yet, but we can report back next time and tell you
what we want to do with this.

(End of Open Mic)