IETF LC SecDir review of draft-ietf-teas-rfc8776-update-19

[italobusi]

Document: draft-ietf-teas-rfc8776-update
Title: Common YANG Data Types for Traffic Engineering
Reviewer: Tero Kivinen
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document provides common yang data types for other modules to use.
It does not define a model itself so it does not as such has any direct security considerations.

Security Considerations section follows the YANG model template, and seems to be ok.

This document uses HUGE number of RFCs only referenced by the RFC number which makes it really hard to follow when you have text saying

  A base YANG identity for supported LSP path
  flags as defined in [RFC3209], [RFC4090], [RFC4736], [RFC5712],
  [RFC4920], [RFC5420], [RFC7570], [RFC4875], [RFC5151], [RFC5150],
  [RFC6001], [RFC6790], [RFC7260], [RFC8001], [RFC8149], and
  [RFC8169].

This makes it difficult for someone who does not have full RFC number to title mapping in their head to read the document. It would be better to provide the RFC title in the text and just use RFC number as a reference.

For example:

In section 1 change:

Section 4.12 of [I-D.ietf-netmod-rfc8407bis] and Section 4.13 of
[I-D.ietf-netmod-rfc8407bis].

to

Section 4.12 and Section 4.13 of YANG Data Models guidelines
document [I-D.ietf-netmod-rfc8407bis].

and for example in section 1.1 change:

The terminology for describing YANG data models is found in
[RFC7950].

to

The terminology for describing YANG data models is found in YANG
Data Modeling Language [RFC7950].

Other places where just plain RFC number is used:

• Section 1.2, RFC6991
• Section 1.3, RFC8340
• Section 3.1.1, I-D.ietf-pce-sid-algo-14, RFC2702, RFC3209, RFC3209,
  RFC3209, RFC3471, RFC3471, RFC3630, RFC3785, RFC4090, RFC4328,
  RFC4736, RFC4872, RFC4872, RFC4872, RFC4872, RFC4872, RFC4873,
  RFC4873, RFC4875, RFC4875, RFC4920, RFC5150, RFC5151, RFC5420,
  RFC5440, RFC5541, RFC5541, RFC5712, RFC6001, RFC6002, RFC6004,
  RFC6004, RFC6368, RFC6780, RFC6790, RFC7074, RFC7138, RFC7260,
  RFC7271, RFC7471, RFC7471, RFC7570, RFC8001, RFC8149, RFC8169,
  RFC8233, RFC8570, RFC8570, RFC8685, and RFC8800.
• Section 3.1.1.1, FC5440, RFC5441, RFC5520, RFC5557, RFC8306, and
  RFC8685.
• Section 3.1.1.2, RFC5440 and RFC9012
• Section 3.1.2, RFC4124, RFC6370, RFC5003, RFC3630, RFC6827, RFC5305,
  RFC6119, RFC6827, RFC8345, RFC3630, RFC5305, RFC4872, RFC3630,
  RFC5305, RFC7308, RFC4203, RFC5307, RFC3785, RFC6378, RFC4427,
  and RFC3630.
• Section 3.1.3, RFC7471, RFC8570, RFC7823, RFC3209, and RFC3477.
• Section 3.2.1, RFC4090, RFC4125, RFC4126, RFC4127, MEF_10.3,
  RFC2697 and RFC2698.
• Section 4, RFC6991, RFC8294, RFC6991, RFC8294, RFC9522, RFC4090,
  RFC4202, RFC4328, RFC4561, RFC4657, RFC4736, RFC6004, RFC6378,
  RFC6511, RFC7139, RFC7271, RFC7308, RFC7551, RFC7571, RFC7579,
  and ITU-T_G.709.
• Appendix A, RFC8340

See: https://mailarchive.ietf.org/arch/msg/teas/8lDfVku2QrOqtCQqIO9PwxxsObk/

[italobusi]

2025-12-05 TE Call

We believe that adding the RFC title would make the text more cluttered.
Is there any precedence or guidelines for doing this (please provide a pointer)?

[italobusi]

See: https://mailarchive.ietf.org/arch/msg/teas/9ua4nEdmbcBgU2WchfmENanIxus/

[italobusi]

See: https://mailarchive.ietf.org/arch/msg/teas/J4IFekzkoV5d6wUxFE7M-r59Oq8/

See also:

• https://mailarchive.ietf.org/arch/msg/teas/ptltCfNVE60i9zuSuZgxuECZ3VY/
• Paul Wouters' No Objection on draft-ietf-teas-rfc8776-update-20 #331