Early Review of draft-ietf-rtgwg-qos-model-15
review-ietf-rtgwg-qos-model-15-yangdoctors-early-liu-2026-06-27-00

This is a review of the YANG modules in draft-ietf-rtgwg-qos-model-15.

Jürgen has reviewed this document twice and provided great feedback. The
authors have addressed the comments, with one remaining question about the
document title.

The current title of the document is “YANG Models for Quality of Service (QoS)
in IP networks”, while the abstract section of the document is “This document
describes a YANG model for management of Quality of Service (QoS) in IP
networks.”

RFC 7950 defines that a data model describes how data is represented and
accessed. A YANG data model is defined in one or more YANG modules. In our
case, all the data described and modeled in this document is for the logical
concept of QOS, containing multiple YANG modules, so it would be better to use
the statement in the abstract section to make the title “A YANG Model for
Quality of Service (QoS) in IP networks”

Additional comments:
1) ietf-queue-policy

1.1) The list name “wred” is the same as its parent container name. When a list
is defined in a container, an IETF convention is to use the plural form for the
parent container name and the singular form for the list name.

1.2) In the list “wred”, profile is the key, not color-type and color-val. Can
the same color be used in two separate wred list items? In such a case, what
behavior do we expect regarding drop policies? Some description or YANG
mechanism would be beneficial.

2) ietf-qos-oper

2.1) Most of the lists do not have keys. Such a style is allowed in YANG, but
is it really what you want? How many items may be reported in these lists? Do
you want to conveniently query and filter these items?

2.2) The list names are not the conventional names for YANG lists, such as
“metering” instead of “meter”.

2.3) Does the list “named” mean the list of “named-qos-count”? If so, can we
expand the list name to “named-qos-count”, “named-count”, or “named-counter”? I
know that there is a description in the document, but YANG emphasizes
meaningfulness more than compactness. We’d better avoid uncommon terms and not
ask readers to check the document text for every term.

3)  ietf-qos-action and  ietf-traffic-policy

3.1) Child name and parent name
In ietf-qos-action, single-rate-two-color-meter repeats “meter” from its parent
name “meter”. Such a repeat is better avoided according to the guidelines.
However, for the in-line meter in ietf-traffic-policy, there is no parent list
“meter”. More interestingly, there is a sibling container called “meter” used
to reference a meter by name. I’m wondering if these can be organized a bit
more cleanly.

3.2) Presence container
Under policies/policy, there is a presence container “inline”. Usually, a
presence container has a semantic meaning when it exists without any children.
In this case, what does an empty container “inline” mean? Why does this
container need to use “presence”?

Thanks,
- Xufeng