I have now reveiwed the Arch document for normative language, as promised.
After the review, I would still be in favour of using RFC2119 language to describe what is required architecturally to be a TAPS system. In my review, I agree the number of requirements is now reduced.
I really do wonder if we could (please) group all these requirements on architecture into a single subsection, so they are easy to read - and we can they say that these are the architectural requirements, explcitly refererence those in section XX relating to racing. I suggest we insert this requirements text either as short text blocks in their own section, or simply a set of bullets in section 1.3 (although I am open to other places where we can call-out the architectural requirements).
Perhaps we should also check we still have captured something along the lines of:
"The System should permit evolution of the system without affecting programs using it. In normal use, TAPS systems are RECOMMENDED to result in consistent selection for the same network conditions when they have the same set of preferences, but applications using the TAPS API are REQUIRED to be robust to the automated selection, including the possibility to express requirements that constrain the choices that can be made by the system." And possibly add "Applications using TAPS can explicitly require or prevent the use of specific transport features (and transport protocols) using the "REQUIRED" and "PROHIBIT"..." or something like that.
If this seems appropriate to add a section on overall requirements, I would then suggest to use lower case within the document and simply refer to this subsection, where necessary to get the RFC2119 sentences.
I made specific comments in pull request, #502: https://github.com/ietf-tapswg/api-drafts/pull/502 --- Comments or imrpovements welcome! Gorry _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
