Ketan, Can you please check the latest and hopefully clear your DISCUSS.
Thanks, Acee > On Jun 26, 2026, at 3:29 AM, Ketan Talaulikar via Datatracker > <[email protected]> wrote: > > Ketan Talaulikar has entered the following ballot position for > draft-ietf-lsr-isis-flex-algo-yang-11: 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-lsr-isis-flex-algo-yang/ > > > > ---------------------------------------------------------------------- > 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. > > > > > _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
