This is a YANG model that specifies modules for network elements that have periods of scheduled availability and/or unavailability. From a security perspective, it all seems fine, particularly with its inheritance of the underlying NETCONF or RESTCONF for primary in-flight data protection. It does point out some concerns about specific elements of the modules. I found a few nits while reading the document that are detailed below, but I did not really attempt to validate that the YANG modules are fit for purpose, nor did I comprehensively look for nits. Nit finding is just something I do to lighten the load on the RFC Editor.

Nits:

Page 8, section 5, 1st sentence: change "RFCs" to "RFC". Change both occurrences of "are" to "is". 
Page 23, 1st sentence: change "start" to "starting".

Page 15, description for "ietf-tvr-topology", 1st paragraph, 1st sentence: change "an" to "a". 

Page 16, description for "node-id" (from previous page): change the comma to a semicolon.

Page 16, description for "available" (at bottom of page): delete an extra white space after "link".

Page 17, description for "default-link-available", 1st sentence (near bottom of page): change "availibility" to "availability".

Page 17, description for "default-link-available", 2nd sentence: change "specifiy" to "specify".

Page 19, at the top, add a line break after "/topology-schedule/links/available".

Page 23, 2nd sentence: delete the commas that bracket "eth 1".

Page 25, 1st paragraph, 1st sentence: delete the comma after "node:1".

Page 25, 2nd paragraph, 1st sentence: delete the commas that bracket "node:2". Change "starts" to "starting". Change "lasts" to "lasting".