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

Discuss

Ketan Talaulikar

Yes

Gunter Van de Velde

No Objection

Andy Newton
Christopher Inacio
Deb Cooley
Éric Vyncke
Gorry Fairhurst
Jim Guichard
Mahesh Jethanandani
Mike Bishop
Mohamed Boucadair
Roman Danyliw
Tommy Jensen

No Record

Charles Eckel

Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.

Ketan Talaulikar
Discuss
Discuss (2026-06-26 for -11) Sent 
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.
Gunter Van de Velde
Yes
Andy Newton
No Objection
Christopher Inacio
No Objection
Deb Cooley
No Objection
Comment (2026-06-22 for -08) Sent 
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).
Éric Vyncke
No Objection
Comment (2026-06-22 for -08) Sent 
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 ? ;-)
Gorry Fairhurst
No Objection
Comment (2026-07-01 for -18) Not sent 
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.
Jim Guichard
No Objection
Mahesh Jethanandani
No Objection
Comment (2026-06-30 for -17) Sent 
Thank you for addressing my comments.
Mike Bishop
No Objection
Comment (2026-06-26 for -12) Sent 
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"
Mohamed Boucadair
(was Discuss) No Objection
Comment (2026-07-08) Sent 
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/
Roman Danyliw
No Objection
Comment (2026-06-25 for -09) Not sent 
Thank you to Russ Housley for the GENART review.
Tommy Jensen
No Objection
Charles Eckel
No Record