Hi Italo, all, Agree with Andy. SHOULD NOT in 8407bis does not need to be changed.
There are other exceptions when it is fine to not go through the intermediate state such as [1]. I see that draft-ietf-teas-rfc8776-update refers to those as bugfix, which is clear about the justification, IMO. Cheers, Med [1] https://mailarchive.ietf.org/arch/msg/rtgwg/mr1kAJ5Dpnen4CdYYnQG7llBH4U/ > -----Message d'origine----- > De : Andy Bierman <[email protected]> > Envoyé : jeudi 15 janvier 2026 19:38 > À : Italo Busi <[email protected]> > Cc : Mahesh Jethanandani <[email protected]>; > [email protected]; [email protected]; teas- > [email protected]; [email protected]; The IESG <[email protected]> > Objet : [Teas] Re: [netmod] Changing status from "current" to > "obsolete" (was RE: Mahesh Jethanandani's Discuss on draft-ietf- > teas-rfc8776-update-20: (with DISCUSS and COMMENT)) > > > On Thu, Jan 15, 2026 at 9:53 AM Italo Busi > <[email protected]> wrote: > > > > Hi Mahesh, > > > > I have changed the subject and involved the Netmod WG mailing > list to > > discuss your comment about changing the status from "current" to > > "obsolete" since I think this is a generic issue and may have an > > impact also on the Netmod WG draft > > > > You are right that section 4.7 of draft-ietf-netmod-rfc8407bis > says: > > > > The status SHOULD NOT be changed from "current" directly > to "obsolete" > > > > My original understanding of the requirements in section 4.7 of > draft-ietf-netmod-rfc8407bis was that the approach allowed for a > graceful migration from the deprecated definitions to the new > definitions and that the SHOULD NOT (instead of the MUST NOT) in > this context was that there might be cases where this change is > allowed or actually makes sense. > > > > However, there are no additional text to confirm or amend my > understanding. > > > The text says SHOULD NOT which allows for exceptions. > You have identified a vaid exception to the rule. > > Hopefully, the YANG module 'mistakes' get caught before RFC > publication, but if not, it is OK to change to obsolete directly, > especially considering the poor definition of 'deprecated' in > YANG. > > > > > > IMHO, in the context of draft-ietf-teas-rfc8776-update, we have > obsoleted definitions which were errors in RFC 8776. There is no > real need to migrate since using these definitions in RFC 8776 > would have been a mistake to be fixed. > > > > What do you or other experts in Netmod WG think? > > > > Do we need to change the SHOULD NOT in section 4.7 of draft- > ietf-netmod-rfc8407bis to be a MUST NOT and always deprecate > existing definitions even if they are clear bugs? > > > > Thanks, Italo > > > > Andy > > > > -----Original Message----- > > > From: Mahesh Jethanandani via Datatracker <[email protected]> > > > Sent: martedì 6 gennaio 2026 01:52 > > > To: The IESG <[email protected]> > > > Cc: [email protected]; [email protected]; > > > [email protected]; [email protected]; > > > [email protected] > > > Subject: Mahesh Jethanandani's Discuss on draft-ietf-teas- > rfc8776-update-20: > > > (with DISCUSS and COMMENT) > > > > > > Mahesh Jethanandani has entered the following ballot position > for > > > draft-ietf-teas-rfc8776-update-20: Discuss > > > > > > When responding, please keep the subject line intact and reply > to > > > all email addresses included in the To and CC lines. (Feel > free to > > > cut this introductory paragraph, however.) > > > > > > > > > Please refer to > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > ww > > > w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling- > &data=05% > > > > 7C02%7Cmohamed.boucadair%40orange.com%7Cb57886abe24742bef14608de54 > 65 > > > > 6429%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6390409916193917 > 90 > > > > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM > CI > > > > sIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sda > ta > > > =N%2F6yzQS9cVuNGXtPl3HdgBf8KNM4Zdu2z2Y%2FMuhsB3o%3D&reserved=0 > > > ballot-positions/ > > > for more information about how to handle DISCUSS and COMMENT > positions. > > > > > > > > > The document, along with other ballot positions, can be found > here: > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > da > > > tatracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-rfc8776- > update%2F&data=05 > > > > %7C02%7Cmohamed.boucadair%40orange.com%7Cb57886abe24742bef14608de5 > 46 > > > > 56429%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639040991619418 > 07 > > > > 8%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAw > MC > > > > IsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > at > > > a=utUuybs6GhC4FwwO4i6uKPML4HiVn1VXPC0%2FYvoCBQA%3D&reserved=0 > > > > > > > > > > > > -------------------------------------------------------------- > ------ > > > -- > > > DISCUSS: > > > -------------------------------------------------------------- > ------ > > > -- > > > > > > "Abstract", paragraph 0 > > > > This document defines a collection of common data types, > identities, > > > > and groupings in YANG data modeling language. These > derived common > > > > data types, identities and groupings are intended to be > imported by > > > > other modules, e.g., those which model the Traffic > Engineering (TE) > > > > configuration and state capabilities. > > > > > > I have to agree with Eric and Joel Halpern (BTW, thanks, Joel, > for > > > your GENART > > > review) about the fact that most of these definitions are, if > > > anything, technology-specific, and the draft needs to reflect > that. > > > It is not enough to say that the definitions in this draft > "can be > > > used by any module" and, by implication, with other > technologies, > > > unless those technologies are also covered comprehensively by > this > > > module. Certainly, the assertion that the module is technology > agnostic needs to be scrutinized. > > > > > > If the authors agree that the definitions are MPLS specific, I > would > > > not suggest renaming the module, as that is a much bigger > change and > > > will not play well with obsoleting RFC 8776. I would rather > just > > > update the description in the draft and in the YANG module to > > > reflect that fact, and hope one day the module will be truly > technology agnostic. > > > > > > Section 4, paragraph 21 > > > > This revision obsoletes the following identities: > > > > - of-minimize-agg-bandwidth-consumption; > > > > - of-minimize-load-most-loaded-link; > > > > - of-minimize-cost-path-set; > > > > - lsp-protection-reroute-extra; > > > > - lsp-protection-reroute. > > > > > > draft-ietf-netmod-rfc8407bis in Section 4.7 says that: > > > > > > The status SHOULD NOT be changed from "current" directly to > > > "obsolete". An object SHOULD be available for at least one > year > > > after the publication date with a "deprecated" status before > it is changed to "obsolete". > > > > > > Yet, this document has clearly done exactly that. Was it not > > > possible to deprecate the above identities, introduce the new > > > identities, and a year later, obsolete the identities that > were deprecated? > > > > > > Section 6, paragraph 5 > > > > This document requests IANA to register the following > YANG modules in > > > > the "YANG Module Names" registry [RFC6020][RFC9890] > within the "YANG > > > > Parameters" registry group. > > > > > > > > name: ietf-te-types > > > > Maintained by IANA? N > > > > namespace: urn:ietf:params:xml:ns:yang:ietf-te- > types > > > > prefix: te-types > > > > reference: RFC XXXX > > > > > > > > name: ietf-te-packet-types > > > > Maintained by IANA? N > > > > namespace: urn:ietf:params:xml:ns:yang:ietf-te- > packet-types > > > > prefix: te-packet-types > > > > reference: RFC XXXX > > > > > > Why is this registration request being made? Should the > request not > > > be for an update to refer to this document? > > > > > > Section 7, paragraph 5 > > > > The YANG modules define a set of identities, types, and > groupings. > > > > These nodes are intended to be reused by other YANG > modules. The > > > > modules by themselves do not expose any data nodes that > are writable, > > > > data nodes that contain read-only state, or RPCs. As > such, there are > > > > no additional security issues related to the YANG module > that need to > > > > be considered. > > > > > > > > Modules that use the groupings that are defined in this > document > > > > should identify the corresponding security > considerations. For > > > > example using 'explicit-route-hop', 'record-route-state' > or 'te- > > > > topology-identifier' (which includes the 'client-id') > groupings may > > > > expose sensitive topology information. > > > > > > If there are no security issues that need to be discussed > here, why > > > is the rest of the text needed? Just these paragraphs should > suffice, no? > > > > > > > > > -------------------------------------------------------------- > ------ > > > -- > > > COMMENT: > > > -------------------------------------------------------------- > ------ > > > -- > > > > > > Section 1.2, paragraph 1 > > > > > > > > +=================+======================+======================== > > > + > > > > | Prefix | YANG module | Reference > | > > > > > > > > +=================+======================+======================== > > > + > > > > | yang | ietf-yang-types | Section 3 of > [RFC6991] | > > > > +-----------------+----------------------+-------------- > ----------+ > > > > | inet | ietf-inet-types | Section 4 of > [RFC6991] | > > > > +-----------------+----------------------+-------------- > ----------+ > > > > | rt-types | ietf-routing-types | [RFC8294] > | > > > > +-----------------+----------------------+-------------- > ----------+ > > > > | te-types | ietf-te-types | RFCXXXX > | > > > > +-----------------+----------------------+-------------- > ----------+ > > > > | te-packet-types | ietf-te-packet-types | RFCXXXX > | > > > > > > > > +-----------------+----------------------+------------------ > ------ > > > > + > > > > > > Please update all references to RFC6991 to point to RFC 9911. > > > > > > Section 4, paragraph 14 > > > > All revisions of IETF and IANA published modules can > be found > > > > at the YANG Parameters registry group > > > > > (https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fwww.iana.org%2Fassignments%2Fyang- > parameters&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cb57886a > be24742bef14608de54656429%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 > C0%7C639040991619437665%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=VhECzqk5B%2FuTln%2F7BMvJMvw4V%2F%2BVGj > 9WWNAVKmbImWo%3D&reserved=0). > > > > > > Is this draft publishing an IANA module? If not, please remove > > > reference to IANA modules. > > > > > > Section 4, paragraph 34 > > > > identity lsp-provisioning-error-reason { > > > > description > > > > "Base identity for LSP provisioning errors."; > > > > } > > > > > > I do not see this base identity being used in this module or > in this document. > > > If this is intended to be used somewhere else or at a later > time, it > > > would be better to define it there or at that time. > > > > > > Section 4, paragraph 358 > > > > leaf one-way-delay { > > > > type uint32 { > > > > range "0..16777215"; > > > > } > > > > units "microseconds"; > > > > description > > > > "One-way delay or latency."; > > > > } > > > > > > Is there a reference that can be cited for this? Or even an > > > explanation for how it can be measured. Per MEF 10.3, "One-way > delay > > > is difficult to measure and therefore one-way delay may be > approximated from two-way measurements." > > > > > > Section 4, paragraph 357 > > > > leaf one-way-delay-normality { > > > > type te-types:performance-metrics-normality; > > > > description > > > > "One-way delay normality."; > > > > } > > > > > > This description and several like these are essentially a > repeat of > > > the name of the node without an explanation for what it is. > Either > > > an explanation or a reference is the minimum one should expect > from these modules. > > > > > > Section 4, paragraph 358 > > > > leaf two-way-delay { > > > > type uint32 { > > > > range "0..16777215"; > > > > } > > > > units "microseconds"; > > > > description > > > > "Two-way delay or latency."; > > > > } > > > > > > Same question here for reference. > > > > > > Section 5, paragraph 0 > > > > The "ietf-te-packet-types" module imports from the "ietf- > te-types" > > > > module defined in Section 4 of this document. > > > > > > How about RFC 6991 or more precisely RFC 9911? > > > > > > Section 5, paragraph 1 > > > > // RFC Editor: Please replace XXXX above with the RFC > number > > > > // assigned to this document. > > > > // Please remove this note. > > > > > > Can all these RFC Editor directives be consolidated in one > place > > > instead of scattering them across the document? > > > > > > Section 5, paragraph 54 > > > > grouping bandwidth-profile-parameters { > > > > description > > > > "Common parameters to define bandwidth profiles in > packet > > > > networks."; > > > > leaf cir { > > > > type uint64; > > > > units "bits per second"; > > > > description > > > > "Committed Information Rate (CIR)."; > > > > } > > > > leaf cbs { > > > > type uint64; > > > > units "bytes"; > > > > description > > > > "Committed Burst Size (CBS)."; > > > > } > > > > leaf eir { > > > > type uint64; > > > > units "bits per second"; > > > > description > > > > "Excess Information Rate (EIR)."; > > > > } > > > > leaf ebs { > > > > type uint64; > > > > units "bytes"; > > > > description > > > > "Excess Burst Size (EBS)."; > > > > } > > > > leaf pir { > > > > type uint64; > > > > units "bits per second"; > > > > description > > > > "Peak Information Rate (PIR)."; > > > > } > > > > leaf pbs { > > > > type uint64; > > > > units "bytes"; > > > > description > > > > "Peak Burst Size (PBS)."; > > > > } > > > > } > > > > > > Please cite the reference of MEF 10.3 for these parameters as > > > suggested by Sergio Belotti. BTW, thanks, Sergio, for your > OPSDIR review. > > > > > > Found terminology that should be reviewed for inclusivity; see > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > ww > > > w.rfc- > editor.org%2Fpart2%2F%23inclusive_language&data=05%7C02%7Cmoha > > > > med.boucadair%40orange.com%7Cb57886abe24742bef14608de54656429%7C90 > c7 > > > > a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C639040991619452574%7CUnknow > n% > > > > 7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJX > aW > > > > 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0%2Fhoe% > 2F > > > bwMEyF%2FhqcXBIuqQZFJqI%2FJzYu7kYAfZVdVLM%3D&reserved=0 for > > > background and more > > > guidance: > > > > > > * Term "he"; alternatives might be "they", "them", "their" > > > > > > -------------------------------------------------------------- > ------ > > > ----------- > > > NIT > > > -------------------------------------------------------------- > ------ > > > ----------- > > > > > > All comments below are about very minor potential issues that > you > > > may choose to address in some way - or ignore - as you see > fit. Some > > > were flagged by automated tools (via > > > > https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F > gi > > > thub.com%2Flarseggert%2Fietf- > reviewtool&data=05%7C02%7Cmohamed.bouca > > > > dair%40orange.com%7Cb57886abe24742bef14608de54656429%7C90c7a20af34 > b40bfbc48b9253b6f5d20%7C0%7C0%7C639040991619463980%7CUnknown%7CTWF > pbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zM > iIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ocaP92hEhsC > n1PqpE6nCAQC5HqVTVg5DJNc2xch18gM%3D&reserved=0), so there will > likely be some false positives. There is no need to let me know > what you did with these suggestions. > > > > > > Reference [RFC6991] to RFC6991, which was obsoleted by RFC9911 > (this > > > may be on purpose). > > > > > > "I", paragraph 53 > > > > with the alternate route being pre-computed and stored for > use when the fai > > > > ^^^^^^^^^^^^ > > > Do not mix variants of the same word ("pre-compute" and > > > "precompute") within a single text. > > > > > > "I", paragraph 196 > > > > es a type representing the access type of a TE link."; > reference "RFC 3630: T > > > > ^^^^^^^^^ > > > If "type" is a classification term, "a" is not necessary. Use > "type > > > of". (The phrases "kind of" and "sort of" are informal if they > mean "to some extent".). > > > > > > "I", paragraph 210 > > > > ition, and the user traffic is being transported (or > selected) on the recove > > > > ^^^^^^^^^^^^^^^^^^^^ > > > You have used the passive voice repeatedly in nearby > sentences. To > > > make your writing clearer and easier to read, consider using > active voice. > > > > > > "I", paragraph 333 > > > > address or dotted quad address or as an URI. The type data > node > > > disambiguate > > > > ^^ > > > Use "a" instead of "an" if the following word doesn't start > with a > > > vowel sound, e.g. "a sentence", "a university". > > > > > > "I", paragraph 397 > > > > c-editor.org/rfc/rfc9522>. Appendix A. The Complete Schema > Trees > > > > This > > > appendi > > > > ^^ > > > It seems like there are too many consecutive spaces here. > > > > > > Section 8, paragraph 10 > > > > ready defined in [RFC8776], have been updated in the > 'explicit-route-hop': - > > > > ^^^^^^^^^^^^ > > > You have used the passive voice repeatedly in nearby > sentences. To > > > make your writing clearer and easier to read, consider using > active voice. > > > > > > Section 8, paragraph 11 > > > > n replaced by must statements that requires at least the > presence of: o node > > > > ^^^^^^^^ > > > Possible subject-verb agreement error detected. > > > > > > Section 8, paragraph 12 > > > > n replaced by must statements that requires at least the > presence of: o node > > > > ^^^^^^^^ > > > Possible subject-verb agreement error detected. > > > > > > Section 8, paragraph 14 > > > > constraints; The following new leaf have been added to the > 'tunnel-constraint > > > > ^^^^ > > > The verb form "have" does not seem to match the subject > "leaf". > > > > > > Section 8, paragraph 15 > > > > jects-always; The container has been renamed as 'explicit- > route-objects'. Thi > > > > ^^^^^^^^^^^^ > > > You have used the passive voice repeatedly in nearby > sentences. To > > > make your writing clearer and easier to read, consider using > active voice. > > > > > > > > > > _______________________________________________ > > netmod mailing list -- [email protected] To unsubscribe send an > email to > > [email protected] > > _______________________________________________ > Teas mailing list -- [email protected] > To unsubscribe send an email to [email protected] ____________________________________________________________________________________________________________ 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. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
