The TRR Overview and related Deployment Plan Overview mention the new delivered API. They should both explicitly mention the second deliverable: a new command-line tool installed on gateways. Both of these deliverables are being tested and deployed in production.
This second deliverable should also be part of the deployment plan, although in this case it may make sense to only mention how the new command-line tool will be distributed to gateways.
The deployment plan could track gateway deployments of the new client, or totally ignore it and assume it's up to gateways to transition as desired.
Should section "G. Schedule" have specific dates?
This is a REST API so there is not a specific command-line client distributed (I clarified that in the docs). The doc shows how to interact with the REST API using the curl client but any HTTP client should work.
In the deployment plan, I've added a tracking step. The dates are set in section G once testing has been completed (usually by Operations).
Ah, right. I'm a little behind and remembering the old un-improved way.
Incidentally, while re-reviewing the design document I noticed that section 5.2 reference "the client", which as mentioned earlier in the document no longer exists. Reference to the no longer existent client should be cleaned up.
Please ignore. I now see that 5.2 was outlining options, and that 1) is not the selected approach. Sorry.