IETF Last Call Review of draft-ietf-teas-rfc8776-update-19
review-ietf-teas-rfc8776-update-19-opsdir-lc-belotti-2025-12-09-00
review-ietf-teas-rfc8776-update-19-opsdir-lc-belotti-2025-12-09-00
Hi, I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered. A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/. While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received. - Document: [draft-ietf-teas-rfc8776-update-19] - Reviewer: [Sergio Belotti] - Review Date: [2025-12-09] - Intended Status: [Proposed Standard] --- ## Summary - This document is basically ready for publication but has nits that should be considered prior to publication. This document introduces a collection of common data types derived from the built-in YANG data types. The derived data types, identities, and groupings are mainly designed to be the common definitions applicable in Traffic Engineering (TE) model(s) defined outside of this document The document obsoletes [RFC8776] updating some of the existing data types, identities, and groupings and fixes few bugs in [RFC8776]. It provides a new revision of the YANG module contained in that RFC, and retains the data types previously defined, but also adds new type definitions to both the "ietf-te-types" and the "ietf-te-packet-types" YANG modules defined in this document. The document is clear and well-written. The motivation is described well. The document is almost ready for publication even if some minor comments it would be good to be fixed before publication. No major issues found. ## Minor Issues ### Section #### Section 3.1.1 link-protection-type :I think for link-protection-type should be better to reference RFC3471 and leave the reference for RFC 4872 for lsp-protection-type switching-capabilities: It is stated "Additional technology-specific interface switching capabilities can be defined in other technology-specific models ." but in reality some additional technology-specific interface switching capabilities have been added in the te-types module. We should probably delete this sentence or delete the switching capabilities introduced in the modules. protocol-origin-type: I do not see any definition of protocol origin even in the RFCs referenced in section 3.1.1.2. svec-metric-type: Maybe here there is a wrong copy&paste : I suppose it would be SVEC metric list #### Section 3.1.1.1 path-computation-error-no-dependent-server: It is stated "The dependent path computation server could be a Backward- Recursive Path Computation (BRPC) downstream PCE or a child PCE" --> I would add the reference to RFC5441 where BRPC is defined #### Section 3.1.2 admin-groups:I would suggest to put RFC reference close to the word classic or extended to make more clear the correct reference . That means:“ A union type for a TE link's classic or extended administrative groups as defined in [RFC3630], [RFC5305] for classic and [RFC7308] for extended. #### Section 3.2.3 performance-metrics-attributes-packet : There are new data nodes in this grouping without any reference. E.G. “one-way-min-delay” defines a range but no reference to understand where/how this range is defined bandwidth-profile-parameters : The grouping describes Ethernet traffic parameters but does not indicate reference for them. Please add RFC6003 or MEF10.1 as reference ### YANG identity lsp-encoding-oduk: The document should be technology agnostic. Not sure this encoding should be here and not in L1-types for OTN specific. identity route-include-object: Maybe the reference to RFC3209 and RFC3473 is still valid since both the document allow “abstract nodes and resources to be explicitly included” case as-number { --> No description related to this “case” as-number statement container as-number-hop ### Appendix B te-gen-node-id : This data type is mentioned as “new” data type added to “ietf-te-types” but is present in the Appendix B but not in the YANG schema. ## Nits > Section 3.1.1.1: path-computation-error-no-dependent-server: 3. match more than one PCEP numbers --> Nits s/numbers/number > Section 3.1.2: te-recovery-status: s/statuses/status ---