[OPS-DIR]Re: draft-ietf-teas-rfc8776-update-19 ietf last call Opsdir review

[[e-mail]]

Hi Sergio, 

Thank you for the review. Appreciate that you finalizing it although your time constraint.

The document is scheduled for 08/01/2026. I trust the authors will follow-up by then.

FYI. I finalized my review and balloted YES: https://mailarchive.ietf.org/arch/msg/teas/Zh3s3Ix6B85M-UXwzzGHlqmfOsE/ as I also think this is a solid piece of work.

Cheers,
Med 

> -----Message d'origine-----
> De : Sergio Belotti via Datatracker <[e-mail]>
> Envoyé : mardi 9 décembre 2025 17:46
> À : [e-mail]
> Cc : [e-mail]; last-
> [e-mail]; [e-mail]
> Objet : [OPS-DIR]draft-ietf-teas-rfc8776-update-19 ietf last call
> Opsdir review
> 
> Document: draft-ietf-teas-rfc8776-update
> Title: Common YANG Data Types for Traffic Engineering
> Reviewer: Sergio Belotti
> Review result: Ready
> 
> 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://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> datatracker.ietf.org%2Fdoc%2Fdraft-opsarea-
> rfc5706bis%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7977
> bb73b19d47a864d108de37427409%7C90c7a20af34b40bfbc48b9253b6f5d20%7C
> 0%7C0%7C639008955731443528%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGk
> iOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUI
> joyfQ%3D%3D%7C0%7C%7C%7C&sdata=eh1ZXNo%2BaIT0Vc0S1gP4Q3jaOueBrj8m0
> %2FE8YLBM3rg%3D&reserved=0.
> 
> 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
> 
> ---
> 
> 
> _______________________________________________
> OPS-DIR mailing list -- [e-mail] To unsubscribe send an
> email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.