Mahesh Jethanandani's Discuss on draft-ietf-teas-rfc8776-update-20

[italobusi]

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-teas-rfc8776-update-20: Discuss

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-teas-rfc8776-update/

---

DISCUSS:

"Abstract", paragraph 0

This document defines a collection of common data types, identities,
and groupings in YANG data modeling language. These derived common
data types, identities and groupings are intended to be imported by
other modules, e.g., those which model the Traffic Engineering (TE)
configuration and state capabilities.

I have to agree with Eric and Joel Halpern (BTW, thanks, Joel, for your GENART
review) about the fact that most of these definitions are, if anything,
technology-specific, and the draft needs to reflect that. It is not enough to
say that the definitions in this draft "can be used by any module" and, by
implication, with other technologies, unless those technologies are also
covered comprehensively by this module. Certainly, the assertion that the
module is technology agnostic needs to be scrutinized.

If the authors agree that the definitions are MPLS specific, I would not
suggest renaming the module, as that is a much bigger change and will not play
well with obsoleting RFC 8776. I would rather just update the description in
the draft and in the YANG module to reflect that fact, and hope one day the
module will be truly technology agnostic.

Section 4, paragraph 21

      This revision obsoletes the following identities:
      - of-minimize-agg-bandwidth-consumption;
      - of-minimize-load-most-loaded-link;
      - of-minimize-cost-path-set;
      - lsp-protection-reroute-extra;
      - lsp-protection-reroute.

draft-ietf-netmod-rfc8407bis in Section 4.7 says that:

The status SHOULD NOT be changed from "current" directly to "obsolete". An
object SHOULD be available for at least one year after the publication date
with a "deprecated" status before it is changed to "obsolete".

Yet, this document has clearly done exactly that. Was it not possible to
deprecate the above identities, introduce the new identities, and a year later,
obsolete the identities that were deprecated?

Section 6, paragraph 5

This document requests IANA to register the following YANG modules in
the "YANG Module Names" registry [RFC6020][RFC9890] within the "YANG
Parameters" registry group.

     name:      ietf-te-types
     Maintained by IANA?  N
     namespace: urn:ietf:params:xml:ns:yang:ietf-te-types
     prefix:    te-types
     reference: RFC XXXX

     name:      ietf-te-packet-types
     Maintained by IANA?  N
     namespace: urn:ietf:params:xml:ns:yang:ietf-te-packet-types
     prefix:    te-packet-types
     reference: RFC XXXX

Why is this registration request being made? Should the request not be for an
update to refer to this document?

Section 7, paragraph 5

The YANG modules define a set of identities, types, and groupings.
These nodes are intended to be reused by other YANG modules. The
modules by themselves do not expose any data nodes that are writable,
data nodes that contain read-only state, or RPCs. As such, there are
no additional security issues related to the YANG module that need to
be considered.

Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example using 'explicit-route-hop', 'record-route-state' or 'te-
topology-identifier' (which includes the 'client-id') groupings may
expose sensitive topology information.

If there are no security issues that need to be discussed here, why is the rest
of the text needed? Just these paragraphs should suffice, no?

---

COMMENT:

Section 1.2, paragraph 1

+=================+======================+========================+
| Prefix          | YANG module          | Reference              |
+=================+======================+========================+
| yang            | ietf-yang-types      | Section 3 of [RFC6991] |
+-----------------+----------------------+------------------------+
| inet            | ietf-inet-types      | Section 4 of [RFC6991] |
+-----------------+----------------------+------------------------+
| rt-types        | ietf-routing-types   | [RFC8294]              |
+-----------------+----------------------+------------------------+
| te-types        | ietf-te-types        | RFCXXXX                |
+-----------------+----------------------+------------------------+
| te-packet-types | ietf-te-packet-types | RFCXXXX                |
+-----------------+----------------------+------------------------+

Please update all references to RFC6991 to point to RFC 9911.

Section 4, paragraph 14

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

Is this draft publishing an IANA module? If not, please remove reference to
IANA modules.

