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

[Ballot comment]
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?

[Ballot comment]
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/

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
Thanks for the presenting the TVR YANG model.  I don't know if I get to use it, but I'm excited about it.

* The model seems capable of modeling linear availability and periodicity.  If the availability is not linear, then I assume the model would approach this with some type of piece-wise linear approach.  Is that correct?  Is it possible to have the model say a node is available with two entries at the same time?  (I didn’t see any reason this couldn’t be true.). Would those be additive?

* There is a timezone for the various schedule entries.  If a non-earth timezone is created, let’s say lunar, what would the `frequency` entry mean if it said something such as `daily`?

[Ballot comment]
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?

[Ballot 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
+                            ^^^^^            +

[Ballot comment]
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.

[Ballot discuss]

# Éric Vyncke INT AD comments for draft-ietf-tvr-schedule-yang-08
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points, some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Tony Li for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Please note that Dirk Von Hugo is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when it will be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-tvr-schedule-yang/reviewrequest/23928/

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.

### Section 4.2

`destination-node` seems to be singular, i.e., does this model only cover point-to-point links ? It so, then it should be made clear in the title/abstract/introduction. Section 5.2 leaf `neighbor` also appear to be singular.

### Section 5.3

```
leaf delay {
                type uint32 {
                  range "0..16777215";
                }
```

Two comments on the above:

1) why limiting to 2**24 rather than the full 32 bits ?

2) 16777215 microseconds is just 16 seconds... i.e., for the 'space' applications it means close the Earth (e.g., Mars is out of scope).

I find the limit very limiting and lacking a rationale. Was this discussed with the TVR WG ?

[Ballot comment]

## COMMENTS (non-blocking)

### Supporting DISCUSS

I support Mahesh's DISCUSS about node-id not being compatible with the IVY model (also about the hierachy of node components).

### TVR in the title ?

Like Med, please add TVR in the title.

### Section 1

In 2026, there is no need to justify the use of YANG, please consider removing the first paragraph.

Unsure whether the module name should include the ".yang" extension as module name is not the same as the filename containing the module. Also applicable to other occurences of the module name.

My understanding is that there is no need to mention NMDA anymore (also applicable in other places).

### Section 3.1

Unsure how to address this issue, but it is unclear on Figure 1 that 'va2' is using the default value, should the box be drawn with 'dots' rather than with '-' ? See also my cosmetic nit about the use of SVG.

### Section 4.1

Please consider renaming 'node-power-schedule' into 'node-active-schedule' as being powered does not mean to be active.

I am really puzzled by the mix of a time-zone dependent leaf `period-start` and UTC-based leaf `start-time-utc` (coming from draft-ietf-netmod-schedule-yang). Is there a reason ? It seems confusing and error-prone. I also hope that the netmod draft handles correctly the daylight saving and leap seconds. But, this is good to re-use YANG modules ;)

### Section 4.2

As TVR could be used in "deep space", is the bandwidth unit in bit/sec correct ? I.e., bandwidth will always be larger than 1 bit/second ? (I guess so but just wanted to check).

### Section 5.3

Why not a MUST rather than a SHOULD in `If the value measured by the system is greater than this value the predicted value SHOULD be used.`

### Section 6

The operational considerations are about TVR itself and not about the use of the YANG models per se.

### Acknowledgements

Suggest listing the tools used by the authors, else this section is really vague ;-)

### Notifications ?

Should these modules also have notifications when the scheduled event occur ?

## 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 ;-)

https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

[Ballot comment]
From a process perspective, the YANG Doctors review was performed
against -03 (five revisions ago). The -08 document has addressed
some but not all of the issues raised. No re-review was requested
for the later revisions. The authors should confirm with the YANG
Doctors that the outstanding issues have been satisfactorily
addressed, but I will let the AD decide how he wants to handle it.

Section 3.2, paragraph 0
>    Module ietf-tvr-node.yang is a device model and designed to manage a
>    single node with scheduled attributes.

Chongfeng Xie (thanks Chongfeng) in his OPSDIR review noted that examples
would be good to have, which the authors have added. Thanks for doing that.
The readers could further benefit from a pointer like "See Appendix B for
an example" from each of these sections.

