Hi Tommy, A few answers below:
> On Jan 10, 2018, at 6:11 PM, Tommy Pauly <[email protected]> wrote: > > Hello TAPS, > > In Singapore, there was much discussion about where we go after the minset > drafts, and what documents will form charter item 3: > > 3) Specify experimental support mechanisms to provide the Transport > Services identified in work item 2. This document will explain > how to select and engage an appropriate protocol and how to > discover which protocols are available for the selected service > between a given pair of end points. Further, it will provide a > basis for incremental deployment. Work on this document will > begin when the TAPS Transport Services have been specified. > > Since it would be good to get convergence and adoption of documents in > London, I’d like to take a stab at how we can structure the WG documents and > start a discussion on this list to decide our collective approach. > > At a high level, based on the work of NEAT, Post Sockets, Happy Eyeballs, > Socket Intents, etc, it seems like the “support mechanisms” for TAPS are > converging into categories (a) how to expose functionality in an Abstract API > and (b) guidance on how to implement a library that provides TAPS > functionality. These two categories are not unrelated, but have different > audiences; Abstract APIs are aimed at adopters of a TAPS system, while the > implementation guidance aspects are aimed at library and system implementers. > The high-level concepts that bind these together form the overall TAPS > architecture. > > Looking at things in this way, I could imagine three documents, which would > form the capstone of the TAPS work > 1) TAPS Architecture: high level explanation of the approach and goals, how > the API and implementations relate, and how the system is derived from the > protocol surveys and minset. Defines consistent terminology for concepts used > in the other documents. > 2) TAPS API: document aimed at adopters taking advantage of a TAPS system: > configuration, initiation of channels, listening/responding, data transfer, > and maintenance. > 3) TAPS Implementation Guide: document aimed at implementers on how to bring > up connections (handling a multiplicity of paths, endpoints, and protocols), > sending and receiving data through protocol stack instances, and interpreting > configuration and system policy into decisions. Funny, I have also been thinking about item 3 in exactly this way for a long time … and I believe we two are not the only ones. This split really seems quite natural. > I believe that many (or all) of the outstanding documents we have in the WG > already fall into one or more of the categories. Here’s a table with the > three proposed documents as 1, 2, 3, and three aspects of a TAPS > system/architecture as A, B, C: > > > A > B > C > 1. TAPS Architecture > Connection Establishment > Data transfer > Policy and Path Selection > 2. TAPS API > Initiator/Listener/Responder > Send/Receive > Intents and configuration > 3. TAPS Implementation Guide > Protocol Racing, Path Racing, Happy Eyeballs > Protocol Stack Instance > Policy engine > > In this table, we could see the existing documents contributing aspects to > certain blocks: > > draft-fairhurst-taps-neat: 1A, 1B, 1C, 2A, 2B, 2C, 3C > draft-trammell-taps-post-sockets: 1A, 1B, 1C, 2A, 2B, (2C), (3B) > draft-pauly-taps-guidelines: 3A, (1C) > draft-grinnemo-taps-he: 3A > draft-tiesel-taps-socketintents: 2C I agree with this rough assessment. This table is good to think about! I think draft-tiesel-taps-communitgrany is missing for 1) (not sure if it’s A / B / C, but it’s about terminology) > This is a rough assignment and not necessarily exhaustive, but the point is > that much of the content is probably already there is some form, and can be > reinterpreted into these documents. > > What do people think about this approach? Any aspects that are missed here > that would need to be separate documents, or new sections across the > documents? Personally I like the approach but I’d caution that we need a tight connection between the lines in the table. For everything we do, we must make sure it’s implementable, and explain how. Hence, a document describing API primitives should also clarify how these primitives could be implemented - with the split you describe above, by pointing at a specific section for each functionality in a "line 3” document (if these things really are going to be separate documents?). Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
