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 <go...@erg.abdn.ac.uk> 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.
>
> ----
>
> 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.
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
AVE!
Philipp S. Tiesel
--
Philipp S. Tiesel
https://philipp.tiesel.net/
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
