TAPS Interim Meeting
January 15, 2019 via WebEx

Attending (add your name here so we know your color)
* Aaron Falk
* Tom Jones
* Gorry Fairhurst
* Theresa Enghardt
* Tommy Pauly
* Chris Wood
* Philipp Tiesel
* Colin Perkins
* Spencer Dawkins
* Erik Kline
* Brian Trammell
* Michael Welzl
* Rich Salz
* Anna Brunstrom
* Mirja Kühlewind
* Max Franke
* John Border
* Kyle Rose
* Jonathan Lennox



Agenda 
====== 


0. State of Documents 
===================

Aaron: there has been a lot of activity on GitHub so for the sake of the record, I'd like to know what the state of each of the documents is

Transport Security document
---------------------------

Chris: SECDIR early review, some content, some missing things (OpenVPN), Theresa will do that. Lots of Wireguard discussion, mixed feelings but will not remove. One or two new protocols, will probably not introduce new features. All should be done by March.

Aaron: Kyle anything to add on transport sec status?

Kyle: What was the response to comments on obscure/academic protocols?

Chris: like minimalt? will move to appendix, but not take them out.

Architecture
------------

Tommy: Since BKK we've done primarily editorial changes, incorporated edits from Gorry to fix MUST/SHOULD, Mirja did a review pass. Integrated message handling text.
Phil put in terminology around properties. Editorial language fixes. Reorganized how properties were laid out. Selection properties are clearly pre-establishment. Message properties are data transfer, but can be defaulted in pre-establishment. Then there are connection properties. When can we change these?
Brian: answer is implementation dependent and property-dependent. 
Will be last-callable soon, but actual Last Call might wait until all three docs are ready.
There are some issues on Github left.
Anna: I reread the doc before the meeting, most of the issues I found are already covered. Will file issues for the others.
Gorry: maybe we should not add more stuff to the architecture document. TAPS can do many things, no need to put them all in. Maybe only 1-2 more things to add and we're there. I agree with what we have in it.

Interface
---------
Brian: We have a few of the Github issues tagged "api" with diminishing returns on how long we discuss them. Editors should maybe do a pass on them.
Brian + Michael: Eds will triage issues and make a proposal to the list

Implementation
--------------

Anna: Lagging a bit behind the other docs, as expected, waiting for them to be stable. Done some cleanup based on changes in the API, some changes waiting to land. This is the one that needs more attention later on once we have settled on the API.
Aaron: how long until the document is Done? Not going to be done by Prague, but Montreal?
Anna: Depends on when we settle on API, and on the scope of the implementation document. There's an issue open on how much of the protocol mappings should be in the doc, for instance. July could be a good target.
Aaron: Put this on the agenda in Prague?
Anna: Yes. Scoping in particular.
Brian: Agree, gives an implicit deadline for Interface doc to stabilize things
Tommy: Ideally, we can know how rigorous the feature mappings should be in the implementation, that should be the outcome of discussion in March.

Jonathan Lennox: Protocol bindings should be normative, but the rest of the implementation is informational. 
Tommy: Design spec should stay in -implementation, and maybe we need a mappings document? That's maybe a registry?
Aaron: IDentified as an issue, let's see if this comes up again after registry discussion.
Gorry: Not sure a PS doc can't have an Info sec in it... Have done this in TSVWG.
Aaron: this is the other way round, mostly Info with a little bit of PS
Gorry: call to be made. Identify how much is normative, how much is normative guidance, how much is just a description
Brian: suggest to write the text then split it up
Everyone: agreed, including AD


