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]>
*Sent:* giovedì 15 gennaio 2026 17:06
*To:* Italo Busi <[email protected]>; [email protected]
*Cc:* [email protected]; [email protected];
[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]
Cc:[email protected];[email protected];[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]
