On 25/03/2020 16:30, Mirja Kuehlewind wrote:
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.

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

Gorry

Mirja


´╗┐On 25.03.20, 17:03, "Taps on behalf of Gorry Fairhurst" <taps-boun...@ietf.org on 
behalf of 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

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

Reply via email to