TAPS working group meeting IETF 106 Chairs: Aaron Falk and Zaheduzzaman Sarker Jabber Scribe: Theresa Note Takers: Sarah & Alexander & Dave 1. Agenda/Administrivia stuffs Doc status: Nothing published since last mtg draft-taps-transport-security last call Milestones: docs published in Nov 2019; propose to adjust to Q1 2020 supposed to conclude wg in Nov 2019; also to Q1 2020 Dec 2019: -arch to LC; interim call Dec 16 Jan 2020: -intf to LC, -arch revs; Interim call Jan 13 Feb 2020: -impl to LC; -intf revs; Interim Feb 10 Mar 2020: -impl revs; IETF Mar 23 Some debate about the need for interim calls, and timing - Brian Trammel - need the calls to spur the work getting done. Selfishly suggests push Jan & Feb calls one week each Theresa is ok w/ (pushed?) dates Anna Brunstrom: February 17 date is bad for me, whole week. Brian: Looks like we can't sort out a date for both Anna and me. Anna: How about Friday of week of Feb 17? Brian: Ok Gory: Hesitant that -impl will arrive in Feb Arch Interim call week of Dec 16 Interface interim call week of Jan 20 Implementation interim call week of Feb 17 Doodle poll to go out to confirm the day Theresa agenda bashing: let's start with security please Colin: back on the schedule: too aggressive Tommy: Should we not try? Aaron: trying to make up for letting it drag past couple of years Philip: Schedule is aggressive but at least doable for arch and interface; too much for impl PyTAPS presentation by Max Franke https://datatracker.ietf.org/meeting/106/materials/slides-106-taps-pytaps-implementation-update Gory: question regarding single source ASM groups Jake: regardless of whether there's one source or not, you'd be joining with an ASM join so if you can get the packets then you will. Colin: With this API is it possible to send without being in the joined group? Max: Well it's implicit not explicit Jake: RIght, the send doesn't requite it, just receive Colin: What about source filtering, does it handle it? Crowd not at mic: yes Tommy: Having framers in our implementation, it's a natural outcome, I don't think we should prohibit it (AMBI slide 7) Presenter: We can have text to make this clear Colin: I wonder if we don't have different views of what framers are. A framer seems to be more simpler than stated Tommy: The arch doc does have a smaller, tighter definition for framer. The interface might be the thing Colin is thinking of. Would prefer to keep the text constrained and perhaps have another doc that covers use cases and how to use them Brian: Is this a legit use of framers? It doesn't matter. Colin: We care, if there are going to be other extension points - we expect this to evolve, even if the resulting implementation isn't a framer by definition Philip: It would be helpful to add to the doc where we'd see the extension happening. For example, framers could have an extension point Anna: For the arch draft, we should avoid putting too many details into that, keep it at the concept level Aaron: the room agrees with you, lots of thumbs up draft-ietf-taps-transport-security by Philip https://datatracker.ietf.org/meeting/106/materials/slides-106-taps-draft-ietf-taps-transport-security - Review of slides (see above) starting with objections raised by Eric Rescorla and Christian Huitema Brian: Too ambitious a task? Aaron: Probably not effective to argue against ekr and Christian who aren't in the room. Brian: Right, I think we can move on to Criticism 2 (comment made on Criticism 1 Slide) Kyle: Criticism against API being used will be solved if someone uses it (or not) Tommy: Agree with that Magnus: Also agreed. Kyle: We added a goals.non goals section; one non goal was to assume security would be considered, and we need apps to explicitly choose a security protocol that fulfills their reqs. We're making it explicit. Theresa: The criticism existed due to the detail provided in the doc; we chose to remove that and replace with text that stats the app chooses whatever security protocol it needs - this should address the comment. Magnus: I don't see a problem, Theresa's comments are spot on Spencer: What Theresa said about pulling out the details was brilliant. This is chartered work and it was discussed within the IESG when we chartered it Chris: Don't see a need to split the docs Presenter: Me neither Gory: Agree, 1 doc and keep things together Aaron: (Chair Interrupt) - Doc shepherd could summarize the changes, send a pointer to the doc to Christian and ekr, allow them to respond, and we work with our AD on how to proceed after that. Give the commenter a chance to see that we understand their concerns. Magnus: Would be nice if someone else (beside the authors) within the taps group would review the new version Aaron: Volunteer? Brian Trammell raised his hand Tommy: Due to this change, since we went through WGLC, do we have to go through that again, or do we have the entire WG look and specific people review Aaron: yes, make sure the WG takes notice, give them a summation of the changes, we have a committed reviewer, that's sufficient. Chris: Yes, this sounds good Magnus: You'll have 2 weeks to comment and review changes, and we'll manage to get feedback from ekr and Christian in that timeframe. Aaron: These were non blocking comments, there's no discuss on the draft Magnus: no, we need to review the comments, which we're doing, Christian/ekr were the main people, and give the WG time to review changes before it goes to the IESG Gory: The text change in the -sec document are actually very large, and though I suspect that it's what everyone in the room wants we really should all look at it again 2. Issue Review (50m) - draft taps-arch-5 Brian Trammel https://github.com/ietf-tapswg/api-drafts/issues/45: Assign to Brian --brief interlude as we all learn how much computers suck-- https://github.com/ietf-tapswg/api-drafts/issues/178: Ready for text; Chris will sit down on Friday to get it done (assigned to Chris) https://github.com/ietf-tapswg/api-drafts/issues/206: Brian thinks just need a line of text in each of -arch and -interface. Already assigned to Tommy. https://github.com/ietf-tapswg/api-drafts/issues/249: Just closed with a shrug.Tommy/Jonathan/Colin agreed at the mic https://github.com/ietf-tapswg/api-drafts/issues/258: Mirja opened it based on a context that made sense at the time, but now is okay with just closing it. https://github.com/ietf-tapswg/api-drafts/issues/299: Let's do it this week https://github.com/ietf-tapswg/api-drafts/issues/305: Theresa: two different places where it is talked about in conflicting ways. related to #327: Add way to force specific protocols Brian: not our problem if an implementation specifies something stupid Assigned to Theresa to work on. https://github.com/ietf-tapswg/api-drafts/issues/347: Chris: Keep them separate; treating everything as an event is BAD. Brian: Agree Colin: I agree, be careful how you phrase it, events and callbacks as terms are overloaded and we don't want to confuse people - draft taps-intf-5 Brian Trammel https://github.com/ietf-tapswg/api-drafts/issues/309: Set to ready for text https://github.com/ietf-tapswg/api-drafts/issues/357: Brian: Default to prefer multiple paths is not supported by the research even under good conditions; set to default ignore. - draft taps-impl-5 Tommy Pauly https://datatracker.ietf.org/meeting/106/materials/slides-106-taps-implementation-document-status Gory: How do you see to adding the bit on pooled connections? Gory: I think the mappings are more abstract, not concrete, so not normative Jonathan: We do have some terminology that means fundamentally different things depending on context, like clone Brian: I like that the informational draft is informational [vs normative?]. I do agree with Jonathan about clone Tommy: We do have the option to split this out to something normative. Aaron: (from the floor, non-mic) yeah I like that idea. Brian: I like it, let's take it to the list. Mirja: Everyone yes please comment https://github.com/ietf-tapswg/api-drafts/issues/282: closed Getting together tomorrow 8:30-10 to try to bang out the rest of the things that are ready for text Mirja: Can I open a new issue? I just want a quick sense of the room ... do we need to say more about ALPN? Brian: Yes, please file an issue on TLS repo Brian: The problem is that ALPN is a stack identifier that they don't recognize is a stack identifier Mirja: What's our answer for people who want to use taps and ALPN? Tommy: When you configure TLS, you configure ALPN. It's highly TLS protocol specific. Anna: Maybe one thing we can do is use that specific case as an example Mirja: I think that would be great. -- meeting ended --