Section 3.3, paragraph 1
>    The module has a list of nodes, identified by a unique "node-id".
>    Each node has a list of links.  Links are modeled as unidirectional.
>    Link availability is described from the viewpoint of a particular
>    source node (the transmitting node) and beginning at a particular
>    time.  Each link in the list contains the range of times during which
>    it is available.

The YANG Doctors review by Xufeng Liu (thanks Xufeng) noted that this
module models links as unidirectional, described from the viewpoint
of a source node. RFC 8346 calls the equivalent concept a
"link termination-point" rather than a "link." The current document
does not explain this divergence, even as they have used other terms
from RFC8345/8346 like node. Authors should add a sentence in
Section 3.3 either acknowledging the design difference and rationale,
or clarifying how this module relates to the RFC 8345/8346 topology model.

Section 3.3, paragraph 1
>    The "source-link-id" is a string and used to identify a link as
>    viewed from the source-node.  Bandwidth and delay are predicted link
>    attributes.  Delay is the link propagation time and does not include
>    any queuing delays. "destination-node" of a link may follow a
>    schedule as well.

This section states "Delay is the link propagation time and does not
include any queuing delays," but does not say how this value is expected
to be determined (e.g., computed from physical distance, measured via
probing, or operator-configured). A clarifying sentence would help implementors.

Section 5, paragraph 0
>    The following RFC is not referenced in the document text but is
>    referenced in the "ietf-tvr-schedule.yang" module and "ietf-tvr-
>    topology.yang" module: [RFC9911].

This sentence is confusing. How about just saying that "This module
uses definitions from [RFC9911]."?

Section 5.1, paragraph 4
>      description
>        "The YANG module contains common YANG definitions for
>        time-variant schedule.

This model exists to define a single grouping. That grouping
could as well have been defined in the ietf-tvr-node or the
ietf-tvr-topology module. Why the need to define a separate module?

If the reason was to allow this grouping could be used by other
modules, that can happen even if it is part of the ietf-tvr-node.

Section 5.2, paragraph 3
>    import ietf-tvr-schedule {
>      prefix "tvr-schd";
>    }

Please add a reference statement to this draft.

Section 5.2, paragraph 13
>          leaf default-bandwidth {
>            type yang:gauge64;
>            units "bits/second";
>            default "0";
>            description
>              "The default interface bandwidth in bits
>                per second";
>          }

The type is set to guage64. It is defined in RFC9911 as:
The gauge64 type represents a non-negative integer, which
may increase or decrease, but shall never exceed a maximum
value, nor fall below a minimum value.

Curious as to why a gauge was used and not something like
uint64, which can also be used to represent a non-negative
number. Is the default-bandwidth value expected to
increase/decrease during operations?

Section 5.3, paragraph 4
>    import ietf-tvr-schedule {
>      prefix "tvr-schd";
>    }

Please add a reference statement here.

Section 7, paragraph 1
>    Some of the readable data nodes in the ietf-tvr-node.yang module and
>    ietf-tvr-topolgy.yang module may be considered sensitive or
>    vulnerable in some network environments.  It is thus important to
>    control read access (e.g., via get, get-config, or notification) to
>    these data nodes.

This section states, "Some of the readable data nodes in the
ietf-tvr-node.yang module and ietf-tvr-topology.yang module may be
considered sensitive," but does not enumerate which nodes. The YANG
security guidance (as applied in many similar YANG documents) expects
that sensitive readable nodes be specifically called out, just as
writable nodes are. Consider listing the specific subtrees
(e.g., scheduled neighbor information, interface availability)
that operators should consider protecting via read access control.

Also
s/ietf-tvr-topolgy/ietf-tvr-topology/

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

"Abstract", paragraph 0
>    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.  The intent is to have this information be utilized
>    by Time-Variant Routing systems.


s/three modules,/three modules/

Section 1, paragraph 0
>    YANG [RFC7950] is a data definition language used to define the
>    contents of a conceptual data store that allows networked devices to
>    be managed using NETCONF [RFC6241].  YANG is proving relevant beyond
>    its initial confines, as bindings to other interfaces (e.g., ReST)
>    and encodings other than XML (e.g., JSON) are being defined.
>    Furthermore, YANG data models can be used as the basis for
>    implementation of other interfaces, such as CLI and programmatic
>    APIs.


s/ReST/REST/

