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]> > 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>. > > (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]