1. Open architecture (actually API) topic: caching state - Michael Welzl 
========================================================================
PR 244, didn't get to discuss in BKK https://github.com/taps-api/drafts/pull/244/files
Keep handle to CacheContext in Preconnection call?
Tommy: CacheContext is optional. By default you share everything.
Brian: Scope question. We do not specify how you sign up for events, because that's implementation-specific. We cannot make this the same for different languages. Post Sockets had an application cache. Here you require the application to manage part of this. I requested changes on the PR. Application context is missing in the whole API, we should make it explicit. And probably talk about how you implement it. You don't want an app mixing its crypto information with other apps.
Tom: Can I re-use Preconnections?
Brian: This is outside Preconnections. It's like the NEAT context. Maybe we don't need to specify the interface, but specify the slot.
Gorry: Specify that this exists but it is implementation-specific?
Tommy: This was inspired by NEAT context and association in Post Sockets. This should be the boundary of the cache and any re-use of protocol instances. Maybe we can also just say this abstractly, like, "There should be a way to separate contexts".
Brian: Sometimes you want control over a specific cache, like for browsers in incognito windows, or give a reference to some data storage in the cloud...
Gorry: I'm worried this sounds like a policy manager. Let's not make this too complex.
Michael: CacheContext could just be a number.
Brian: Or a pointer.
Michael: The PR has a bit more.
Anna: Some parameters can be cached in different contexts, because some are sensitive, some are not.
Brian: I think we should junk this PR and start over. If we need to say much about this, it's probably in the implementation document. In API, only say that this must be possible.
Colin: There needs to be a slot in the architecture as well.
Tommy: This PR proposes to add something to architecture.
Aaron: But why do we have to say anything about this? Why is this not implementation-specific?
Brian: Because it changes the security properties of a TAPS system.
Philipp: Why not rename this to privacy context?
Brian: That will get the wrong people reviewing the document in the wrong way, it oversells it. But we should think about it in this way.
Gorry: This also includes PvD information.
Brian: But PvD information is also privacy-sensitive.
Aaron: That's a security consideration. But I don't see why this is in scope for the draft.
Brian: My proposal is for the application to say which Preconnections and Connections are in the same or a different context. For privacy and other reasons.
Mirja: Maybe we just need an option "Don't cache any information for this Connection". And then if you do need to cache something, the application can do it.
Tommy: That's one way to solve it. If we don't do anything like this, people will complain that they "this is too smart", they can't use TAPS because it caches too much.
Aaron: Can there be a caching considerations section in the implementation? Or does it have to be in the architecture? If so, we need to pull that discussion up.
Tommy: We want to make sure all TAPS implementation are capable of caching and racing. So they must also be able to turn that off.
Brian: Can you come back with a PR for just the Architecture doc? And then we can decide what we need in Interface.
Tommy: Yes.
Jonathan: There's multiple concepts of caching conflated here. Results of racing and TLS or HTTP? Are these all the same granularity?
Tommy: The implementation can carve it up more granular. But that's implementation-specific.

--> Tommy to prepare a PR for Architecture.

2. TAPS registry proposal - Philip Tiesel
=========================================

Philipp: Do we want to have defined strings for properties? Propose so, it gives a common vocabulary across implementations. Should we request a registry for these property names? This would enable extension. Looking for feedback on these two questions.

Gorry: I've done this for various protocols. Not a bad idea to have a registry if we have names. A registry with RFC required... 

Aaron: If we standardize property names, then we need a registry unless we want to keep the WG alive forever. My worry is... It took us a long time to agree on the properties we have, so adding to the registry will be hard... Will we name them badly, or will we have a lot of work to agree on names. This set of people will have to continue to discuss these things on into the future.

Colin: If things are hard to name...

Mirja: Philipp said we want to use the same names and have the same behavior on all platforms, so we need the same names, but that is a non-goal. Naming on every implementation may differ.

Philipp: system uses the same name for the same property is a different thing than the system must behave exactly the same...

Anna: you also have to think about the semantics of the names.. if the behaviors are different on different systems, then that's not ok. it should mean the same thing, at least in terms of high-level behavior

Michael: We have this for the names in the API...

Anna: i thought we talked about having a pool of new names... those I am concerned about.

Mirja: what do you ca... [missing]

Gorry: Can't tell, unless we know how these policy frameworks are used by others. Should we do this in a separate document? If time suggests this is important, then we can do it. If we build it in a part of the main thing then taps is only this

Mirja: we need standard names in the main doc, we can do the registry later

Gorry: or in a separate document... i agree we can do it later, or we can do it now in a separate doc

Brian (wants to ask a q): important for properties in the doc to have standard names and a recommendation to use them unless you have a reason not to (constrained environment, ..). Have put a lot of effort into registry in the past, share Aaron's concern that adding things to the registry / reviewing them is going to be painful. Proposed format offends all languages that don't have Camel-cased strings. Separate doc for defining registry later or now, no strong opinion, but important to standardize names in the API doc.

Aaron: Pulling name est into own doc...

Brian + Michael: no!

Aaron: Counterproposal: define names in the interface document, don't create a registry

Philipp: I think the first step is establish standard names

Aaron: Create a registry if we want to add to the list

Jonathan: any name needs an associated semantic which needs a document. a convention for how names work is separate from the registry.

Brian: I think we should have a PR to add names to the document

Philipp: Do we want rules for how the names should look? 

Brian: yes, discuss on the mailinglist, doesn't necessarily need to be in the document.

form of names? Brian: suggest we have names that are all lowercase and space-separated, and you can use whatever convention you want to.

Jonathan: namespaces are also useful. 

Philipp: how namespaces work are implementation specific

Aaron: philipp, will you write text?

Philipp: yes.


3. Implementation update - Theresa Enghardt
===========================================

Theresa will bring python asyncio taps to the hackathon in Prague. https://github.com/fg-inet/python-asyncio-taps

Theresa, Philipp, and Max to host a TAPS table at the hackathon. Theresa to write an announcement to the mailing list.

Theresa, will you own the hackathon topic on the wiki / etc? Sure!

Philipp: let's have a table for all TAPS implementations

Brian mentioned ETH implementation, which does AF agility (SCION vs IOnternet). It looks a lot like net.Conn in Go (so not a very good implementation of the whole TAPS concept), but this will result in a critique / screed about the usability and implementability of TAPS

4. Mobility - Zahed Sarker 
==========================