Section 7, paragraph 2
>    There are a number of data nodes defined in ietf-tvr-node.yang module
>    and ietf-tvr-topology.yang that are writable/creatable/deletable
>    (i.e., config true, which is the default).  These data nodes may be
>    considered sensitive or vulnerable in some network environments.
>    Write operations (e.g., edit-config) to these data nodes without
>    proper protection can have a negative effect on network operations.
>    There are the subtrees and data nodes and their sensitivity/
>    vulnerability:


s/There are the/These are the/

Document references draft-ietf-netmod-schedule-yang, but that has been
published as RFC9922{quote}.

These URLs in the document can probably be converted to HTTPS:

* http://datatracker.ietf.org/wg/tvr

[Ballot discuss]
Section 5.2, paragraph 10
>    revision 2022-02-09 {
>      description
>        "Initial Version";
>      reference
>        "RFC XXXX: YANG Data Model for Scheduled Attributes.";
>    }

The revision date here must have been just a typo error, as it does
not match the date on the CODE BEGINS line.

Section 5.2, paragraph 10
>      leaf node-id {
>        type inet:uri;
>        description
>          "Identifier for a node, uniquely identifies a node.";
>      }

The IVY model (ietf-network-inventory) provides a read-only,
network-wide inventory of physical network elements and their
components, as seen from a controller. While that is a network
level model, there is specific linkage points between the two
drafts. They are:

- node-id <-> ne-id: ietf-tvr-topology uses node-id of type
inet:uri and notes it "may be the same as the node-id defined
in the ietf-network module (RFC 8345)." IVY's ne-id is a string.
In practice, both identify the same physical network element
from the controller's perspective — but there is no formal
binding or leafref between them. This is a gap that could cause
correlation ambiguity in deployments. Considering changing the
node-id to a leafref.

- Augmentation opportunity: IVY is designed to be extended.
A natural companion module could augment
/nwi:network-inventory/nwi:network-elements/nwi:network-element
with TVR schedule groupings to attach planned maintenance windows,
scheduled power-down periods, or availability schedules to inventory
entries. This work does not yet exist in either draft.

- Component-level scheduling gap: IVY goes down to the component
level (cards, ports, chassis). The TVR schedule models only go to the
interface level in ietf-tvr-node. There is no TVR mechanism to attach
schedules to sub-interface components or hardware chassis as
represented in IVY's component list. This could matter in cases
where the sub-interfaces are used (with tagging such as VLAN) to
create different "links".

Section 7, paragraph 2
>      /node-schedule/node-power-schedule
>      /node-schedule/interface-schedule
>      /topology-schedule/nodes/available
>      /topology-schedule/links/available

The ietf-tvr-topology module (Section 5.3) defines list node and list
link (both singular) as children of container topology-schedule.
The correct YANG instance-identifier paths are therefore:

/topology-schedule/node/available
/topology-schedule/link/available

[Ballot comment]
Section 3.2, paragraph 0
>    Module ietf-tvr-node.yang is a device model and designed to manage a
>    single node with scheduled attributes.

Chongfeng Xie (thanks Chongfeng) in his OPSDIR review noted that examples
would be good to have, which the authors have added. Thanks for doing that.
The readers could further benefit from a pointer like "See Appendix B for
an example" from each of these sections.

Section 3.3, paragraph 1
>    The module has a list of nodes, identified by a unique "node-id".
>    Each node has a list of links.  Links are modeled as unidirectional.
>    Link availability is described from the viewpoint of a particular
>    source node (the transmitting node) and beginning at a particular
>    time.  Each link in the list contains the range of times during which
>    it is available.

The YANG Doctors review by Xufeng Liu (thanks Xufeng) noted that this
module models links as unidirectional, described from the viewpoint
of a source node. RFC 8346 calls the equivalent concept a
"link termination-point" rather than a "link." The current document
does not explain this divergence, even as they have used other terms
from RFC8345/8346 like node. Authors should add a sentence in
Section 3.3 either acknowledging the design difference and rationale,
or clarifying how this module relates to the RFC 8345/8346 topology model.

Section 3.3, paragraph 1
>    The "source-link-id" is a string and used to identify a link as
>    viewed from the source-node.  Bandwidth and delay are predicted link
>    attributes.  Delay is the link propagation time and does not include
>    any queuing delays. "destination-node" of a link may follow a
>    schedule as well.

