Thanks Joel for your feedbacks We have just uploaded draft-ietf-teas-rfc8776-update-21 with the text changes proposed below
Thanks, Italo (on behalf of co-auhtors/contributors) From: jmh.direct <[email protected]> Sent: venerdì 16 gennaio 2026 19:25 To: Italo Busi <[email protected]>; Joel Halpern <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: draft-ietf-teas-rfc8776-update-20 ietf last call Genart review Yes, those changes address my concerns. In particular, the first change nicely clarifies the scope. Thank you, Joel Sent via the Samsung Galaxy S20 FE 5G, an AT&T 5G smartphone -------- Original message -------- From: Italo Busi <[email protected]<mailto:[email protected]>> Date: 1/16/26 1:13 PM (GMT-05:00) To: Joel Halpern <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]>, [email protected]<mailto:[email protected]> Subject: RE: draft-ietf-teas-rfc8776-update-20 ietf last call Genart review Hi Joel, The authors and contributors discussed this issue today and the proposal is to update the text in section 3.1 as follows: OLD The "ietf-te-types" module (Section 4) contains common TE types that are independent and agnostic of any specific technology or control-plane instance. NEW The "ietf-te-types" module (Section 4) contains TE types that are commonly used across multiple TE technology-specific modules. Regarding the definition of the session-attributes-flags, we noted that the union of the session-attributes-flags and lsp-attributes-flags provides the list of all the path attributes that can be applied to any type of TE path although originally defined for RSVP-TE SESSION_ATTRIBUTE object and RSVP-TE LSP_ATTRIBUTES object and we would propose the following changes to YANG: OLD identity session-attributes-flags { description "Base identity for the RSVP-TE session attributes flags."; } identity lsp-attributes-flags { description "Base identity for LSP attributes flags."; } NEW identity session-attributes-flags { description "Base identity for the path attributes flags as defined for the RSVP-TE SESSION_ATTRIBUTE object."; } identity lsp-attributes-flags { description "Base identity for the path attributes flags as defined for the RSVP-TE LSP_ATTRIBUTES object."; } Would these changes address your concerns? Thanks, Italo (on behalf of co-authors/contributors) From: Joel Halpern <[email protected]<mailto:[email protected]>> Sent: giovedì 15 gennaio 2026 21:06 To: Italo Busi <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: draft-ietf-teas-rfc8776-update-20 ietf last call Genart review At the very least, it would help if you would mark which things are included for compatibility even though they don't fit the paradigm. Yours, Joel On 1/15/2026 1:33 PM, Italo Busi wrote: Hi Joel, For the session-attributes-flags, I will further check with the co-authors since it is also coming from RFC 8776, and we had not discussed it in the context of RFC 8776-bis For the exceptions, these are due to mistakes in RFC 8776 so we have two options: 1. Deprecate or obsolete these definitions in YANG and re-defined them in other technology-specific YANG models 2. Keep these definitions in YANG and mark them as exceptions due to historical reasons We adopted the latter option not to cause impacts to existing implementations of RFC 8776 but the intention is to keep them as exceptions to the rule Italo From: Joel Halpern <[email protected]><mailto:[email protected]> Sent: giovedì 15 gennaio 2026 17:06 To: Italo Busi <[email protected]><mailto:[email protected]>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: draft-ietf-teas-rfc8776-update-20 ietf last call Genart review Just because they are there before does not justify claiming they are technology agnostic. And there seem to be a scattering of ones that are new and not agnostic, such as session-attribute-flags "Base identity for the RSVP-TE session attributes flags."; which is clearly specific to RSVP-TE. As are a number of entries which follow that. RSVP-TE is clearly a specific technology, even if it can be used for a few different sub-cases. Yours, Joel On 1/15/2026 10:58 AM, Italo Busi wrote: Hi Joel, Thanks a lot for your review and comment. I am not sure there are MPLS technology specific identities in section 3.1.1 since, as far as I am aware of, they are also used/applicable to other technologies (e.g., OTN). There are some technology-specific derived identities for switching-capabilities and lsp-encoding-types which are an exception and we have added some text to indicate this exception. The reason for the exception is that these identities have been already defined in RFC 8776 and we have decided to keep them here to maintain backward compatibility with RFC 8776. Is there any other metric that you think are MPLS technology-specific, besides these exceptions? Thanks, Italo -----Original Message----- From: Joel Halpern via Datatracker <[email protected]><mailto:[email protected]> Sent: martedì 23 dicembre 2025 21:32 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: draft-ietf-teas-rfc8776-update-20 ietf last call Genart review Document: draft-ietf-teas-rfc8776-update Title: Common YANG Data Types for Traffic Engineering Reviewer: Joel Halpern Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ><https://wiki.ietf.org/en/group/gen/GenArtFAQ>. (My apologies for the lateness of this review.) Document: draft-ietf-teas-rfc8776-update-20 Reviewer: Joel Halpern Review Date: 2025-12-23 IETF LC End Date: 2025-12-09 IESG Telechat date: 2026-01-08 Summary: This document is basically ready for publication as a proposed standards RFC. There is one wording issue that I believe should be addressed. Major issues: N/A Minor issues: I believe that this was mentioned in other reviews, and discussed, but I am still having trouble with it, Section 3.1 says "The "ietf-te-types" module (Section 4) contains common TE types that are independent and agnostic of any specific technology or control-plane instance." Except that section 3.1.1 then defines multiple MPLS specific identities. Which are clearly technology specific. If you have a narrower meaning of "specific technology" in mind, please use wording that conveys that meaning. Nits/editorial comments: N/A
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
