Minutes IETF105: taps
|Meeting Minutes||Transport Services (taps) WG|
|Title||Minutes IETF105: taps|
|Other versions||plain text|
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.