This section states "Delay is the link propagation time and does not
include any queuing delays," but does not say how this value is expected
to be determined (e.g., computed from physical distance, measured via
probing, or operator-configured). A clarifying sentence would help implementors.

Section 5, paragraph 0
>    The following RFC is not referenced in the document text but is
>    referenced in the "ietf-tvr-schedule.yang" module and "ietf-tvr-
>    topology.yang" module: [RFC9911].

This sentence is confusing. How about just saying that "This module
uses definitions from [RFC9911]."?

Section 5.1, paragraph 4
>      description
>        "The YANG module contains common YANG definitions for
>        time-variant schedule.

This model exists to define a single grouping. That grouping
could as well have been defined in the ietf-tvr-node or the
ietf-tvr-topology module. Why the need to define a separate module?

If the reason was to allow this grouping could be used by other
modules, that can happen even if it is part of the ietf-tvr-node.

Section 5.2, paragraph 3
>    import ietf-tvr-schedule {
>      prefix "tvr-schd";
>    }

Please add a reference statement to this draft.

Section 5.2, paragraph 13
>          leaf default-bandwidth {
>            type yang:gauge64;
>            units "bits/second";
>            default "0";
>            description
>              "The default interface bandwidth in bits
>                per second";
>          }

The type is set to guage64. It is defined in RFC9911 as:
The gauge64 type represents a non-negative integer, which
may increase or decrease, but shall never exceed a maximum
value, nor fall below a minimum value.

Curious as to why a gauge was used and not something like
uint64, which can also be used to represent a non-negative
number. Is the default-bandwidth value expected to
increase/decrease during operations?

Section 5.3, paragraph 4
>    import ietf-tvr-schedule {
>      prefix "tvr-schd";
>    }

Please add a reference statement here.

Section 7, paragraph 1
>    Some of the readable data nodes in the ietf-tvr-node.yang module and
>    ietf-tvr-topolgy.yang module may be considered sensitive or
>    vulnerable in some network environments.  It is thus important to
>    control read access (e.g., via get, get-config, or notification) to
>    these data nodes.

This section states, "Some of the readable data nodes in the
ietf-tvr-node.yang module and ietf-tvr-topology.yang module may be
considered sensitive," but does not enumerate which nodes. The YANG
security guidance (as applied in many similar YANG documents) expects
that sensitive readable nodes be specifically called out, just as
writable nodes are. Consider listing the specific subtrees
(e.g., scheduled neighbor information, interface availability)
that operators should consider protecting via read access control.

Also
s/ietf-tvr-topolgy/ietf-tvr-topology/

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

"Abstract", paragraph 0
>    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.  The intent is to have this information be utilized
>    by Time-Variant Routing systems.


s/three modules,/three modules/

Section 1, paragraph 0
>    YANG [RFC7950] is a data definition language used to define the
>    contents of a conceptual data store that allows networked devices to
>    be managed using NETCONF [RFC6241].  YANG is proving relevant beyond
>    its initial confines, as bindings to other interfaces (e.g., ReST)
>    and encodings other than XML (e.g., JSON) are being defined.
>    Furthermore, YANG data models can be used as the basis for
>    implementation of other interfaces, such as CLI and programmatic
>    APIs.


s/ReST/REST/

Section 7, paragraph 2
>    There are a number of data nodes defined in ietf-tvr-node.yang module
>    and ietf-tvr-topology.yang that are writable/creatable/deletable
>    (i.e., config true, which is the default).  These data nodes may be
>    considered sensitive or vulnerable in some network environments.
>    Write operations (e.g., edit-config) to these data nodes without
>    proper protection can have a negative effect on network operations.
>    There are the subtrees and data nodes and their sensitivity/
>    vulnerability:


s/There are the/These are the/

Document references draft-ietf-netmod-schedule-yang, but that has been
published as RFC9922{quote}.

These URLs in the document can probably be converted to HTTPS:

* http://datatracker.ietf.org/wg/tvr

[Ballot comment]
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.

[Ballot comment]
# 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?

[Ballot discuss]
Hi Yingzhen, Acee, Eric, Don, and Marc,

Thank you for the effort put into this specification.

Thanks to Chongfeng Xie for the OPSDIR review and to the authors for engaging and addressing his review.

