A YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm
draft-ietf-lsr-isis-flex-algo-yang-21

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Also thanks to the authors for the discussion on my original ballot and the updates to address the concerns raised.

[Ballot comment]
Hi Yingzhen, Acee, and Madhavi,

The changes made are great [1]. Thank you for taking caring of all the comments in my previous ballot [2]. Much appreciated.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-lsr-isis-flex-algo-yang-08&url2=draft-ietf-lsr-isis-flex-algo-yang-19&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/lsr/ydQQNGc5m4cFrDpH7CYOWP3tEKU/

[Ballot comment]
I see no transport protocol issues, thanks for doing this work.

It was hard to read this without a short introduction to the various parts - See other IESG feedback.

[Ballot comment]
1. Section 2, ietf-isis-link-attr, fa-in-all-ag-sub-tlv grouping:

979 >        description
980 >          "The flex-algo include-all admin group sub-tlv. Note that
981 >            the presence of more than one Include-Any Extended Admin
982 >            Group sub-TLV will result in an invalid FAD TLV.";

The description for the fa-in-all-ag-sub-tlv container says
"Include-Any" where it should say "Include-All".  This appears to be a
copy-paste from the fa-in-any-ag-sub-tlv grouping.  In my opinion, this
should be corrected because an implementor reading this description will
be misled about which constraint applies.


2. Section 4, Security Considerations — missing writable container:

1302 >    There are a number of data nodes defined in this YANG module that are
1303 >    writable/creatable/deletable (i.e., "config true", which is the
1304 >    default).  All writable data nodes are likely to be reasonably
1305 >    sensitive or vulnerable in some network environments.
...
1311 >      /isis:isis/isis-link-attr/link-attr-op-mode - Modification to the
1312 >      protocol operation mode may result in traffic disruption.
1313 >
1314 >      /isis:isis/isis-flex-algo/flex-algo - Modification to flex-algo
1315 >      configuration could be used to mount a DoS attack.

The Security Considerations list two sensitive writable subtrees but
omit the interface-level ASLA configuration:

