Minutes IETF105: taps
minutes-105-taps-00

Transport Services (TAPS) Working Group
13:30-15:30 Monday Afternoon session I
Room: Van Horne
Chairs: Aaron and Zahed
Jabber: Theresa
Note-taker: Gorry Fairhurst

Administrivia - Aaron & Zahed (5m)

Minset ID is waiting on draft-ietf-taps-transport-security (MISREF).
draft-ietf-taps-transport-security will proceed to WGLC write-up, and Philip
agreed to shepherd.

September Interim was sumamrised (see notes).

Framing - Tommy Pauly

Mirja K - Do we ever need to stack multiple framers.
Tommy - We could potentially have a framer for one thing (e.g. DNS) that works
over another. Mirja - That's more an implementation question rather than an
architectural question. Mirja - Why do you need to add the framer to the
preconnection? Tommy - You get a connection, and the framer starts at some
unknown time. Mirja - Do you need it in the startup? Do we need to have the
start venet? Tommy - Yes, that's useful. The start gives an opportunity to add
memnory, etc. Colin P - These are things if you are building a framer, not the
App? Tommy - Yes. Colin - I thought framers could be implicit. (e.g. adding one
when http is used). Tommy - Yes,for a lot of protocols that are framed. Philip
- Can we implement starttls using this? Tommy - Yes, by prepending a framer
after the preconnection. Aaron - Do you still belive when using TAPS with a
framer that this can be one-sided? Tommy - Yes, nothing appears on the wire.
John - Is the TAPS model different to Applenetwork frame? Tommy -
Preconnections = parameters for us. John - What about multiple preconnections?
Tommy - They refer to the instances that are created, rather than creating an
object and instantiating it. Theresa - One of one possible way to implement one
part of a protocol (i.e. a set of functions). Should we separate the
transformation and the buffer management. Tommy - Can you open an issue?

Erik K - I like the framer view of the model. It could do a handshake if you
like, etc. Philip - It got easier for me to understand if I think the framer is
a buffer manager. Is the API focussed on the buffer management, rather than how
to compose the stacking. Tommy - The data path does involve buffer management.
Do we agree the functions exist in the current form? Philip - I think there may
also be other ways to implement ba framer. Tommy - The question relates to how
portable the parts are. Theresa - I suggest keeping how to add a Framer to a
Preconnection and the set of functions a Framer can implement in the API draft,
and moving "how to implement a Framer" to the implementation draft or maybe
even a separate draft if this grows out of proportion. Max +1 - there are
implementation-specific details that vary by language. There are many
implications. Colin - I agree with Theresa, it's better in the implementation
draft. We should describe what it does as a parser or serialiser. Brian +1.
Message framers are not protocols. Colin - We could in the implementation
sketch the approach for different languages.

Property Profiles & Explicit Protocol Selection - Michael Welzl

        •       https://github.com/ietf-tapswg/api-drafts/pull/328
        •       https://github.com/ietf-tapswg/api-drafts/pull/327
        •       Do we really (still) have any resistance to this idea?

Brian: What is "allow" a specific protocol, or implementation specific protovol
one reason a lazy developer
Gorry - There are cases where someone absolutely needs to do this - an emaple
is where there is a signalling protocol that needs a protocol, port, etc top be
set up. Colin - If we build a general purpose networking API we need to be able
to do what people need to do this. The stack should make the default easy.
Tommy - Should allow you to specify a protocol. Anna B - I basically agree,
when you wish to write an app in TAPs, and in the future you get TAPS benefits
- but at the moment Mirja - We should make it hard. Theresa - Use profiles is
an easy way to get the right outcome and to discourage some applications from
picking a specific protocol. Brian - We should help make it a bit more
discouraged - use a blank tag, don't do this. I reviewed both PRs at the same
time and was confused, since they seemed like opposing PRs, can you explain
Philipp - (explains the 2 ways that you can use profiles to help/force the
protocol that is selected) Brian - I don't dislike the idea as much as I
thought I would. Keith - IMO it is absolutely essential for apps to be able to
specify transport protocol(s). My experience is that there too many subtle
differences from one transport protocol to another, to expect apps to run
successfully over arbitrary protocols.  Second, by permitting arbitrary
transport protocols you make testing of apps and support into nightmares.  
It's one thing if a app can support (and is tested on) N protocols (for small
N) and that's potentially useful, but arbitrary number of protocols is
unworkable. Using profiles is inviting more variability between endpoint
situations, and more ways for an application to fail in mysterious ways Zahed -
Thanks for this discussion. When do we need a protocol? (something only working
with one protocol). An app devceloper wants to use TAPS to get the best set of
services. Colin - We are building an API for the longterm. This is intended to
be the only future API. We need to be able to explicitly request a protocol,
that is still a reasonable case. Michael - Can we add a profile with just one
protocol specified. Tommy - I don't like the profile we say what we currently
do, and I think this is a convenience. I think it will depend on use-cases. A
Yang model could have details that let you do everything, but that's not
interesting to be a part of the API. I think this is more about what we do in
the future. Aaron - I think Keith's point is that apps need to be able to
specify completely what happens. Tommy - I think we can limit what is exposed.
Philipp - I think we need to be able to set the protocol and set the
properties. We talked about the defaults - we can specify default profiles. You
can add to these profiles, but you eliminate the problem that we have to agree
on one set of defaults. Mirja - On selecting a specific profile. - A specific
stack - A test case I didn't see why this is required. I think profiles should
not be in the API Michael S - There are protocols that use specific protocols
and specific parameters. There are real uses-case that need specific params and
protocols. One example will be discussed in the TCPM session during this IETF
meeting. John - I argue that in the future apps may start doing things because
TAPS chooses some ways, we need to avoid protocols coming on line becaue a
stack is simply updated Keith Moore - As an app developer I would love to be
able to find out what options exist to connect to a peer.   That doesn't mean I
want  a lower layer to choose an arbitrary stack. *and not just legacy
protocols* Theresa -  I want to make the stack easy to use, without needing the
details. Profiles make this a cleaner thing to explain, even if the profiles
are in an appendix. Phillipp - Can profiles be a parameter? Anna - I would not
want them as a parameter.

