Ballot for draft-ietf-tvr-requirements
Discuss
Yes
No Objection
No Record
Summary: Has 3 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
# Éric Vyncke INT AD comments for draft-ietf-tvr-requirements-08 CC @evyncke Thank you for the work put into this document. Please find below blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Ed Birrane for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Other thanks to Darren Dukes, the Internet directorate reviewer (at my request), please consider this recent int-dir review: https://datatracker.ietf.org/doc/review-ietf-tvr-requirements-08-intdir-telechat-dukes-2026-04-12/ (I hope that authors will engage with Darren) I hope that this review helps to improve the document, Regards, -éric Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues. ## DISCUSS (blocking) As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise. ### Requirements or considerations ? Most of the document is about considerations, only the very short section 4 is about actual requirements. Should the title and abstract better fit the actual content ? Moreover, the section 4 contains two subsections with "should" and not "must": - section 4.1: `A Manager should provide an advertisement methodology` - section 4.6: `The following security-related requirements should be considered` Has the WG considered categorizing requirements by priority ? ### Time accuracy Should the document require a specific format & accuracy for time ? (e.g., UTC to the msec)
## COMMENTS (non-blocking) ### Predictability in real life What happens when reality deviates from the predicted schedule? Is there a requirement for a fallback mechanism ? (I may have failed to spot the text though) ### Section 1 `This document is an *informational specification*` seems like an oxymoron to me. ### Section 2.1 You may consider s/unmanned aerial vehicles/*uncrewed* aerial vehicles/ ### Section 2.1.4 Why does an IETF document mention a specific service from USA (`GPS time`) rather than the global GNSS (Global Navigation Satellite System) term ? The IETF is a global organisation. Not to mention that I am unsure whether GNSS time is accurate outside of the Earth surface and some TVR use case are not on the Earth surface. Moreover, the last sentence of the section 6.1 (security considerations) is only about NTP and not GNSS. Suggest to be consistent. ### Section 6.2 In the security section, nothing is said that if the schedule is divulgated for some operators (e.g., military) then this could disclosed critical plans or for a normal SP information about business. ### Acknowledgements Suggest removing `This work has benefited from the participation of the TVR working group and the discussions on the mailing list.` as it is a WG document anyway. ## NITS (non-blocking / cosmetic) ### Use of SVG graphics To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)
I have many comments and curioisitis about this document, and would like to DISCUSS the strengths of the recommendations, since the WG has requested publication in the RFC-Series. 1) I see the Charter text calls for: "Requirements: This document should include definitions, requirements, notes, rationales, and examples." - However, the supplied document is mainly descriptive at present. Sections 2 and 3 describe broad use cases, but section 4 does not currently derive strong requirements; such as a numbered set of precisely defined requirements. So, is/could the document provide formal requirements using RFC2119 language in section 4 to clearly indicate what is needed. Here are some specific questions to discuss on the specific 'requirements" below: 2) / A Manager should provide an advertisement methodology for responding to abnormal changes in the system./ -- It was not clear to me what was needed here, or what the exepected response included - is it enough to log, might this imply alerting or taking action? 3) Recommended, optional or needed? / Systems must support proxy entities to help non-routing nodes implement information advertisement./ - this is specified as a "should", but the text above suggests this is optional. Please clarify the position. 4) What would be compliant? / Systems must support system schedule changes. Systems must support time interval changes./ - What does the requirement imply as a constraint on the solution space? How often is this needed? Is rollback needed in event of a fault, and how is this authenticated? and / Systems must support appropriate time tolerance./ - This is a "must" - but what is actually required for a design to be conformant, and how will this be specified?... this seems a difficult conformance requiremenrt, please indicate how it will be achieved? 5) / Resilience Against Malicious or Erroneous Inputs: A TVR network must be resilient against the injection of incorrect or maliciously crafted scheduling information./ - How? and /TVR implementations should include fallback mechanisms to maintain network stability./ - Why is this not a requirement (MUST?) 6) There are also presumably requirements for data integrity and timely delivery of information - ought these also to be called out in the list of requirements (even if the chosen way to mittigate these is to use strong security mechanisms)? Best wishes, Gorry (WIT AD)
Thank you for the TSV-ART review by Mirja Kühlewind, and the issues raised in that review. Minor: Section 1: /This document is an informational specification meant to inform .../ -- is it better to state: /This document was written to inform.../ Minor: /orchestrator/ - ought this to be /Orchestrator/ Minor: Why does an International document discuss GPS, whilst coordinated Universal Time (UTC) is a primary time standard? Minor: Is a "MAC address" sufficient in Layer 2? - Does this document need to consider a wider set, i.e. EUI-48, or EUI-64?
** Section 4.2. 4.2. Support Proxy Advertisement Proxies can help to improve the efficiency of the network. There are some entities in the network that do not have routing functions. When their properties change, they are unable to notify other entities in the network. Proxy nodes can help nodes without routing functions to advertise information, thus improving the efficiency of the network. Therefore, Systems must support proxy entities to help non-routing nodes implement information advertisement. -- What is a proxy in this context? -- What does it mean to “support proxy entities”?
I support the positions of Éric Vyncke and Gorry Fairhurst on clarifying text around the requirements. ** Are the requirements in Section 4, as the name would imply, a “Requirements Summary”, of those in Section 3? There are various clauses in Section 3 which talk about “should” which don’t appear to me to cleanly align with the Section 4 text. ** Section 4.5 4.5. Support Appropriate Time Accuracy The accuracy of the time cannot be too large or too small; otherwise, convergence may not be possible. Therefore, Systems must support appropriate time tolerance. With no definition or framing of “appropriate”, isn’t any time tolerance acceptable? It isn’t clear how this text establishes a requirement.
Overall, the document is well written and extensively covers issues relating to the terminology and considerations of building a time-variant routing network. I will support many of the other AD’s comments in that for as extensive as a document as this is, it is relatively thin on the requirements for implementing a TVR network. The draft is more “TVR Concerns, Consideratons, Terminology, and Requirements”. ### Comments * The link in this reference is broken: > EUROCONTROL and Federal Aviation Administration, "AIXM 5 Temporality Model", 15 September 2010, <~[https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm_temporality_1.0.pdf](https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/aixm_temporality_1.0.pdf)~>. * This possibility seems like in a time-variant resource constrained system that it could cause extreme complexity and challenges to realize, but there is no menton of that. It’s also not clear if this applies to store-and-forward type queueing for the routing model or the scheduling of resources for nodes. For example, if one if communicating with an overhead resource (statellite, drone, heliostat, etc.) using free space optics maybe, then shining multiple lasers at its receiver is likely not to be resolved easily. But a system using something more akin to cellular with a control channel and OFDM schedulable data channels can much more easily make use of priority decisions and reallocate communication bandwidth. If this refers to queueing, then the implicatons on queue depth, slow sender, and drops should be considered. Should this be covered? > 675 2.2.8. Time-Overlap and Priority > > 677 In an ideal situation a model would be guaranteed by design to > 678 contain only contiguous and non-overlapping schedules for each time- > 679 variant scope. In a realized model this kind of invariant might not > 680 be enforceable or might lead to overly complex schedule structures. > 681 One way a model can handle this is to establish a concept of schedule > 682 priority, where some intervals of the schedule timeline contain > 683 overlapping schedules for the same properties and only the highest- > 684 priority schedule applies. When priorities are allowed by a model, > 685 it enables the concept of an "overlay" where a long-duration state > 686 can be temporarily (in schedule time) superseded by a short-duration > 687 state.
------------------------------------------------------------------------------- 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 1.1, paragraph 3 > true timeline, measured in some time scale by some local ticker. The notion > ^^^^^^^^^^ This word is normally spelled as one. [EN_COMPOUNDS_TIME_SCALE] Section 2.2.2, paragraph 2 > eed to model repetitive states in a concise way. One way to model a periodic > ^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "concisely" to avoid wordiness. [IN_A_X_MANNER] Section 2.2.9, paragraph 1 > s, relating schedules to entities in an network model used for routing is me > ^^ Use "a" instead of "an" if the following word doesn't start with a vowel sound, e.g. "a sentence", "a university". [EN_A_VS_AN] Section 2.3.3, paragraph 3 > ents, scheduling information may distributed through a management plane mecha > ^^^^^^^^^^^ The modal verb "may" requires the verb's base form. [MD_BASEFORM] Section 5, paragraph 1 > exity, make schedule scope more fine grained, or expand time horizons as dev > ^^^^^^^^^^^^ This word is normally spelled with a hyphen. [EN_COMPOUNDS_FINE_GRAINED]
Hi Dan, Luis, Brian, and Li, Thank you for the effort put in this document. Thanks also to Bo Wu for the excellent OPSDIR review and the authors for engaging and implementing changes in -08. The document reads well. I have few comments: # How these requirements are expected to inform the solution space? For example, how these requirements are used to derive the work in draft-ietf-tvr-schedule-yang? # Abstract ## It is about forwarding paths OLD: Time-Variant Routing (TVR) refers to calculating a path .. NEW: Time-Variant Routing (TVR) refers to calculating a forwarding path … ## Subpaths I’m not sure I would mention paths and subpaths as that is too subtle for an abstract. More importantly, the notion of path and subpath is not defined, while it should be if this is important. # TVR System Please add a definition of what is meant by that concept. # On devices, data model, internal decompositions CURRENT: +--------------------+ +-------------------+ | Managing Device | | Managed Device | | | | | | +--------------+ | | +-------------+ | | | Orchestrator | | | | Application | | | +--------------+ | | +-------------+ | | | | Management | | | | +--------------+ | Protocol | +-------------+ | | | Manager | |------+------| | Agent | | | +--------------+ | : | +-------------+ | +--------------------+ : +-------------------+ : +-------------+ | Data Model | +-------------+ ## I suggest s/Managing Device/Managing Entity and s/Managed Device/Managed Entity as the current architecture is restrictive and may not cover deployment when such entities are virtual instances that co-exist with other instances. ## Why the orchestrator and manager are enclosed in the same entity? Why isn’t allowed from an operational standpoint to have those separated? ## Idem, what is there one single application that interacts with an Agent? ## There might be several data models invoked on the management interface. The current arch is restrictive. # Samples CURRENT: However, there are a growing number of use cases where changes to the routing topology are an expected part of network operations. Can we please provide examples of these “growing number of use cases”? # Terminology Maybe add: route, path, and Termination Points entries. # Unmanned vs. Uncrewed Maybe better to use OLD: such as unmanned aerial vehicles NEW: such as uncrewed aerial vehicles # Green computing vs energy efficiency CURRENT: prioritising green computing and energy efficiency over data rate. What is referred to concretely here by “green computing”? Do we target more than “energy efficiency”? If not, consider deleting “green computing”. If maintained, please consider adding a reference of “green computing”. # For this figure and similar, indicate in the narrative text that this assume that no scheduling conflicts, execution errors are encountered. CURRENT: Schedule Schedule Config Generation Execution Distribution | | | --inputs-->| | |--config--> --inputs-->|---schedule--->|---snapshot--->|--config--> --inputs-->| | |--config--> <-----------------------------------------------------> Information Configuration Sources Consumers Figure 2: Centralized Generation with Centralized Execution # Periodic vs recurrent CURRENT: One way to model a periodic change of state is to This statement and similar may suggest that the document assumes some regularity, while recurrence may happen without that regularity. Some of the authors are familiar with the modeling concepts in RFC9922. Maybe clarify the intent in the document. # What is the point of this sentence? CURRENT: The predicted topology-change information may change due to forecasted or unforecasted changes. # Condider labelling the requirements for ease of reference within or outside this document. For example: OLD: An entity must support the identification and advertisement of non- scheduled property changes. NEW: REQ_NON_SCH_CHANGE: An entity must support the identification and advertisement of non- scheduled property changes. # I don’t parse what this requirement is about CURRENT: A Manager should provide an advertisement methodology for responding to abnormal changes in the system. Can we please clarify? # Idem, what is meant concretely here? CURRENT: Systems must support appropriate time tolerance. # Section 4.6. Support Robust Security How this unique to TVR? Shouldn’t this be applicable to any routing information schemes? # New guidance OLD: This section discusses considerations for those areas in the spirit of [RFC5706] but without concrete details of a specific TVR system design. NEW: This section discusses considerations for those areas in the spirit of [I-D. ietf-opsawg-rfc5706bis] but without concrete details of a specific TVR system design. # I have “The requested page could not be found.” when accessing this file: CURRENT: [AIXM] EUROCONTROL and Federal Aviation Administration, "AIXM 5 Temporality Model", 15 September 2010, <https://aixm.aero/sites/aixm.aero/files/imce/AIXM51/ aixm_temporality_1.0.pdf>. Cheers, Med