Minutes IETF106: taps
minutes-106-taps-00

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 --