Section 4, paragraph 34

 identity lsp-provisioning-error-reason {
   description
     "Base identity for LSP provisioning errors.";
 }

I do not see this base identity being used in this module or in this document.
If this is intended to be used somewhere else or at a later time, it would be
better to define it there or at that time.

Section 4, paragraph 358

   leaf one-way-delay {
     type uint32 {
       range "0..16777215";
     }
     units "microseconds";
     description
       "One-way delay or latency.";
   }

Is there a reference that can be cited for this? Or even an explanation for how
it can be measured. Per MEF 10.3, "One-way delay is difficult to measure and
therefore one-way delay may be approximated from two-way measurements."

Section 4, paragraph 357

   leaf one-way-delay-normality {
     type te-types:performance-metrics-normality;
     description
       "One-way delay normality.";
   }

This description and several like these are essentially a repeat of the name of
the node without an explanation for what it is. Either an explanation or a
reference is the minimum one should expect from these modules.

Section 4, paragraph 358

   leaf two-way-delay {
     type uint32 {
       range "0..16777215";
     }
     units "microseconds";
     description
       "Two-way delay or latency.";
   }

Same question here for reference.

Section 5, paragraph 0

The "ietf-te-packet-types" module imports from the "ietf-te-types"
module defined in Section 4 of this document.

How about RFC 6991 or more precisely RFC 9911?

Section 5, paragraph 1

 // RFC Editor: Please replace XXXX above with the RFC number
 // assigned to this document.
 // Please remove this note.

Can all these RFC Editor directives be consolidated in one place instead of
scattering them across the document?

Section 5, paragraph 54

 grouping bandwidth-profile-parameters {
   description
     "Common parameters to define bandwidth profiles in packet
      networks.";
   leaf cir {
     type uint64;
     units "bits per second";
     description
       "Committed Information Rate (CIR).";
   }
   leaf cbs {
     type uint64;
     units "bytes";
     description
       "Committed Burst Size (CBS).";
   }
   leaf eir {
     type uint64;
     units "bits per second";
     description
       "Excess Information Rate (EIR).";
   }
   leaf ebs {
     type uint64;
     units "bytes";
     description
       "Excess Burst Size (EBS).";
   }
   leaf pir {
     type uint64;
     units "bits per second";
     description
       "Peak Information Rate (PIR).";
   }
   leaf pbs {
     type uint64;
     units "bytes";
     description
       "Peak Burst Size (PBS).";
   }
 }

Please cite the reference of MEF 10.3 for these parameters as suggested by
Sergio Belotti. BTW, thanks, Sergio, for your OPSDIR review.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

• Term "he"; alternatives might be "they", "them", "their"

---

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.

Reference [RFC6991] to RFC6991, which was obsoleted by RFC9911 (this may be on
purpose).

"I", paragraph 53

with the alternate route being pre-computed and stored for use when the fai
^^^^^^^^^^^^
Do not mix variants of the same word ("pre-compute" and "precompute") within a
single text.

"I", paragraph 196

es a type representing the access type of a TE link."; reference "RFC 3630: T
^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

"I", paragraph 210

ition, and the user traffic is being transported (or selected) on the recove
^^^^^^^^^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

"I", paragraph 333

address or dotted quad address or as an URI. The type data node disambiguate
^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

"I", paragraph 397

c-editor.org/rfc/rfc9522>. Appendix A. The Complete Schema Trees This appendi
^^
It seems like there are too many consecutive spaces here.

Section 8, paragraph 10

ready defined in [RFC8776], have been updated in the 'explicit-route-hop': -
^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

Section 8, paragraph 11

n replaced by must statements that requires at least the presence of: o node
^^^^^^^^
Possible subject-verb agreement error detected.

Section 8, paragraph 12

n replaced by must statements that requires at least the presence of: o node
^^^^^^^^
Possible subject-verb agreement error detected.

Section 8, paragraph 14

constraints; The following new leaf have been added to the 'tunnel-constraint
^^^^
The verb form "have" does not seem to match the subject "leaf".

