[Tvr] 答复: Christopher Inacio's No Objection on draft-ietf-tvr-requirements-08: (with COMMENT)

["zhangli (CE)" <[e-mail]>]

Hi Christopher,

Many thanks for your review, and sorry for replying so late. The authors just submitted a new version(10). I think it addresses your comments. Please see our response in line with [Li].

Here is the link for the latest version: https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/ 

Best regards
Li

> -----邮件原件-----
> 发件人: Christopher Inacio via Datatracker <[e-mail]>
> 发送时间: 2026年4月16日 4:08
> 收件人: The IESG <[e-mail]>
> 抄送: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> 主题: Christopher Inacio's No Objection on draft-ietf-tvr-requirements-08:
> (with COMMENT)
> 
> Christopher Inacio has entered the following ballot position for
> draft-ietf-tvr-requirements-08: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tvr-requirements/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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)~>.

[Li]: thanks, we have updated. 

> 
> * 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.

[Li]: we have added a paragraph in section 2.2.9 to explain that the priority mechanism is not intended to specify queueing behavior, physical medium sharing, or resource arbitration. Any solution using schedule priority to drive constrained resources needs additional technology-specific handling.