Subject: [Taps] April interim: call for agenda items

From: "Aaron Falk" <[email-masked]>
Date: Wed, 25 Mar 2020 10:24:42 -0400

What shall we discuss in April?  How about:

* Normative language in -arch
* Issue review

Some questions:

Is it timely to seek a deep review of -implementation?
Are there open issues to discuss from Kyle’s review of -interface?
What else?

--aaron

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 25 Mar 2020 16:02:52 +0000

As promised,

I did a review of the arch draft and the PR that was recently done. 
There were comments that requested to remove some normative language 
that has been implemented in the current draft - where my review agreed, 
I have not commented further below. However, the latest revision, also 
did not retain the discussion of what I suggested should be normative. I 
have worked through the various comments in github and summarise them 
here (since these comments are now burried in the git, see 502 et al).

So here goes:

Overall review: I think we need to keep the normative language for the 
key features that differentiate the API. I'd really like to use 
REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not 
protocol operation requirements, but are implementation requirements to 
conform. This includes requirements based on Minset - where the WG 
dervied this API: This is after all why the WG worked on Minset as the 
basis of the API.

----

The following are key requirements, that define the TAPS architecture:

* It is RECOMMENDED that functionality that is common across multiple 
transport protocols is made accessible through a unified set of TAPS 
interface calls. As a baseline, a Transport Services API is 
RECOMMENDED/REQUIRED to allow access to the minimal set of features 
offered by transport protocols {{?I-D.ietf-taps-minset}}.

* TAPS automates the selection of protocols and features, based on a set 
of Properties supplied through the TAPS interface. It is RECOMMENDED 
that a TAPS system offers Properties that are common to multiple 
transport protocols. Specifying common Properties enables a system to 
appropriately select between protocols that offer equivalent features. 
This design permits evolution of the transport protocols and functions 
without affecting the programs using the system.

* Applications using the TAPS API are REQUIRED to be robust to the 
automated selection provided by TAPS, including the possibility to 
express requirements and preferences that constrain the choices that can 
be made by the system.  In normal use, TAPS Systems are RECOMMENDED to 
be designed so that all selection decisions result in consistent choices 
for the same network conditions when they have the same set of 
preferences. This is intended to provide predictable outcomes to the 
application using the transport service.

* Applications using TAPS MAY explicitly require or prevent the use of 
specific transport features (and transport protocols) using the 
"REQUIRED" and "PROHIBIT" preferences. This allows an application to 
constrain the set of protocols and features that will be selected for 
the transport service. It is RECOMMENDED that the default usage by 
applications does not unecessarily restrict this selection, so that the 
system can make informed choices (e.g., based on the availability of 
interfaces or set of transport protocols available for the specified 
remote endpoint).

---

After thought, here is my specific poposal of what to do next:

(a) I suggest we group all the requirements on architecture as short one 
or two sentence blocks (preferably as a bullet or definition list) 
collected into a single subsection, so they are easy to find and read 
and we say that these are the key architectural requirements. I suggest 
we insert this new requirements text either their own section, or in 
section 1.3 (although I am open to other places where we can call-out 
the architectural requirements).

(b) We need to decide if these are architectural requirements and if 
there are more or less in total. I am of course open to more refined 
wording:-).

(c) We could also explicitly say there are additional requirements in 
racing  in section XX.

(d) If this plan seems appropriate, I would then suggest to use lower 
case within the remainder of document (we could refer to the 
requirements subsection, if we thought necessary).

Thoughts please, but review now completed!

Gorry

---

Additional Language NiT:

I think the word /assumes/ is not a good choice of word.

OLD:

and it assumes an implementation that can use multiple IP addresses, 
multiple protocols, multiple paths, and provide multiple application streams

NEW:

and it can provide benefit when an implementation can use multiple IP 
addresses, multiple protocols, multiple paths, and provide multiple 
application streams.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 25 Mar 2020 16:30:31 +0000

Thanks, Gorry, for this! I support the idea of having one section with normative requirement at the beginning. Would be nice if someone could put this in a PR. I guess we need to add at least one more requirement on use of security protocols at least.

Mirja

On 25.03.20, 17:03, "Taps on behalf of Gorry Fairhurst" <[email-masked] on behalf of [email-masked]> wrote:

    As promised,

    So here goes:

    ----

    

    ---

    

    
    
    Gorry

    ---

    Additional Language NiT:

    OLD:

    NEW:

    _______________________________________________
    Taps mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/taps

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 25 Mar 2020 16:40:10 +0000

