Subject: [Taps] TAPS: Software Guidelines for Protocol Evolution

From: Tommy Pauly <[email-masked]>
Date: Thu, 23 Feb 2017 09:00:35 -0800

Hello TAPS,

I posted an information draft a little bit ago that goes more into depth on the presentation I gave in Seoul about the requirements that protocol racing, etc, have on API design. It focuses on the ways in which API models can cause protocol ossification and stagnation, and how we can try to avoid this by making our APIs sufficiently flexible.

I see this mainly as an information document to use as a reference as we are working on Post-Sockets and other API efforts. Please take a read through it, and let me know your feedback! If the WG would like to adopt this, I'd be happy to continue working on it.

Best,
Tommy

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pauly-taps-guidelines-00.txt
> Date: February 7, 2017 at 4:05:58 PM PST
> To: Tommy Pauly <[email-masked]>
> 
> 
> A new version of I-D, draft-pauly-taps-guidelines-00.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
> 
> Name:		draft-pauly-taps-guidelines
> Revision:	00
> Title:		Software Guidelines for Protocol Evolution
> Document date:	2017-02-07
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-pauly-taps-guidelines-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-pauly-taps-guidelines/
> Htmlized:       https://tools.ietf.org/html/draft-pauly-taps-guidelines-00
> 
> 
> Abstract:
>   This document outlines a set of recommendations and guidelines for
>   how networking software should be designed to enable the development,
>   testing, and deployment of new protocols and protocol features.  The
>   focus is primarily on the API contract that a client-side networking
>   library should present to applications using networking features, and
>   how that library can be architected to maximize flexibility and
>   longevity.
> 
>   Specific areas of protocol development that should be enabled
>   include:
> 
>   o  Making security and privacy easy to use
> 
>   o  Reducing latency with 0-RTT protocols
> 
>   o  Allowing wider use of multi-stream protocols
> 
>   o  Providing a simple interface for multi-path protocols
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>