IAB Open Meeting - IETF108

When: Tue 2020-07-28 13:00 UTC

Where: [Meetecho]

Chairs: Mirja Kühlewind, Tommy Pauly

Note-takers: Wes Hardaker, Ben Campbell

Slides: slides-108-iabopen-iab-open-slides

Agenda

Topics

Welcome and Status Update (10 mins) - Tommy and Mirja

• Mirja presented the Note Well
• Mirja described the purpose of the meeting
  • increase IAB visibility
  • collect feedback
  • Focus on architectural and technical work of IAB
• Mailing list usage
  • Comments welcome on IAB and architecture discuss lists
  • use iab@iab.org for direct conversations
  • use program specific lists for program conversations
• Mirja summarised the IAB retreat
  • different organisation due to covid/remote participation
  • pre-thinking about trends, challenges, break-out groups to discuss topics (see slides)

Documents (5 mins)

• draft-iab-for-the-users - Mark

• draft-iab-dedr-report (reported on below)

• Three recently published RFCs

• Mark presents draft-iab-for-the-users

  • Document started in 2015/08
  • Approved by IAB in March 2020
  • Discusses how the IETF should consider users in its deliberations
  • In the RFC editor queue now
  • Next steps? open/ongoing discussion
  • Discussion:
    • Linda Dunbar Internet for end users "what does it mean" -what's special here?
    • Mark Trying to establish how, and to what degree we consider the end user, especially when in conflict to other goals/stakeholders. encouraged to read the draft.
    • Bernie Hoeneisen does this also include some stuff on the end-user side like UI/UX issues, what we have to better understand the end user?
    • Mark The draft doesn't address expanding scope of ietf work, or what we're good at or not. User experience is something we've been recidence to dive into in the past, unless there are overriding security concerns.
    • Bernie Security related, needs to understand what doing, what clicking on? is this 'on the IAB agenda'?
    • Mark Not currently now, but there is interest. There is expertise in many places besides the IETF.

Workshops (10 mins)

• DEDR workshop report - Jari
  • Design Expectations vs Deployment Reality worshop
  • Draft report available, please give feedback before it becomes an RFC.
  • Will be publishing the RFC soon.
• Proposed workshop on COVID-19 Network Impacts - Jari (November, virtual)

  • proposed workshop we're planning on sending, with a call for papers in a few days.

  • organizing committee includes a few people from the IAB

  • How has covid impact networking, multimedia, traffic. It will be interesting to review its impact. What has changed? How have organizations changed?

  • Goals

    • Understand traffic patterns and changes
    • How operators/service providers responded
    • Things they had to do
    • Understanding of what the impacts were
    • Learn for the future

  • Topics

    • Measurements
    • behind the scenes activities
    • Experiences for multiple applications
    • Lessons learned for operations
    • Lessons learned for technical architecture

  • Virtual workshop

    • Scheduled around different topics
    • Position papers due 9 October
    • Invitations by 15 October
    • Over several days in November (just before IETF 109)

  • Discussion:

    • Daniel Gillmor no reference to the organizational issues and how they have been impacted, nor privacy, is this because always under discussion?
    • Jari Those are good points, and certainly impacts we should think about. A good topic for position papers. I hope we get to discuss that too (personally).
    • Frode Kileng Any reason for "invitation only workshop" when it's an over-the-Internet virtual one?
    • Jari good question. Discussions are best had when participants are well informed. Position papers help us do that. Even though we're virtual, I hope we have free attendance to listen for anyone interested.
    • Mirja It's not a barrier to participate. Please write position papers. A smaller group brings a different discussion.

Program Status (15 mins)

• Recently concluded (see concluded program link at the IAB web)

  • privsec
  • IP stack evolution

• Model-t - Stephen

  • Not much to say
  • Hope to get it ramped up again
  • Had a call on April 20
  • Virtual meeting soon
  • Trying to be timezone friendly to au
  • Join the mailing list
  • Lots of drafts have been written
  • Trying to get together Thursday this week
  • Discussion
    • Dominique Lazanski lots of work discussed on these drafts already, and thanks to Stephen for organizing
    • Mallory Knodel why is there a taxonomy when there is work elsewhere on this?
    • Stephen Farrell that list of drafts is just the recent list discussed on the mailing list.