Should profiles be in TAPS?
Humm for inclusion in taps (none against) - TAPS seems useful.

Should this existance appear in the API?
Humm for inclusion in taps (some against)

One possibilty:
(1) profiles are 1st order and specified (2) In the appendix and how (3) We
could place this in our own document (4) Could be in implementation.

Tommy suggested this:
(1) profiles are 1st order and specified - essences in  (2) mentions they exist
and give an example In the appendix (3) No mention.

- The WG will ask Tommy to form this question and ask on the list

Parameters & Defaults - Michael Welzl & Philip Tiesel
        •
        •       Should we specify rather than recommend default values?
        •       https://github.com/ietf-tapswg/api-drafts/pull/317

Gorry - are we following the examples set by other IETF work? What do you want
to see? Gorry - I was happy that the policy could be overwritten Eric - Is the
default that I must specify this unless the client overrides it? (yes) We've
seen different platforms have different defaults - is this going to be any more
effective if we say MUST? Mike - We should have SHOULD for these cases where it
could be different for different platforms Brian - ... your reason for filing
the issue was that the language was too loose. An alternate suggestion: the
default IS .... -let's use that language Aaron - confused by the discussion -
we agree that there should be defaults. It's less loose than what we have Gorry
- Yes - we avoid the lowercase "recommend". Mirja - We shouldn't use normative
language Gorry - I wanted to use normative language because there were reasons
to do that - because the base RFC that said this required a certain behaviour.
We should not be wooley or even contradict the RFC series. I am really content
with "The default is". Keith - Please define things in such a way that
applications behave predictably across different locations and different hosts.
If defaults are implementation-dependent, I don't think this happens.

ARCH & API open topics - Philipp Tiesel

issue - Listening filter behaviour

Tommy - We decided not to do this when we did our implementation. I may want to
do something before an app starts. i.e., something that says how many
conncetions to accept that is TLS-specific, e.g. to reject all from a subnet.
John - I think you should be able to respond in a different way. Brian - I
think we need to look at this again. I retract statement on resolution A - it's
beautiful, but not practical. We need to respond to back pressure and early
rejection. We could add a new event.

Issue - Multicast

Jacob - There were things done in the Hackathon.
Gorry - We could do more, but we should do the least, I like what was done.

Issue 249
- we need text, can be closed.

Issue 307 - selection configuration.
Theresa - I like the initation error to include a reason (b), we need to know
which failure mode, but can't foresee all in the API document. Brian - I am
confused. A bad initiation should fail at call time. Tommy - Initiate does not
have a return value. Brian - I think resilution (b) is good. ? - All error
events could include additional events. Tommy - I like fewer events with more
descriptive errors returned. One event is much easier for the app to catch. Max
volunteered to work through this topic.

Issue 334 - padding
Erik - May be sueful for apps.
Gorry - if we have PMTU info this can be useful. It can also be a really stupid
thing to try to do. Mirja - we could do other stuff. Brian - There are things
that we may want to tag in the git hub to be future work.

Issue 336 - message context

Tommy - Is the returned value only the context that was supplied?
Philiip - Yes.
Tommy - Let us just pas sthe value that you want to use.
Michael - just query the transport system and ask what was chosen.
Brian +1

Do you get lots of send errors from the same send? (ofr each send you can
potnetially get a send error) Colin - We do not need to specify.

All the rmaining issues will be posted to the taps list to try to seek
resolution asap.

YANG Model - Theresa Enghardt
        •       Benefits and pain points of using Yang within our PyTAPS
        implementation •       Suggested changes to the model we come up with
        during the hackathon

Tommy - Thank you for doing this. Feels like where the profiles ideas could fit
well. We also discussed how we test the output - we could try to expose the
decisions - the other alternative is to have a server and then orchestrate this
on the server to accept different combinbations of protocols. Mirja - I was
more convinced that profiles and yang models were different ways to do this.
Aaron - Yang models are a way to describe profiles. This helps apps choose
useful sets of behaviours, so apps developers do not need to think about that.
Mirja - You could just publish a set of yang models. Thereas - I dont think
apps developers need to read yang models. Mirja  - You would need several yang
models - I think profiles would be much simpler. Jake - are you suggesting we
have profiles in the yang model or just define features? This can make the yang
model less useful. It is easier to specify profiles for app developers.

Next meeting: September 2019  Virtual Interim.