Section 8, paragraph 15

jects-always; The container has been renamed as 'explicit-route-objects'. Thi
^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

See: https://mailarchive.ietf.org/arch/msg/teas/1m74kPkAUeCwwnWx62eQY4MeJMk/

[boucadair]

ection 4, paragraph 14

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

Is this draft publishing an IANA module? If not, please remove reference to IANA modules.

This is part of the template in RFC8407bis for IETF modules. The draft has this right and I don't think any action is needed.

[boucadair]

Section 7, paragraph 5

The YANG modules define a set of identities, types, and groupings.
These nodes are intended to be reused by other YANG modules. The
modules by themselves do not expose any data nodes that are writable,
data nodes that contain read-only state, or RPCs. As such, there are
no additional security issues related to the YANG module that need to
be considered.
Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example using 'explicit-route-hop', 'record-route-state' or 'te-
topology-identifier' (which includes the 'client-id') groupings may
expose sensitive topology information.

If there are no security issues that need to be discussed here, why is the rest of the text needed? Just these paragraphs should suffice, no?

The doc is following the template from 8407bis. The first para are always present for all modules.

[italobusi]

Input for follow-up discussion:

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-teas-rfc8776-update-20: Discuss

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-teas-rfc8776-update/

---

DISCUSS:

"Abstract", paragraph 0

This document defines a collection of common data types, identities,
and groupings in YANG data modeling language. These derived common
data types, identities and groupings are intended to be imported by
other modules, e.g., those which model the Traffic Engineering (TE)
configuration and state capabilities.

I have to agree with Eric and Joel Halpern (BTW, thanks, Joel, for your GENART
review) about the fact that most of these definitions are, if anything,
technology-specific, and the draft needs to reflect that. It is not enough to
say that the definitions in this draft "can be used by any module" and, by
implication, with other technologies, unless those technologies are also
covered comprehensively by this module. Certainly, the assertion that the
module is technology agnostic needs to be scrutinized.

If the authors agree that the definitions are MPLS specific, I would not
suggest renaming the module, as that is a much bigger change and will not play
well with obsoleting RFC 8776. I would rather just update the description in
the draft and in the YANG module to reflect that fact, and hope one day the
module will be truly technology agnostic.

Italo: I think this comment is being addressed in the replies to Eric's and Joel's comments

Section 4, paragraph 21

      This revision obsoletes the following identities:
      - of-minimize-agg-bandwidth-consumption;
      - of-minimize-load-most-loaded-link;
      - of-minimize-cost-path-set;
      - lsp-protection-reroute-extra;
      - lsp-protection-reroute.

draft-ietf-netmod-rfc8407bis in Section 4.7 says that:

The status SHOULD NOT be changed from "current" directly to "obsolete". An
object SHOULD be available for at least one year after the publication date
with a "deprecated" status before it is changed to "obsolete".

Yet, this document has clearly done exactly that. Was it not possible to
deprecate the above identities, introduce the new identities, and a year later,
obsolete the identities that were deprecated?

See #335

Section 6, paragraph 5

This document requests IANA to register the following YANG modules in
the "YANG Module Names" registry [RFC6020][RFC9890] within the "YANG
Parameters" registry group.

     name:      ietf-te-types
     Maintained by IANA?  N
     namespace: urn:ietf:params:xml:ns:yang:ietf-te-types
     prefix:    te-types
     reference: RFC XXXX

     name:      ietf-te-packet-types
     Maintained by IANA?  N
     namespace: urn:ietf:params:xml:ns:yang:ietf-te-packet-types
     prefix:    te-packet-types
     reference: RFC XXXX

Why is this registration request being made? Should the request not be for an
update to refer to this document?

Italo: I think this has been already clarified by Med on the mailing list and no action is needed.

Section 7, paragraph 5

The YANG modules define a set of identities, types, and groupings.
These nodes are intended to be reused by other YANG modules. The
modules by themselves do not expose any data nodes that are writable,
data nodes that contain read-only state, or RPCs. As such, there are
no additional security issues related to the YANG module that need to
be considered.