[Will send mobility thoughts to mailing list if we don't have time to discuss]

5. GitHub - Aaron Falk
======================
Aaron: IETF's been coming up with best practices on using githubs in WGs, largely based on QUIC and HTTPS experience
https://tools.ietf.org/id/draft-thomson-github-bcp-00.html / https://www.ietf.org/archive/id/draft-thomson-github-bcp-00.txt
Tools to make it easier to use
Doc has recommendations that we don't conform with. Could choose to do it or finish things the way we are going. Not a requirements doc, but best practices, but good reasons for that. E.g. organization running the repo should .. have ADs and WG chairs. Option of separate mailing list that just exports github activity. Not sure we could move repo?
Brian: we can have the taps-api drafts repo simply point to the new "taps" organization
continuous integration shouldn't be lost.
Aaron doesn't have cycles, welcomes Brian's volunteering to do it. Will create an org for it. Recommendation of separate repo for document is not a good idea in our case.
Brian: also not done in QUIC.
Zahed: when is discussion moved to mailing list, when not?
Tommy: QUIC uses weekly digest. Good way to do it.
Rich Salz: script that does that is pretty neat. My scripts, but not complete: https://github.com/richsalz/ietf-gh-scripts
https://github.com/dontcallmedom/github-notify-ml
Spencer Dawkins: Encourage all to look at the doc. Don't want to oversell it. Creation of WG that will work on the doc on the agenda for the next IETF, so don't believe everything it says today, else we won't create a WG for it. But keep an eye on what is going on. One thing that keeps coming up: what happens when everyone in github agrees on something and other people don't? We make decisions on mailing lists, in the BCPs. If you think of github as a design team, coming back with a design team report is good. Good to capture discussions with history, so we can back and know reasons. But don't want "we've all agreed, implemented, and now we tell the WG". Working groups have a lot of flexibility, and it's OK to use it. 
Zahed: if there's a hot topic in issues, good to cross-check with ML.
Aaron: conscious that we get stuff done through volunteer energy, there is an obligation to transparency and openness. we tend to have fine-grained discussion on github, when we do not come to consensus, usually we speak face to face, the mailing list is informed. don't want to make it harder to do work. so let's get the automated summary of the github discussion on to the mailing list. let's see if spencer will fire me over that.
Spencer: i trust you all to do the right thing (tm).
Aaron: happy about the level of activity, don't want to mess things up.
gorry: i like to put the github in the charter page
spencer: if you can't edit it, tell me.
Action items:
    * Create a new organization (or rename the existing one? rather not)
    * transfer the repo to the new organization
    * come up with a logo :D

6. Architectural Considerations for Types of Properties (Selection, Connection, Message) - Brian
========================================================================================
Michael: Connection Properties - when can they be changed? And can they be used for racing? Some it's pretty obvious they can be changed, like timeouts or niceness.
Tommy: Generic Connection Properties? All Connection properties may be specified and changed at any point?
Michael: That's what I want.
Anna: I think this is okay, but then you should not use them for selection.
Brian: We're talking about Connection properties in 9.1, not 5.2
Michael: There was discussion in a PR for the Implementation draft. They don't make sense as Selection Properties, but I can't see what's wrong with specifying them as early as possible.
Tommy: Changing them might be a lot of work for the implementation. Like using LEDBAT and then not, implications on queues, etc... So the implementation should be able to not let you change them.
Michael: Maybe they shouldn't all be in the same bag? Some of them really need to be changeable later. 
Philipp: Let's not start the whole classification discussion again. The bags are not that sharp. I think now we have pretty nice bags. Yes, some Connection properties only make sense on the Preconnection for implementation reasons. And yes, an implementation may use Connection properties for everything it likes to, also for selection.
Anna: I did not suggest "must not use", but that it doesn't need to be added in every place where we discuss racing in the implementation draft.
Michael: I see your concern and I can change that. But the capacity profile can make an influence and it does fit as a Connection Property.
Anna: But it's not well-specified. Is it a requirement or a preference? Maybe this is a selection property and not something you change mid-way?
Tommy: Question for architecture how the text should do. I split properties into paragraphs to describe them more. Can we put Connection Properties in the pre-establishment group of things, and just say that they may be changeable later depending on the implementation? Just so we get the right congestion control etc in the beginning. And then say that there's no guarantee that it's possible to change later. 
(general agreement)
Anna: Basic objects having all properties reads strange to me. But we can sort that out.

--> Tommy will write the text.

Philipp: Not all Selection Properties we define in Interface are mandatory to implement, they might be NO-OPs. Do we need to reflect this in the text?
Gorry: What does mandatory to implement mean? Can't everything be a NO-OP.
Brian: Agree. What's the change to the doc?
Philipp: Just noting the fact. It says this implicitly. And sometimes the discussion comes up. I'd just like to clarify it.
Gorry: make it very clear that things can just be no-oped. I like that.


7. Interface Feature Triage - Brian and Michael
===============================================

https://github.com/taps-api/drafts/issues?q=is%3Aissue+is%3Aopen+label%3AAPI