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.
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
> -----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://www.ietf.org/about/groups/iesg/statements/handling-
> 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://datatracker.ietf.org/doc/draft-ietf-teas-rfc8776-update/
>
>
>
> ----------------------------------------------------------------------
> 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://www.iana.org/assignments/yang-parameters).
>
> 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://www.rfc-editor.org/part2/#inclusive_language 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://github.com/larseggert/ietf-reviewtool), 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]
