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