Please find below some points for DISCUSSion:

# Design Rationale

## ietf-tvr-schedule

This module is not TVR-sepcific but a generic one similar to the one defined in RFC9922. Please update the module name and prefix to follow a patter similar to RFC9922. The description should be updated as well to reflect the generic nature of the module.

## Node module

CURRENT:
  Module ietf-tvr-node.yang is a device model and designed to manage a
  single node with scheduled attributes.

It is not clear to me how this is anchored in NE? What isn’t this defined as an extension to ietf-logical-network-element?

Please consider adding a rationale of this design and how this is supposed to work.

## Idem vs. interface

CURRENT:
  Each node has scheduled power at the node level.  At the interface
  level, a node has a list of interfaces, and each interface has its
  own schedule for availability/power up and down, scheduled bandwidth,
  and scheduled neighbors.

Idem why isn’t this defined as an augmentation of the interface module? How overall consistency will be ensured.

# Idem for the topology

CURRENT:
  Module ietf-tvr-topology.yang describes a network topology with a
  time-variant availability schedule.

Why isn’t this defined as a new ietf-network type + augmentation to RFC 8345 - A YANG Data Model for Network Topologies?

## Some elaboration about the design adopted in the draft compared to the alternatives mentioned above is needed, IMO. Thanks.

# Broken JSON Examples

RF9907 requires the following:

  Examples that are meant to illustrate a valid
  data instance MUST be validated (Section 3.10).

At least all your JSON Examples are broken: namespace issues, type mis-alignment, no quotes for duration, etc.

Please fix all these (you can run yangson or yanglint to fix those).

[Ballot comment]
# Overall, consider adding a discussion how thsi spec meets the requirements of TVR Use Cases.

# Title

## Consider

OLD: YANG Data Model for Scheduled Attributes

NEW: A YANG Data Model for Scheduled Attributes

## I wonder whether you can include TVR in the title as well.

## Please update the title in the reference clauses of your YANG modules.

# Please follow the guidance in Section 2.5 of RFC9907 about data model, model, etc.

## For example, please make this change in the abstract:

OLD: The YANG model

NEW: The YANG data model

## Idem in the Introduction;

OLD:    The YANG model in this document can

NEW:    The YANG data model in this document can

## Please make sure this is used in a consistent manner through the document


# We don’t need to motivate the use of YANG!

I would delete this text:

CURRENT:
  YANG [RFC7950] is a data definition language used to define the
  contents of a conceptual data store that allows networked devices to
  be managed using NETCONF [RFC6241].  YANG is proving relevant beyond
  its initial confines, as bindings to other interfaces (e.g., ReST)
  and encodings other than XML (e.g., JSON) are being defined.
  Furthermore, YANG data models can be used as the basis for
  implementation of other interfaces, such as CLI and programmatic
  APIs.

If you keep it, then s/being defined/defined

# (nit) Reference use cases

OLD:
please reference to
  TVR (Time-Variant Routing) Use Cases [RFC9657].

NEW:
please refer to
  TVR (Time-Variant Routing) Use Cases [RFC9657].

# Please list the modules in the order they are defined in the document:

CURRENT:
  Module ietf-tvr-schedule.yang contains the schedule YANG definitions.
  Module ietf-tvr-topology.yang defines a network topology with time-
  variant availability.  Module ietf-tvr-node.yang is to be used to
  manage scheduled attributes of a single node.

# NMDA: The new guidance is to highlight when we deviate from NMDA

Please delete this statement:

CURRENT:
  The YANG modules in this document conform to the Network Management
  Datastore Architecture (NMDA) [RFC8342].

# RFC9922

CURRENT:
  time" and "recurrence-utc" as defined in
  [I-D.ietf-netmod-schedule-yang].

Please update this reference to RFC9922.

# Users: Not sure to get what is meant by users in this text. Please clarify that in the text.

CURRENT:
  Users can supply attributes or containers that augment the schedule.

# Escape clause for RFC9911 and the like

CURRENT:
  The following RFC is not referenced in the document text but is
  referenced in the "ietf-tvr-schedule.yang" module and "ietf-tvr-
  topology.yang" module: [RFC9911].