• Proposed Program on Evolvability, Deployability, and Maintainability (EDM) - Tommy

  • Note sent to arch-discuss
  • topic from retreat: What are the different issues we see right now?
  • This is the theme we came back to (EDM for short)
  • Most recently IP stack evolution about how hosts evolve
  • This will take the next step about how to apply them within the IETF work we do
  • And when doing practical work of designing the protocol, and is there a better way to create an architecture that scales and isn't hampered by ossification or because we don't have enough insight while designing
  • topics in scope:
    • Evolvability - A lot of work has already been done (e.g. use-it-or-lose-it or the protocol-maintenance draft), but they haven't been published yet as RFCs. Also work in WGs, eg quic with greasing to help it from becoming ossified. Recently, HTTP greasing has been discussed with large scale experiments being discussed. What are the extension points to a protocol. How do we communicate about them. RFC5507 discusses expanding DNS and what's the best way. The points that should be greased are the points we know. Many points are already ossified. Often this is not well documented. We should get in the practice of documenting how each extension point is evolvability. We need to define codepoint allocations for extensibility. New DNS record type (HTTPS/SVCB) where a lot of discussion occurred around IANA allocation to allow for better first come first serve. How can we do more of that?
    • Deployability - Making sure that things we have in theory really play out in deployment on the open internet. About how we do work in working groups and develop recommendations. Various WGs do this, but not in a standard way. We want to catalog various implementations we have, what versions are supported, catalog interop testing results. Do authors know the issues people are hitting. Where can we share information?
    • Examples - TLS 1.3 implementations page has interoperability support by various implementations. Quic also has a great page about its implementations and public servers. Those were official WG pages, but many others exist like HTTPS/SVCB on other github pages hosted by other authors. Quic has a large google doc that tracks all interoperability results on the drafts. Very helpful to see what protocol implementations are working well together. Important to determine what is being tested. All so far are github pages or google docs hosted by WG. They aren't easy to find (no datatracker links). They're not easy to replicate if a WG doesn't have infrastructure in place. They help determine deployability.
    • Maintainability - Even after a WG ships a protocol, how do we ensure the points of extensibility are used properly. Not always done as RFC content, but could be living documents as well (wikis, faqs). Don't have to be formal. Just a place to talk about issues would be useful. Community that comes out of a working group can be involved in this.
    • Examples - TLS working group website (again). List of implementations, how to do testing, etc. We'd love to see other protocols find this easier to use.
    • Tasks - We want representatives from IAB, IESG, tools team, broader community. Want to review successful models in working groups. And review where struggles have occurred in protocols being defined.
    • Output - write documents, hold workshops, build new tools, provide guidance for WGs and IETF reviews.

• Discussion

  • DKG put pointer to https://tests.sequoia-pgp.org/. Trying to define a high level API was super useful. IETF has not traditionally done this, but maybe we should think about APIs. Simple APIs that people can understand helps clarify goals of a protocol and helps interoperability.Not
  • Dan York Thanks. (Not speaking for ISOC). I think this is great. At the ISOC I've tried to help many people deploy protocols, and the only typical advise is "read the RFCs". That's hard for the average implementer. I think there are parts: 1) good work highlighted here for people to copy. WG github portals is good 2) Challenge is after RFCs are published. How do we help them there. How do the find it then? Discoverability is an issue, as its in different places etc. Getting to a place with a defined set of artifacts would be hugely useful.
  • Mailing list: edm@iab.org
  • Christopher Wood Supportive of this program. It would be nice if there was a common way to specify these resources.
  • Toerless Eckert Thanks to Tommy for starting this. Big can of worms. One of the main issues is figuring out the process. Seeing how things can be professionalized, but that's a cost for the tools team.

Open Mic (10 mins)

• Toerless Eckert Need to better extend IPv6, feasibility of programmable ASIC, etc. Rejected for IRTF. Where is the right place to do this work within the IETF? Could the IAB present a short statement about when to start new programs, etc.

  • Mirja I saw the email and will reply to it. We're discussing how to work on programs now. The general topic we don't have time to discuss right now.
  • Colin Perkins Had a brief conversation in the hallway in Singapore. Based on what I understood at the time I didn't see an appropriate research topic at the time. If you have a more detailed proposal on a different topic, but claiming the IRTF refused the topic forever based on a hallway topic doesn't feel right.
  • Toerless Eckert I felt architectural questions fell somewhere in between the cracks, and were 'not part of the discussion'.

• Benjamin Schwartz - Enjoyed session, found it useful and informative. Wortwhile endeavor. Agrees with Toerless on EDM topics. Maintaining interactive test points indefinitely is a daunting effort. Helpful if IETF or ISOC had support.

• Dominique Lazanski I appreciate the presentation and am interested in seeing the deployability and end points as well. in the chat we've been discussing the consolidation document and I wondered about future work

  • Mirja Still on the agenda. Jari is on IAB and can bring it back up at any time.

• Jim Reid - Thanks. This has been a very useful and very helpful session. A direct dialog between the IETF and the IAB directly is a very good thing.

• Mirja - wraps meeting. We plan to do this again, will consider how to continue. Mirja and Tommy thank the participants.