A YANG Data Model for Scheduled Attributes
draft-ietf-tvr-schedule-yang-12

# Andy Newton, ART AD, comments for draft-ietf-tvr-schedule-yang-08
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tvr-schedule-yang-08.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/


## Nits

898        ietf-tvr-topolgy.yang module may be considered sensitive or

topology?

Thanks to the authors and working group for their work on this document. Thanks as well to Tony Li for the shepherd writeup, which I found to be very helpful. One note of a possible copy/paste or a script error in the writeup:

"This version is dated 4 July 2022."

I have a few minor comments on the text of the document.

In the Abstract, I had a challenge time parsing the first sentence. If my assumption of the intended meaning is correct, moving a comma as suggested below would help.

OLD
The YANG model in this document includes three modules, and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity as a function of time.

NEW
The YANG model in this document includes three modules and can be used to manage network resources and topologies with scheduled attributes, such as predictable link loss and link connectivity, as a function of time.

In Security Considerations, I did not understand what is meant by the following:
"There are the subtrees and data nodes and their sensitivity/vulnerability:
   /node-schedule/node-power-schedule
   /node-schedule/interface-schedule
   /topology-schedule/nodes/available
   /topology-schedule/links/available"

Are these examples of subtrees and data nodes, and is their sensitivity/vulnerability indicated in some manner? 

I believe the indentation of "Modifications to these scheduled attributes may result in a denial of service.", is not intended.

Thanks for the updates.


Thanks to Peter Yee for the SECDIR review.  Some additional comments to consider:

* what does available mean in the interface definition:
> 235	           +--rw interface* [name]
> 236	              +--rw name                  union
> 237	              +--rw default-available?    boolean
> 238	              +--rw default-bandwidth?    yang:gauge64
> 239	              +--rw attribute-schedule
there are multiple `booleans` for available, but even if the top level available is true, the schedule could be resourced to be unavailable or the particular schedule could also be not available?  What would the implementation useage logic of all that add up to be?

Thank you to Peter Yee for their secdir (and GenArt) reviews.

Section 7, para 1:  I recommend using draft-ietf-tls-8446bis vice RFC 8446.  The draft is in Auth 48.

Thanks for addressing my [previous DISCUSS/COMMENT points](https://mailarchive.ietf.org/arch/msg/tvr/T1yybPWuPRDlFF-LBqjoOpqF918/)

I did not see an transport topics in this document. 
Thanks - Gorry

Just a comment - if your ietf-tvr-topology module had retained the ’topology-schedule’ container, but now inside of ’node’ and ’termination-point’ it would have been nice. But that would be a nice-to-have, not a blocking comment.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 8, paragraph 1
-    This document registers a URI in the IETF XML registry [RFC3688].
-                            ^
-    Following the format in [RFC3688], the following registration is
-                                                                  ^^
+    This document registers three URIs in the IETF XML registry [RFC3688].
+                            ^^^^^    +
+    Following the format in [RFC3688], the following registrations are
+                                                                 + ^^^

Section 8, paragraph 5
-    This document registers a YANG module in the YANG Module Names
-                            ^
+    This document registers three YANG modules in the YANG Module Names
+                            ^^^^^            +

Hi Yingzhen, Acee, Eric, Don, and Marc,

Thank you for the discussion and changes made [1]. All points in [2] were adequately addressed.

Thanks for your patience with me.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-tvr-schedule-yang-08&url2=draft-ietf-tvr-schedule-yang-10&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/tvr/ey_MKtgxHa29mnYkBbAhjtDis5k/

Thank you to Peter Yee for the GENART and SECDIR review.

It wasn't clear which of the requirements defined by https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/ this model satisfied.  This requirements document also outlined a number of security considerations and the link between them and what is provided through the YANG deployment architecture could be clearer.