Modules that use the groupings that are defined in this document
should identify the corresponding security considerations. For
example using 'explicit-route-hop', 'record-route-state' or 'te-
topology-identifier' (which includes the 'client-id') groupings may
expose sensitive topology information.

If there are no security issues that need to be discussed here, why is the rest
of the text needed? Just these paragraphs should suffice, no?

Italo: As clarified by Med in #329 (comment) this is aligned with the template from 8407bis and no action is needed.

---

COMMENT:

Section 1.2, paragraph 1

+=================+======================+========================+
| Prefix          | YANG module          | Reference              |
+=================+======================+========================+
| yang            | ietf-yang-types      | Section 3 of [RFC6991] |
+-----------------+----------------------+------------------------+
| inet            | ietf-inet-types      | Section 4 of [RFC6991] |
+-----------------+----------------------+------------------------+
| rt-types        | ietf-routing-types   | [RFC8294]              |
+-----------------+----------------------+------------------------+
| te-types        | ietf-te-types        | RFCXXXX                |
+-----------------+----------------------+------------------------+
| te-packet-types | ietf-te-packet-types | RFCXXXX                |
+-----------------+----------------------+------------------------+

Please update all references to RFC6991 to point to RFC 9911.

Italo: I am ok with this change (see draft PR #334 )

Section 4, paragraph 14

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

Is this draft publishing an IANA module? If not, please remove reference to
IANA modules.

Italo: As clarified by Med in #329 (comment) this is aligned with the template from 8407bis and no action is needed.

Section 4, paragraph 34

 identity lsp-provisioning-error-reason {
   description
     "Base identity for LSP provisioning errors.";
 }

I do not see this base identity being used in this module or in this document.
If this is intended to be used somewhere else or at a later time, it would be
better to define it there or at that time.

Italo: this identity is defined here since it is intended to be used by more than one module

Section 4, paragraph 358

   leaf one-way-delay {
     type uint32 {
       range "0..16777215";
     }
     units "microseconds";
     description
       "One-way delay or latency.";
   }

Is there a reference that can be cited for this? Or even an explanation for how
it can be measured. Per MEF 10.3, "One-way delay is difficult to measure and
therefore one-way delay may be approximated from two-way measurements."

<Italo>

• need help for the definition within the grouping one-way-performance-metrics (from the grouping description it seems related to throttling)

Note: for the leaf defined in the grouping performance-metrics-one-way-delay-loss, the references are already provided for the whole grouping.

<\Italo>

Section 4, paragraph 357

   leaf one-way-delay-normality {
     type te-types:performance-metrics-normality;
     description
       "One-way delay normality.";
   }

This description and several like these are essentially a repeat of the name of
the node without an explanation for what it is. Either an explanation or a
reference is the minimum one should expect from these modules.

Italo: the references are already provided for the whole grouping

Section 4, paragraph 358

   leaf two-way-delay {
     type uint32 {
       range "0..16777215";
     }
     units "microseconds";
     description
       "Two-way delay or latency.";
   }

Same question here for reference.

<Italo>

• need help for the definition within the grouping two-way-performance-metrics (from the grouping description it seems related to throttling)

Note: for the leaf defined in the grouping performance-metrics-two-way-delay-loss, the references are already provided for the whole grouping.

<\Italo>

Section 5, paragraph 0

The "ietf-te-packet-types" module imports from the "ietf-te-types"
module defined in Section 4 of this document.

How about RFC 6991 or more precisely RFC 9911?

Italo: I think the text needs to be fixed (see draft PR #334 )

Section 5, paragraph 1

 // RFC Editor: Please replace XXXX above with the RFC number
 // assigned to this document.
 // Please remove this note.

Can all these RFC Editor directives be consolidated in one place instead of
scattering them across the document?

Italo: Ok to consolidate all the RFC Editor directives in one place (see draft PR #334 ). I have asked offline Med some suggestion on what to do for the module revision dates

Section 5, paragraph 54

 grouping bandwidth-profile-parameters {
   description
     "Common parameters to define bandwidth profiles in packet
      networks.";
   leaf cir {
     type uint64;
     units "bits per second";
     description
       "Committed Information Rate (CIR).";
   }
   leaf cbs {
     type uint64;
     units "bytes";
     description
       "Committed Burst Size (CBS).";
   }
   leaf eir {
     type uint64;
     units "bits per second";
     description
       "Excess Information Rate (EIR).";
   }
   leaf ebs {
     type uint64;
     units "bytes";
     description
       "Excess Burst Size (EBS).";
   }
   leaf pir {
     type uint64;
     units "bits per second";
     description
       "Peak Information Rate (PIR).";
   }
   leaf pbs {
     type uint64;
     units "bytes";
     description
       "Peak Burst Size (PBS).";
   }
 }

Please cite the reference of MEF 10.3 for these parameters as suggested by
Sergio Belotti. BTW, thanks, Sergio, for your OPSDIR review.

Italo: as discussed with Sergio, I would reference the generic term 'traffic profile' defined in RFC 2475 and cite MEF 10, RFC 2697 and RFC 2798 as examples of bandwidth profiles which can be defined using this model (see PR #334 )

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

• Term "he"; alternatives might be "they", "them", "their"

Italo: I was not able to find any use of the term "he"

• @ALL pleas double check

---

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.

Reference [RFC6991] to RFC6991, which was obsoleted by RFC9911 (this may be on
purpose).

Italo: I agree (see draft PR #334 )

"I", paragraph 53

with the alternate route being pre-computed and stored for use when the fai
^^^^^^^^^^^^
Do not mix variants of the same word ("pre-compute" and "precompute") within a
single text.

Italo: I think we can use precompute/precomputed consistently (see draft PR #334 )

"I", paragraph 196

es a type representing the access type of a TE link."; reference "RFC 3630: T
^^^^^^^^^
If "type" is a classification term, "a" is not necessary. Use "type of". (The
phrases "kind of" and "sort of" are informal if they mean "to some extent".).

• @ALL: need help with English grammar (type is used twice so I do not understand what to change)

"I", paragraph 210

ition, and the user traffic is being transported (or selected) on the recove
^^^^^^^^^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

Italo: I think that the passive voice is better in this sentence since there is no clear subject for the active sentence

"I", paragraph 333

address or dotted quad address or as an URI. The type data node disambiguate
^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

Italo: I agree (see draft PR #334 )

"I", paragraph 397

c-editor.org/rfc/rfc9522>. Appendix A. The Complete Schema Trees This appendi
^^
It seems like there are too many consecutive spaces here.

Italo: the spaces are added by the I-D tool, no change needed

Section 8, paragraph 10

ready defined in [RFC8776], have been updated in the 'explicit-route-hop': -
^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

Italo: I think that the passive sentence is appropriate here

Section 8, paragraph 11

n replaced by must statements that requires at least the presence of: o node
^^^^^^^^
Possible subject-verb agreement error detected.

Italo: I would add some quotes for "must" (see draft PR #334 )

Section 8, paragraph 12

n replaced by must statements that requires at least the presence of: o node
^^^^^^^^
Possible subject-verb agreement error detected.

Italo: same as above (see draft PR #334 )

Section 8, paragraph 14

constraints; The following new leaf have been added to the 'tunnel-constraint
^^^^
The verb form "have" does not seem to match the subject "leaf".

Italo: I agree (see draft PR #334 )

Section 8, paragraph 15

jects-always; The container has been renamed as 'explicit-route-objects'. Thi
^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

Italo: I think that the passive sentence is appropriate here

[boucadair]

I have asked offline Med some suggestion on what to do for the module revision dates

I created a PR for your convenience at #336 to address this.

[italobusi]

2026-01-16 TE Call

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

• Term "he"; alternatives might be "they", "them", "their"

Italo: I was not able to find any use of the term "he"

• @ALL pleas double check

It is confirmed that the only appearance of the term "he" is the surname "He" in the reference section so no action is needed.