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 protected] on behalf of [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