639 >      container isis-asla {
640 >        list interface-asla {
641 >          key "link-attr-app";

The `isis-asla/interface-asla` list is writable (config true) and
controls per-application TE metric, admin-group, and SRLG values on
each IS-IS interface.  Unauthorized modification of these attributes
can redirect traffic flows for specific applications or create routing
inconsistencies in multi-area topologies.  RFC 9907 requires that
particularly sensitive writable nodes be explicitly listed by name.
In my view, this subtree should be added to the writable nodes list in
the Security Considerations.

3. Section 3, ietf-isis-flex-algo, admin-groups — leaf-list of full
  bitmasks vs. single bitmask in the LSDB:

1127 >            leaf-list exclude-admin-groups {
1128 >              type te-types:extended-admin-group;
1129 >              description
1130 >                "Exclude rule used during the flex-algo
1131 >                  path computation.";

The LSDB operational state models each admin group sub-TLV as a single
leaf:

773 >            +--ro extended-admin-group?
774 >                    te-types:extended-admin-group

RFC 9350 Section 6.1 states: "The IS-IS FAEAG sub-TLV MUST NOT appear
more than once in a single IS-IS FAD sub-TLV."  The same constraint
applies to the Include-Any sub-TLV (Section 6.2) and the Include-All
sub-TLV (Section 6.3).  Each sub-TLV carries a single Extended Admin
Group value (a variable-length bitmask per RFC 7308).  The LSDB model
is therefore correct in using a single optional leaf for each.

The config model uses `leaf-list exclude-admin-groups` (and similarly
for include-any and include-all), where `te-types:extended-admin-group`
is a variable-length hex-string representing the full bitmask.  It is
not defined how multiple leaf-list entries are combined into a single
sub-TLV that can appear on the wire.  In my opinion, the config model
should either use a single leaf (consistent with the LSDB
representation and the protocol constraint) or include a clear
description of how multiple leaf-list entries are merged when building
the wire-format sub-TLV.


4. Section 2, ietf-isis-link-attr, link-local-id / link-remote-id
  union type:

504 >              leaf link-local-id {
505 >                type union {
506 >                  type inet:ipv4-address;
507 >                  type uint32;
508 >                }
509 >                description
510 >                  "Local identifier of the link.
511 >                    It could be an IPv4 address or a local identifier.";

513 >              leaf link-remote-id {
514 >                type union {
515 >                  type inet:ipv4-address;
516 >                  type uint32;
517 >                }

These leaves model the Link Local/Remote Identifiers sub-TLV.
RFC 5307 Section 1.1 defines this sub-TLV as carrying a pair of 32-bit
integer link identifiers — not IPv4 addresses.  IPv4 interface and
neighbor addresses are separate sub-TLVs, already modeled in the
ipv4-interface-addr and ipv4-neighbor-addr containers present in the
same link-id-sub-tlvs container.

Including `inet:ipv4-address` in the union conflates the Link
Local/Remote Identifiers sub-TLV with those separate IPv4 address
sub-TLVs.  The type of link-local-id and link-remote-id should be
`uint32`, matching the protocol definition.  If there are
implementations that reuse an IPv4 address as the link identifier
value, that practice should be explicitly documented rather than
absorbed silently into the type union.


5. Section 2, ietf-isis-link-attr, interface-asla config
  completeness:

639 >      container isis-asla {
640 >        list interface-asla {
641 >          key "link-attr-app";
651 >          leaf te-metric { ... }
658 >          leaf admin-group { ... }
665 >          container srlgs { ... }

The `interface-asla` list allows configuring te-metric, admin-group,
and SRLG per application.  RFC 9479 defines the ASLA sub-TLV as a
general mechanism for advertising any link attribute (including TE
bandwidth metrics, delay, and loss) on a per-application basis.  The
LSDB operational state for the asla-sub-tlv (lines 130-178) exposes
max-bandwidth, max-reservable-bandwidth, unreserved-bandwidths, and
various performance metrics (unidirectional-link-delay,
delay-variation, loss, etc.) — but none of these are configurable
through the interface-asla list.

If per-application bandwidth and performance metric values are
intentionally auto-derived from the link layer (rather than
configured), in my view, the document should explicitly say so.
Without this explanation, it is unclear whether the absence of
bandwidth and delay configuration is a deliberate design decision or
an incomplete model.


6. Section 4, Security Considerations — RFC 9907 template, RPC/action
  clause:

This is more of an NIT.

The Security Considerations section addresses writable and readable data nodes
but does not include an explicit statement about RPC or action
operations.  RFC 9907 Section 3.7 requires that "Operations (i.e.,
YANG 'rpc' statements) that are potentially harmful to system behavior
or that raise significant privacy concerns MUST be explicitly listed by
name."  Neither module defines any RPCs or actions.  I would suggest
adding a sentence stating that no RPC or action operations are defined
in these modules.


7. Section 2, ietf-isis-link-attr — missing RFC 8294 in normative
  references:

286 >      import ietf-routing-types {
287 >        prefix rt-types;
288 >        reference
289 >          "RFC 8294: Common YANG Data Types for the
290 >          Routing Area";

The ietf-isis-link-attr module imports ietf-routing-types (RFC 8294)
and uses rt-types:bandwidth-ieee-float32 in multiple leaves.  RFC 8294
does not appear in the normative references in Section 7.1. Please add.

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

Section 2, ietf-isis-link-attr, unreserved-bandwidth list, priority
leaf description:

395 >              description
396 >                "Priority from 0 to 7. There should on be a single
397 >                unreserved-bandwidth per priority.";

s/There should on be a single/There should only be a single/

Section 3, ietf-isis-flex-algo, import of ietf-te-types, reference
string:

Section 3, ietf-isis-flex-algo, contact field:

875 >        Author:    Acee Lindem
876 >                 
877 >        Author:    Madhavi Joshi
878 >                 

The mailto: URI scheme prefix is present for Qu and Lindem in this
module but absent for Joshi.  The same inconsistency appears in the
ietf-isis-link-attr module contact field.  For consistency, please
add the mailto: prefix uniformly across all authors in both
modules.

[Ballot comment]
This is a YANG data model with an introduction; there's no description of what these fields are, etc. I support Med's DISCUSS.

# Nits

In 11 places: "This augment IS-IS" should probably be "This augments IS-IS"

[Ballot discuss]
Thanks to the authors and the WG for their work on their document.

I have two meta topics which I would like to discuss.

1) The link-attr-op-mode knob is not clear since it is neither offering detailed description nor referencing the RFC 9479 subsections.

      choice link-attr-op-mode {
        default "legacy"; >>> Why is this the default? Is that coming from RFC9479?
        leaf legacy {
          type empty;
          description
            "Only send legacy advertisements."; >>> What does this mean? Not send via ASLA but only legacy advertisements (sec 3) or send via ASLA with the L-bit (sec 4.2)?
        }
        leaf transition {
          type empty;
          description
            "Send both application-specific and legacy
            advertisements."; >>> What does this mean? Is there a reference from the base RFC on how this is supposed to work?
        }
        leaf app-specific {
          type empty;
          description
            "Only send application-specific advertisements."; >>> If there is a compulsion to pick a default (I think there shouldn't be one?), then I would pick this one.
        }
        description
          "Link attributes mode. Default to legacy mode for
          backward compatibility.";
      }

Based on my understanding of RFC9479, we can only think of an enablement knob for ASLA advertisements at global level. The L-bit is perhaps something to control under the interface config under isis-asla. It could also be global if there is a desire to support hierarchical config for just the app selection (SABM/UDABM) and the L-bit setting.

2) When new sub-sub-TLVs are introduced under ASLA sub-TLV or under FAD sub-TLV, how does the current structure make augmentation of the module easy and straightforward? I am not a YANG expert and hence I would like to cross-check.

[Ballot discuss]
Hi Yingzhen, Acee, and Madhavi,

Thank you for the effort put into this specification.

Please find some comments and suggestions. These are easy-to-fix. Let me know if any clarification is needed.

# Lack or narrative text

RFC9907 says:
  The narrative sections MUST include an overview section that
  describes the scope and field of application of the data model(s)
  defined by the specification and that specifies the relationship (if
  any) of these data models to other standards, particularly to
  standards containing other YANG data models.  The narrative part
  SHOULD include one or more sections to briefly describe the structure
  of the data models defined in the specification.

At least an overview is needed (MUST part above).

I remember that we had the same comment for RFC9903. Having something similar to the text you added in “Design of the YANG Module for OSPF MPLS Segment Routing” of RFC9903 would be great. Thanks.

# te-metric

CURRENT:
      leaf te-metric {
        type uint32;
        description
          "TE default metric.";
        reference
          "RFC 5305: IS-IS Extensions for Traffic Engineering,
            Section 3.7";

Why not using this type from draft-ietf-teas-rfc8776-update

    typedef te-metric {
      type uint32;
      description
        "Traffic Engineering (TE)  metric.";
      reference
        "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                    Version 2, Section 2.5.5
          RFC 5305: IS-IS Extensions for Traffic Engineering,
                    Section 3.7";
    }

# admin-group

CURRENT:
      leaf admin-group {
        type uint32;
        description
          "Administrative Group / Resource Class/Color.";
        reference
          "RFC 5305: IS-IS Extensions for Traffic Engineering,
            Section 3.1";
      }

This definition deviates from the one in draft-ietf-teas-rfc8776-update:

    typedef admin-group {
      type yang:hex-string {
        /* 01:02:03:04 */
        length "1..11";
      }
      description
        "Administrative group / resource class / color representation
          in 'hex-string' type.

          The most significant byte in the hex-string is the farthest
          to the left in the byte sequence.

          Leading zero bytes in the configured value may be omitted
          for brevity.";
      reference
        "RFC 3630: Traffic Engineering (TE) Extensions to OSPF
                    Version 2
          RFC 5305: IS-IS Extensions for Traffic Engineering
          RFC 7308: Extended Administrative Groups in MPLS Traffic
                    Engineering (MPLS-TE)";
    }

Unless there is a valid reason, I recommend to reuse the type defined in 8776.

# Priority Unicity

CURRENT:
        list unreserved-bandwidth {
          leaf priority {
            type uint8 {
              range "0 .. 7";
            }
            description
              "Priority from 0 to 7.";
          }
          leaf unreserved-bandwidth {
            type rt-types:bandwidth-ieee-float32;
            description
              "Unreserved bandwidth.";
          }
          description
            "List of unreserved bandwidths for different
              priorities.";
        }

Do we allow to repeat the same priority? How to ensure unicity? At least for ro, this should be flagged as an anomaly. A discussion in an OPS Considerations Section would be helpful here.

## Idem for

CURRENT:
        list fad-tlv {
          leaf algo-number {
            type uint8;
            description
              "Flex-algo number - A value not in the inclusive range
                of 128-255 is an invalid FAD TLV specification.";
          }
          leaf metric-type {
            type identityref {
              base iana-metric-type:metric-type;
            }
            description
              "Type of metric to be used during the calculation.";
          }
          leaf calc-type {
            type identityref {
              base iana-algo-types:algo-type;
            }
            description
              "IGP algorithm types, value from 0 to 127 as
                defined under 'Interior Gateway Protocol (IGP)
                Parameter' by IANA.";
          }
          leaf priority {
            type uint8;
            description
              "Priority of the advertisement.";
          }


# Deviate from RFC 9479

CURRENT:
      leaf l-flag {
        type boolean;
        description
          "Legacy Flag. When set, all of the applications
            specified in the bit mask MUST use the legacy
            advertisements.";
      }

RFC9479:
  When the SABM Length or UDABM Length is non-zero and the L-flag is
  NOT set, all applications specified in the bit mask MUST use the link
  attribute advertisements in the sub-TLV.

## The description does not mirror exactly the behavior in RFC 9479.

## An easy fix is to remove the normative language and update the description to focus on the leaf itself (management) not the on-wire spec.

# Length fields: Intended use

CURRENT:

      leaf sabm-length {
        type uint8;
        description
          "Standard Application Identifier Bit Mask Length in
            octets.";
      }
      leaf udabm-length {
        type uint8;
        description
          "User Defined Application Identifier Bit Mask Length
            in octets.";
      }

    …

          leaf length-of-sub-tlvs {
            type uint8;
            description
              "Length of sub-tlvs.";
          }


## I understand this is needed for the protocol, but why do we need these for managing an implem?

## If these are maintained (which I don’t see why), then you need to update the module to have a constraint for sabm per:

RFC 9479:
    This field is omitted if SABM Length is 0.

# Provision for future augmentations, but without guidance

CURRENT:
      container udabm {
        description
          "User Defined Application Identifier Bit Mask.
            This container is to be augmented by user defined
            applications.";
      }

The intended use/guidance should be defined in the main document. Please add some text to set the expectations for authors for future augmentations.

# Abnormal configuration

CURRENT:
            |  +--ro ipv4-interface-addr
            |  |  +--ro ipv4-int-addr?  inet:ipv4-address
            |  +--ro ipv4-neighbor-addr
            |  |  +--ro ipv4-neighbor-addr?  inet:ipv4-address
            |  +--ro ipv6-interface-addr
            |  |  +--ro ipv6-int-addr?  inet:ipv6-address
            |  +--ro ipv6-neighbor-addr
            |    +--ro ipv6-neighbor-addr?  inet:ipv6-address

The module/document does not include any discussion about checks to detect abnormal behaviors with regards to address family mismatch. Can we please gave some text?

# srlg

CURRENT:
            leaf-list srlg {
              type uint32;
              description
                "SRLG value of the link.";
            }

Why no reusing this type from draft-ietf-teas-rfc8776-update?

    typedef srlg {
      type uint32;
      description
        "Shared Risk Link Group (SRLG) type.";
      reference
        "RFC 4203: OSPF Extensions in Support of Generalized
                    Multi-Protocol Label Switching (GMPLS)
          RFC 5307: IS-IS Extensions in Support of Generalized
                    Multi-Protocol Label Switching (GMPLS)";
    }

# Update to draft-ietf-teas-rfc8776-update

CURRENT:
    import ietf-te-types {
      prefix te-types;
      reference
        "RFC8776: Common YANG Data Types for Traffic Engineering.";
    }

# missing normative import

CURRENT:
    import ietf-te {
      prefix te;
      reference
        "RFC XXXX: A YANG Data Model for Traffic Engineering
                    Tunnels, Label Switched Paths, and Interfaces";
    }

RFC9907:

  For every "import" or "include" statement that appears in a module
  contained in the specification that identifies a module in a separate
  document, a corresponding normative reference to that document MUST
  appear in the Normative References section.

# Consistency with RFC 9350

CURRENT:
    identity m-bit {
      base fad-flags;
      description
        "M bit, when set, the flex-algo specific prefix and ASBR
          metric MUST be used for inter-area and external prefix
          calculation.";
    }

## RFC 9350 has M-flag. If we refer to the same object, then please update to be consistent with 9350.

## This is an identity, not a Boolean. I don’t understand what is meant by set here.

## (almost) Duplicate RFC 9350 behavior, but more importantly lack of management object description

        M-flag:  when set, the Flex-Algorithm-specific prefix metric
            MUST be used for inter-area and external prefix calculation.
            This flag is not applicable to prefixes advertised as SRv6
            locators.

Note also the exception part in the RFC 9350.

Please update the description to focus on the intended use of the management object.

# extended-admin-group

CURRENT:
        leaf-list extended-admin-groups {
          type uint64;
          description
            "Extended administrative group as defined in RFC 7308.";
        }

Any reason why we can’t use extended-admin-group from draft-ietf-teas-rfc8776-update?

As I’m there, please s/ extended-admin-groups/ extended-admin-group

# Valid Examples

RFC9907 says:
  Examples that are meant to illustrate a valid
  data instance MUST be validated (Section 3.10).

The JSON Example in Appendix B is not valid (at least modules prefixes are needed). Please run yangson or yanglint for all the examples.

[Ballot comment]
# Title

OLD:
  YANG Data Model for IS-IS Application-Specific Link Attributes and
                          Flexible Algorithm

NEW:
  A YANG Data Model for IS-IS Application-Specific Link Attributes and
                          Flexible Algorithm

Please update the modules accordingly.

# Module, model, etc.

Per https://datatracker.ietf.org/doc/html/rfc9907#section-2.5,

  Note that the term "YANG model" is sometimes used as an abbreviation
  of "YANG data model".  However, that term should be avoided in favor
  of "YANG data model".  Likewise, "YANG data module" has no meaning
  and must be avoided.

OLD: This document defines two YANG [RFC7950] data modules.
NEW: This document defines a YANG [RFC7950] data model, which is composed to two YANG modules.

OLD: Algorithm in JSON format using the YANG model
NEW: Algorithm in JSON format using the YANG module

# Tree diagrams

RFC9907:
  If YANG tree diagrams are used, then an informative reference to the
  YANG tree diagrams specification MUST be included in the document.

Please update 1.1 with the following:

NEW:
  The meanings of the symbols in the YANG tree diagrams are defined in
  [RFC8340].

# RFC9911

CURRENT:
    import ietf-inet-types {
      prefix inet;
      reference
        "RFC 6991: Common YANG Data Types";
    }

Please update to 9911.

# IANA-Maintained Modules

CURRENT:
    import iana-igp-link-attr-apps {
      prefix iana-link-attr-apps;
      reference
        "RFC XXXX: YANG Data Model for OSPF Application-Specific
                    Link Attributes and Flexible Algorithm";
    }

…

    import iana-igp-algo-types {
      prefix iana-algo-types;
      reference
        "RFC XXXX: YANG Data Model for OSPF Application-Specific
                    Link Attributes and Flexible Algorithm";
    }
    import iana-igp-metric-types {
      prefix iana-metric-type;
      reference
        "RFC XXXX: YANG Data Model for OSPF Application-Specific
                    Link Attributes and Flexible Algorithm";
    }


The import applies, not only for the initial version. Please consider updating the reference to follow this part from 9907:

RFC9907:
  If an IANA-maintained YANG module is imported by another module, a
  normative reference with the IANA URL from which to retrieve the
  IANA-maintained YANG module SHOULD be included.  Although not
  encouraged, referencing the RFC that defines the initial version of
  the IANA module is acceptable in specific cases (e.g., the imported
  version is specifically the initial version, the RFC includes useful
  description about the usage of the module).

# RFC XXXX is ambiguous as it refers to distinct docs

CURRENT:
      reference
        "RFC XXXX: YANG Data Model for OSPF Application-Specific
                    Link Attributes and Flexible Algorithm";

        "RFC XXXX: A YANG Data Model for Traffic Engineering
                    Tunnels, Label Switched Paths, and Interfaces";

# Only NMDA exceptions are needed to be called out

CURRENT:
        This YANG model conforms to the Network Management
        Datastore Architecture (NMDA) as described in RFC 8342.

Consider delete that statement.

# Follow IETF Template

OLD:

        This version of this YANG module is part of RFC XXXX;
        see the RFC itself for full legal notices.

NEW:

        All revisions of IETF and IANA published modules can be found
        at the YANG Parameters registry group
        (https://www.iana.org/assignments/yang-parameters).

        This version of this YANG module is part of RFC XXXX; see
        the RFC itself for full legal notices.

# Consider adding a reference statement to rfc9479 for application-identifier-bit-mask grouping

# l-flag: can be set to true or false

OLD:
      leaf l-flag {
        type boolean;
        description
          "Legacy Flag. When set, …
      }

NEW:
      leaf l-flag {
        type boolean;
        description
          "Legacy Flag. When set to true, …
      }

# Missing units statements

CURRENT:
      leaf sabm-length {
        type uint8;
        description
          "Standard Application Identifier Bit Mask Length in
            octets.";
      }
      leaf udabm-length {
        type uint8;
        description
          "User Defined Application Identifier Bit Mask Length
            in octets.";
      }

Consider adding a units statement rather than having this in the description.

# Lists and leaf-lists

CURRENT:
        leaf-list sabm-bits {
          type identityref {
            base iana-link-attr-apps:igp-link-attr-app;
          }
          description
            "SABM bits list. This list will contain
              identities for the bits which are set in the
              SABM bits.";
        }

RFC 9907 says:

  List identifiers SHOULD be singular with the surrounding container
  name plural.  Similarly, "leaf-list" identifiers SHOULD be singular.

NEW:
        leaf-list sabm-bit {
          type identityref {
            base iana-link-attr-apps:igp-link-attr-app;
          }
          description
            "SABM bits list. This list will contain
              identities for the bits which are set to 1 in the
              SABM bits.";
        }

## (also fixed s/set/set to 1)

## There are several such constructs that need to be fixed. I’m not listing all these, but please check.

# Not only configuration, but also for retrieval

CURRENT:
    /* Configuration */

Please update to “Management” or something similar.

## Idem

OLD: This augments IS-IS protocol configuration
NEW: This augments IS-IS protocol management

## Idem

OLD: This augments IS-IS interface configuration
NEW: This augments IS-IS interface management

# m-bit

CURRENT:
    identity m-bit {
      base fad-flags;
      description
        "M bit, when set, the flex-algo specific prefix and ASBR
          metric MUST be used for inter-area and external prefix
          calculation.";
    }

Same comments as l-flag

# Embedded references in the description

CURRENT:
          description
            "Extended administrative group as defined in RFC 7308.";
        }

Please use a reference statement for this (and similar)

# Applies when enabled to true

OLD:
          leaf advertise-definition {
            type boolean;
            default "true";
            description
              "Enable to advertise the flex-algo definition.";
          }

NEW/
          leaf advertise-definition {
            type boolean;
            default "true";
            description
              "When set to true, enables to advertise the flex-algo definition.";
          }

# Specification?

CURRENT:
          "Flex-algo identifier which is not supported by the IS-IS
            instance. A value not in the inclusive range of 128-255
            is indicative of an invalid FAD algorithm specification.";

Which specification?

# Update Security considerations to cover the notifications

# Two modules

OLD: This document registers a URI in the IETF XML registry
NEW: This document registers two URIs in the IETF XML registry

OLD: This document registers the YANG module
NEW: This document registers the YANG modules

# This dependency can be avoided as the normative source of the IANA-maintained module is the IANA registry itself.

CURRENT:
7.1.  Normative References

  [I-D.ietf-lsr-ospf-flex-algo-yang]
              Qu, Y. and A. Lindem, "YANG Data Model for OSPF
              Application-Specific Link Attributes and Flexible
              Algorithm", Work in Progress, Internet-Draft, draft-ietf-
              lsr-ospf-flex-algo-yang-07, 30 March 2026,
              .

# Not Normative: Please move the following to Informative

CURRENT:
7.1.  Normative References


  [RFC4252]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
              Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
              January 2006, .

  [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
              and A. Bierman, Ed., "Network Configuration Protocol
              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
              .

  [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
              .

  [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              .

  [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              .

Hope this helps.

Cheers,
Med

[Ballot comment]

Section 4:  Consider leaving a note to the RFC Editor to update RFC 8446 to RFC 9846, if it is published before this draft (it is currently in Auth 48).

[Ballot comment]
Thanks for the work done in this document. Some comments

### Section 3

Just doing my IESG evaluation of draft-ietf-lsr-ospf-flex-algo-yang and reading that this common YANG module is indeed shared and does not "belong" to OSPF, so, all is good and my previous comment below can be ignoed.

> About this IS-IS YANG module re-using a type specified in draft-ietf-lsr-ospf-flex-algo-yang. If common to IS-IS and OSPF, then why not having a common module ? (of course, it this is the *only* common thing, then my comment can be ignored)

Should the unit be specified in all the bandwidth-related leaf nodes ?

Unusual presentation with the YANG tree directly followed by the YANG module, why not ? ;-)

[Ballot comment]
Thanks for the work done in this document. Some comments

### Section 3

About this IS-IS YANG module re-using a type specified in ietf-lsr-ospf-flex-algo-yang. If common to IS-IS and OSPF, then why not having a common module ? (of course, it this is the *only* common thing, then my comment can be ignored)

Should the unit be specified in all the bandwidth-related leaf nodes ?

Unusual presentation with the YANG tree directly followed by the YANG module, why not ? ;-)

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-isis-flex-algo-yang-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

two new namespaces will be registered as follows:

ID: yang:ietf-isis-link-attr
URI: urn:ietf:params:xml:ns:ietf-isis-link-attr
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:ietf-isis-flex-algo
URI: urn:ietf:params:xml:ns:ietf-isis-flex-algo
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

two new YANG modules will be registered as follows:

Name: ietf-isis-link-attr
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-isis-link-attr
Prefix: isis-link-attribute
Module:
Reference: [ RFC-to-be ]

Name: ietf-isis-flex-algo
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-isis-flex-algo
Prefix: isis-flex-algo
Module:
Reference: [ RFC-to-be ]

While the YANG module names will be registered after the IESG approves the document, the YANG module files will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-03-30):

From: The IESG
To: IETF-Announce
CC: chopps@chopps.org, draft-ietf-lsr-isis-flex-algo-yang@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for IS-IS Application-Specific Link Attributes and Flexible Algorithm) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'YANG Data Model for IS-IS
Application-Specific Link Attributes and
  Flexible Algorithm'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-03-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model to support IS-IS Application-
  Specific Link Attributes and Flexible Algorithm.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flex-algo-yang/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.


Document: draft-ietf-lsr-isis-flex-algo-yang-04
Reviewer: Christian Hopps

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

    1. Does the working group (WG) consensus represent the strong concurrence of
      a few individuals, with others being silent, or did it reach broad
      agreement?

There was a limited WG participation due in part to lack of excitement for YANG
module development.

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No.

    3. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in separate
      email messages to the responsible Area Director. (It should be in a
      separate email because this questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the
      contents of the document? Have a significant number of potential
      implementers indicated plans to implement? Are any existing
      implementations reported somewhere, either in the document itself (as
      [RFC 7942][3] recommends) or elsewhere (where)?

N/A.

    ## Additional Reviews

    5. Do the contents of this document closely interact with technologies in
      other IETF working groups or external organizations, and would it
      therefore benefit from their review? Have those reviews occurred? If yes,
      describe which reviews took place.

No, the document does not need external WG or Org reviews.

The doc was reviewed by routing directorate, and comments were addressed.

    6. Describe how the document meets any required formal expert review
      criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
      reviews.

Document was reviewed by YANG doctors, and comments were addressed.

    7. If the document contains a YANG module, has the final version of the
      module been checked with any of the [recommended validation tools][4] for
      syntax and formatting validation? If there are any resulting errors or
      warnings, what is the justification for not fixing them at this time?
      Does the YANG module comply with the Network Management Datastore
      Architecture (NMDA) as specified in [RFC 8342][5]?

Unknown on validation tools. There are examples provided. The module augments
the base IS-IS YANG module and doesn't change NMDA compliance.

    8. Describe reviews and automated checks performed to validate sections of
      the final version of the document written in a formal language, such as
      XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

No extra checks.

    ## Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that
      this document is needed, clearly written, complete, correctly designed,
      and ready to be handed off to the responsible Area Director?

Document is Ready. There are a couple minor grammar edits that can be
addressed during RFC editor. No need for a new version of the doc though.

    10. Several IETF Areas have assembled [lists of common issues that their
        reviewers encounter][6]. For which areas have such issues been
        identified and addressed? For which does this still need to happen in
        subsequent reviews?
None.

    11. What type of RFC publication is being requested on the IETF stream
        ([Best Current Practice][12], [Proposed Standard, Internet
        Standard][13], [Informational, Experimental or Historic][14])? Why is
        this the proper type of RFC? Do all Datatracker state attributes
        correctly reflect this intent?

Proposed Standard. All YANG modules for IS-IS are standards track documents.

    12. Have reasonable efforts been made to remind all authors of the
        intellectual property rights (IPR) disclosure obligations described in
        [BCP 79][7]? To the best of your knowledge, have all required
        disclosures been filed? If not, explain why. If yes, summarize any
        relevant discussion, including links to publicly-available messages when
        applicable.

All authors polled and none indicated knowledge of IPR.

    13. Has each author, editor, and contributor shown their willingness to be
        listed as such? If the total number of authors and editors on the front
        page is greater than five, please provide a justification.

Yes.

    14. Document any remaining I-D nits in this document. Simply running the
        [idnits tool][8] is not enough; please review the ["Content Guidelines"
        on authors.ietf.org][15]. (Also note that the current idnits tool
        generates some incorrect warnings; a rewrite is underway.)

The latest run of ID nits indicates 'NOT RECOMMENDED' should be listed as one of
the RFC2119 words. Other nits are not-applicable.

    15. Should any informative references be normative or vice-versa? See the
        [IESG Statement on Normative and Informative References][16].

No.

    16. List any normative references that are not freely available to anyone.
        Did the community have sufficient access to review any such normative
        references?

None.

    17. Are there any normative downward references (see [RFC 3967][9] and [BCP
        97][10]) that are not already listed in the [DOWNREF registry][17]? If
        so, list them.

No.

    18. Are there normative references to documents that are not ready to be
        submitted to the IESG for publication or are otherwise in an unclear
        state? If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing
        RFCs? If so, does the Datatracker metadata correctly reflect this and
        are those RFCs listed on the title page, in the abstract, and discussed
        in the introduction? If not, explain why and point to the part of the
        document where the relationship of this document to these other RFCs is
        discussed.

Doesn't update other docs.

    20. Describe the document shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all aspects of the document requiring IANA
        assignments are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that each newly created IANA registry
        specifies its initial contents, allocations procedures, and a reasonable
        name (see [RFC 8126][11]).

Has a standard YANG document IANA section.

    21. List any new IANA registries that require Designated Expert Review for
        future allocations. Are the instructions to the Designated Expert clear?
        Please include suggestions of designated experts, if appropriate.

None.


    [1]: https://www.ietf.org/about/groups/iesg/ [2]:
    https://www.rfc-editor.org/rfc/rfc4858.html [3]:
    https://www.rfc-editor.org/rfc/rfc7942.html [4]:
    https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]:
    https://www.rfc-editor.org/rfc/rfc8342.html [6]:
    https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]:
    https://www.rfc-editor.org/info/bcp79 [8]:
    https://www.ietf.org/tools/idnits/ [9]:
    https://www.rfc-editor.org/rfc/rfc3967.html [10]:
    https://www.rfc-editor.org/info/bcp97 [11]:
    https://www.rfc-editor.org/rfc/rfc8126.html [12]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
    https://authors.ietf.org/en/content-guidelines-overview [16]:
    https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
    [17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.


Document: draft-ietf-lsr-isis-flex-algo-yang-04
Reviewer: Christian Hopps

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

    1. Does the working group (WG) consensus represent the strong concurrence of
      a few individuals, with others being silent, or did it reach broad
      agreement?

There was a limited WG participation due in part to lack of excitement for YANG
module development.

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No.

    3. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in separate
      email messages to the responsible Area Director. (It should be in a
      separate email because this questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the
      contents of the document? Have a significant number of potential
      implementers indicated plans to implement? Are any existing
      implementations reported somewhere, either in the document itself (as
      [RFC 7942][3] recommends) or elsewhere (where)?

N/A.

    ## Additional Reviews

    5. Do the contents of this document closely interact with technologies in
      other IETF working groups or external organizations, and would it
      therefore benefit from their review? Have those reviews occurred? If yes,
      describe which reviews took place.

No, the document does not need external WG or Org reviews.

The doc was reviewed by routing directorate, and comments were addressed.

    6. Describe how the document meets any required formal expert review
      criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
      reviews.

Document was reviewed by YANG doctors, and comments were addressed.

    7. If the document contains a YANG module, has the final version of the
      module been checked with any of the [recommended validation tools][4] for
      syntax and formatting validation? If there are any resulting errors or
      warnings, what is the justification for not fixing them at this time?
      Does the YANG module comply with the Network Management Datastore
      Architecture (NMDA) as specified in [RFC 8342][5]?

Unknown on validation tools. There are examples provided. The module augments
the base IS-IS YANG module and doesn't change NMDA compliance.

    8. Describe reviews and automated checks performed to validate sections of
      the final version of the document written in a formal language, such as
      XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

No extra checks.

    ## Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that
      this document is needed, clearly written, complete, correctly designed,
      and ready to be handed off to the responsible Area Director?

Document is Ready. There are a couple minor grammar edits that can be
addressed during RFC editor. No need for a new version of the doc though.

    10. Several IETF Areas have assembled [lists of common issues that their
        reviewers encounter][6]. For which areas have such issues been
        identified and addressed? For which does this still need to happen in
        subsequent reviews?
None.

    11. What type of RFC publication is being requested on the IETF stream
        ([Best Current Practice][12], [Proposed Standard, Internet
        Standard][13], [Informational, Experimental or Historic][14])? Why is
        this the proper type of RFC? Do all Datatracker state attributes
        correctly reflect this intent?

Proposed Standard. All YANG modules for IS-IS are standards track documents.

    12. Have reasonable efforts been made to remind all authors of the
        intellectual property rights (IPR) disclosure obligations described in
        [BCP 79][7]? To the best of your knowledge, have all required
        disclosures been filed? If not, explain why. If yes, summarize any
        relevant discussion, including links to publicly-available messages when
        applicable.

All authors polled and none indicated knowledge of IPR.

    13. Has each author, editor, and contributor shown their willingness to be
        listed as such? If the total number of authors and editors on the front
        page is greater than five, please provide a justification.

Yes.

    14. Document any remaining I-D nits in this document. Simply running the
        [idnits tool][8] is not enough; please review the ["Content Guidelines"
        on authors.ietf.org][15]. (Also note that the current idnits tool
        generates some incorrect warnings; a rewrite is underway.)

The latest run of ID nits indicates 'NOT RECOMMENDED' should be listed as one of
the RFC2119 words. Other nits are not-applicable.

    15. Should any informative references be normative or vice-versa? See the
        [IESG Statement on Normative and Informative References][16].

No.

    16. List any normative references that are not freely available to anyone.
        Did the community have sufficient access to review any such normative
        references?

None.

    17. Are there any normative downward references (see [RFC 3967][9] and [BCP
        97][10]) that are not already listed in the [DOWNREF registry][17]? If
        so, list them.

No.

    18. Are there normative references to documents that are not ready to be
        submitted to the IESG for publication or are otherwise in an unclear
        state? If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing
        RFCs? If so, does the Datatracker metadata correctly reflect this and
        are those RFCs listed on the title page, in the abstract, and discussed
        in the introduction? If not, explain why and point to the part of the
        document where the relationship of this document to these other RFCs is
        discussed.

Doesn't update other docs.

    20. Describe the document shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all aspects of the document requiring IANA
        assignments are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that each newly created IANA registry
        specifies its initial contents, allocations procedures, and a reasonable
        name (see [RFC 8126][11]).

Has a standard YANG document IANA section.

    21. List any new IANA registries that require Designated Expert Review for
        future allocations. Are the instructions to the Designated Expert clear?
        Please include suggestions of designated experts, if appropriate.

None.


    [1]: https://www.ietf.org/about/groups/iesg/ [2]:
    https://www.rfc-editor.org/rfc/rfc4858.html [3]:
    https://www.rfc-editor.org/rfc/rfc7942.html [4]:
    https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]:
    https://www.rfc-editor.org/rfc/rfc8342.html [6]:
    https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]:
    https://www.rfc-editor.org/info/bcp79 [8]:
    https://www.ietf.org/tools/idnits/ [9]:
    https://www.rfc-editor.org/rfc/rfc3967.html [10]:
    https://www.rfc-editor.org/info/bcp97 [11]:
    https://www.rfc-editor.org/rfc/rfc8126.html [12]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
    https://authors.ietf.org/en/content-guidelines-overview [16]:
    https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
    [17]: https://datatracker.ietf.org/doc/downref/