> Thanks, Gorry, for this! I support the idea of having one section with normative requirement at the beginning. Would be nice if someone could put this in a PR. I guess we need to add at least one m…

Sure - have you an idea for a "placeholder bullet" we can add to my list 
below... so we don't loose the thought...

Gorry

---

From: Michael Welzl <[email-masked]>
Date: Thu, 26 Mar 2020 09:11:06 +0100

Hi,

Regarding Kyle’s review, I think this should fall under the heading of “issue review”. I’m planning to look at these again soon, addressing easy ones in a PR, removing points of agreement… and whatever remains, unless some bigger things warrant a list discussion, I thought I'd post as issues. Clearly, “Issue review” is an important agenda item and it could take long. It’s a good, structured way to discuss things IMHO.

Cheers,
Michael

> On Mar 25, 2020, at 3:24 PM, Aaron Falk <[email-masked]> wrote:
> 
> Normative language in -arch
> Issue review
> Some questions:
>

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 26 Mar 2020 14:42:12 +0100

Hi Gorry,

I am much in favour with you proposal, though we can clearly define what a TAPS system is.

AVE!
   Philipp 

> On 25. Mar 2020, at 17:02, Gorry Fairhurst <[email-masked]> wrote:
> 
> As promised,
> 
> I did a review of the arch draft and the PR that was recently done. There were comments that requested to remove some normative language that has been implemented in the current draft - where my review agreed, I have not commented further below. However, the latest revision, also did not retain the discussion of what I suggested should be normative. I have worked through the various comments in github and summarise them here (since these comments are now burried in the git, see 502 et al).
> 
> So here goes:
> 
> Overall review: I think we need to keep the normative language for the key features that differentiate the API. I'd really like to use REQUIRED, RECOMMENDED, rather MUST and SHOULD - because these are not protocol operation requirements, but are implementation requirements to conform. This includes requirements based on Minset - where the WG dervied this API: This is after all why the WG worked on Minset as the basis of the API.
> 
> ----
> 
> * It is RECOMMENDED that functionality that is common across multiple transport protocols is made accessible through a unified set of TAPS interface calls. As a baseline, a Transport Services API is RECOMMENDED/REQUIRED to allow access to the minimal set of features offered by transport protocols {{?I-D.ietf-taps-minset}}.
> 
> * TAPS automates the selection of protocols and features, based on a set of Properties supplied through the TAPS interface. It is RECOMMENDED that a TAPS system offers Properties that are common to multiple transport protocols. Specifying common Properties enables a system to appropriately select between protocols that offer equivalent features. This design permits evolution of the transport protocols and functions without affecting the programs using the system.
> 
> * Applications using the TAPS API are REQUIRED to be robust to the automated selection provided by TAPS, including the possibility to express requirements and preferences that constrain the choices that can be made by the system.  In normal use, TAPS Systems are RECOMMENDED to be designed so that all selection decisions result in consistent choices for the same network conditions when they have the same set of preferences. This is intended to provide predictable outcomes to the application using the transport service.
> 
> * Applications using TAPS MAY explicitly require or prevent the use of specific transport features (and transport protocols) using the "REQUIRED" and "PROHIBIT" preferences. This allows an application to constrain the set of protocols and features that will be selected for the transport service. It is RECOMMENDED that the default usage by applications does not unecessarily restrict this selection, so that the system can make informed choices (e.g., based on the availability of interfaces or set of transport protocols available for the specified remote endpoint).
> 
> 
> ---
> 
> (a) I suggest we group all the requirements on architecture as short one or two sentence blocks (preferably as a bullet or definition list) collected into a single subsection, so they are easy to find and read and we say that these are the key architectural requirements. I suggest we insert this new requirements text either their own section, or in section 1.3 (although I am open to other places where we can call-out the architectural requirements).
> 
> (b) We need to decide if these are architectural requirements and if there are more or less in total. I am of course open to more refined wording:-).
> 
> (c) We could also explicitly say there are additional requirements in racing  in section XX.
> 
> (d) If this plan seems appropriate, I would then suggest to use lower case within the remainder of document (we could refer to the requirements subsection, if we thought necessary).
> 
> and it assumes an implementation that can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams
> 
> NEW:
> 
> and it can provide benefit when an implementation can use multiple IP addresses, multiple protocols, multiple paths, and provide multiple application streams.
> 

AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/