You don’t need this text per RFC9907:

  If the module (or modules) defined by the specification imports
  definitions from other modules (except for those defined in [RFC7950]
  or [RFC9911]) or is always implemented in conjunction with other
  modules, then those facts MUST be noted in the overview section;

# Please consider adding a tree with ietf-tvr-schedule grouping

NEW:
module: ietf-tvr-schedule

  grouping tvr-schedule:
    +-- schedule* [schedule-id]
      +-- schedule-id                    uint32
      +-- (schedule-type)?
          +--:(period)
          |  +-- period-description?      string
          |  +-- period-start?            yang:date-and-time
          |  +-- time-zone-identifier?    sys:timezone-name
          |  +-- (period-type)?
          |    +--:(explicit)
          |    |  +-- period-end?        yang:date-and-time
          |    +--:(duration)
          |        +-- duration?          duration
          +--:(recurrence)
            +-- recurrence-first
            |  +-- start-time-utc?  yang:date-and-time
            |  +-- duration?        uint32
            +-- (recurrence-end)?
            |  +--:(until)
            |  |  +-- utc-until?          yang:date-and-time
            |  +--:(count)
            |    +-- count?              uint32
            +-- recurrence-description?  string
            +-- frequency?                identityref
            +-- interval?                uint32


# Update reference clause

OLD:
    import ietf-schedule {
      prefix "schedule";
      reference
        "RFC XXXX: A Common YANG Data Model for Scheduling";
    }

NEW:
    import ietf-schedule {
      prefix "schedule";
      reference
        "RFC 9922: A Common YANG Data Model for Scheduling";
    }

# Update TLP Date of ietf-tvr-schedule s/2025/2026

# Update the description of your modules to follow the IET template in RFC9907, in particular:

OLD:
        This version of this YANG module is part of RFC XXXX
        (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
        for full legal notices.";


NEW:
        All revisions of IETF and IANA published modules can be found
        at the YANG Parameters registry group
        (https://www.iana.org/assignments/yang-parameters).

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.";


# Extra reference clause

OLD:
    reference
      "RFC XXXX: YANG Data Model for Scheduled Attributes";

    revision 2025-06-30 {
      description
        "Initial Version";
      reference
        "RFC XXXX: YANG Data Model for Scheduled Attributes.";
    }

NEW:

    revision 2025-06-30 {
      description
        "Initial Version";
      reference
        "RFC XXXX: A YANG Data Model for Scheduled Attributes.";
    }


# NMDA Again: Please delete the following:

CURRENT:
        This YANG model conforms to the Network Management
        Datastore Architecture (NMDA) as described in RFC 8342.

# The module will live outside the RFC

OLD:
  import ietf-tvr-schedule {
    prefix "tvr-schd";
  }

NEW:
  import ietf-tvr-schedule {
    prefix "tvr-schd";
    reference
      "RFC XXXX: A YANG Data Model for Scheduled Attributes";
  }

# Redundant descriptions

CURRENT:
          type boolean;
          default false;
          description
            "By default, the link is not available.";

        leaf default-bandwidth {
          type yang:gauge64;
          units "bits/second";
          default "0";
          description
            "The default interface bandwidth in bits

The description for both nodes is redundant with “default” clause. Please consider a more meaningful description of the node, without repeating the default clause.

# use “units” statement

CURRENT:
          description
            "The default one-way delay in microseconds.";

Please use units statant rather than having this in the description.

# Explain the recommendation

CURRENT:
  recurrence.  The model defined in this document doesn't prevent a
  configuration to mix both styles.  However, it's not recommended.

I would use NOT RECOMMENDED here. Also, please consider motivate the recommendation.

# Help identify the relevant data nodes

CURRENT:
  The TVR schedule modules are meant to work together with other models
  that manage node or interface attributes. 

You list in your modules some identifiers that might be common (node-id, etc.). I would call these here for awareness.

# Security Considerations

Consider updating to follow the template in RFC9907, Section 3.7.1

# Reference

Please move the following from Normative to Informative

  [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              .

  [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
              .

  [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              .

  [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              .

# Appendix “Example: Add a scheduled cost to OSPF interface”

What is the purpose of this example? Please consider clarifying that in the text.

# Please add a reference to RFC9129 in the following:

CURRENT:
By default, the OSPF interface cost is calculated
  based on the bandwidth of the interface, and it is also configurable.

Cheers,
Med

Request for IETF Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tvr-schedule-yang-08. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

three new namespaces will be registered as follows:

ID: yang:ietf-tvr-schedule
URI: urn:ietf:params:xml:ns:yang:ietf-tvr-schedule
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-tvr-node
URI: urn:ietf:params:xml:ns:yang:ietf-tvr-node
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-tvr-topology
URI: urn:ietf:params:xml:ns:yang:ietf-tvr-topology
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

three new YANG modules will be registered as follows:

Name: ietf-tvr-schedule
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-tvr-schedule
Prefix: tvr-schd
Module:
Reference: [ RFC-to-be ]

Name: ietf-tvr-node
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-tvr-node
Prefix: tvr-node
Module:
Reference: [ RFC-to-be ]

Name: ietf-tvr-topology
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-tvr-topology
Prefix: tvr-topo
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-03-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tvr-schedule-yang@ietf.org, gunter@vandevelde.cc, tony.li@tony.li, tvr-chairs@ietf.org, tvr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for Scheduled Attributes) to Proposed Standard


The IESG has received a request from the Time-Variant Routing WG (tvr) to
consider the following document: - 'YANG Data Model for Scheduled Attributes'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-03-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.  The intent is to have this information be utilized
  by Time-Variant Routing systems.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tvr-schedule-yang/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No discontent noted.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not a protocol document.  No public documented implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

As a YANG module, this will interact with the management plane. This
has been reviewed by YANGDOCTORS, OPSDIR, RTGDIR, and SECDIR.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type
  reviews.

As above, the document has been reviewed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The modules have been verfied using pyang, yanglint, and yangvalidator.
The modules comply with RFC 8342.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The reviews and automated checks have been described above.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There are no outstanding issues with this document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard. This is the proper type of RFC because it will
apply to YANG models throughout the management plane. The datatracker
correctly shows this as "Proposed Standard".

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPR filings on the document. All authors have responded
to the WGLC indicating that they have no knowledge of any IPR. There
has been no discussion.  All author responses can be found here:
https://mailarchive.ietf.org/arch/browse/tvr/?q=IPR%20yang

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are five authors and no editors or contributors. All authors are
willing to be listed as such and support publication.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is one issue with a non-ASCII character in a name in a
reference that is automatically generated.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The status of all references seems appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There are none.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are none.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There is a normative reference to
draft-ietf-netmod-schedule-yang, which is already on the IESG queue.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document makes no changes to any RFC.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This question is unnecessarily self-referential.  I will instead
provide the review:

Disclaimer: I am not a subject matter expert in URI. The URI requested
in the IANA considerations section are consistent with the body of the
document and seem appropriate to me. No new registries are requested.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Not applicable.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It reached broad agreement.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No controversy.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No discontent noted.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Not a protocol document.  No public documented implementations.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

As a YANG module, this will interact with the management plane. This
has been reviewed by YANGDOCTORS, OPSDIR, RTGDIR, and SECDIR.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type
  reviews.

As above, the document has been reviewed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The modules have been verfied using pyang, yanglint, and yangvalidator.
The modules comply with RFC 8342.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

The reviews and automated checks have been described above.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes, this document is needed, clearly written, complete, correctly
designed, and ready to be handed off to the responsible Area Director.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

There are no outstanding issues with this document.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed standard. This is the proper type of RFC because it will
apply to YANG models throughout the management plane. The datatracker
correctly shows this as "Proposed Standard".

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

There are no IPR filings on the document. All authors have responded
to the WGLC indicating that they have no knowledge of any IPR. There
has been no discussion.  All author responses can be found here:
https://mailarchive.ietf.org/arch/browse/tvr/?q=IPR%20yang

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

There are five authors and no editors or contributors. All authors are
willing to be listed as such and support publication.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

There is one issue with a non-ASCII character in a name in a
reference that is automatically generated.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

The status of all references seems appropriate.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

There are none.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

There are none.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

There is a normative reference to
draft-ietf-netmod-schedule-yang, which is already on the IESG queue.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document makes no changes to any RFC.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

This question is unnecessarily self-referential.  I will instead
provide the review:

Disclaimer: I am not a subject matter expert in URI. The URI requested
in the IANA considerations section are consistent with the body of the
document and seem appropriate to me. No new registries are requested.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

Not applicable.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/