Subject: [Taps] Review of Arch wrt to normative requirements on the architecture

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 8 Mar 2020 09:32:03 +0000

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