----- Original Message ----- From: "Mikael Abrahamsson" <swm...@swm.pp.se> Sent: Sunday, March 31, 2019 8:07 AM
> On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: > > > Additionally, I agree with Yingzhen's comment that it is not clear that > > we want a separate YANG module for every OSPF/IS-IS feature. > > As an operator, I expect to manage my routers using YANG modules. Thus, > every feature that is introduced that would provide requirement for > management and/or provide operational data needs to have an YANG module > come with it, otherwise this new feature isn't useful. > > I don't want YANG to be second class citizen compared to CLI the way SNMP > has been. I also want to avoid having vendor-specific YANG modules if > possible. Thus it makes sense to require YANG module with every new work. > > If this is in the same document or an accompanying document is not of > importance to me, as long as it gets the YANG module shows up in roughly > the same timeframe as the feature. Mikael Do you have any concern about the number of modules involved i.e. in the practical management on Internet routers, does it matter whether the management comes in the form of 100 or 1000 or ... modules? I have a nagging concern, based on experience with older technologies, that difficulties can arise, and that they are not linear with the number of modules. Is management with YANG more difficult if you have 1000 arbitrary prefixes (or module names or module revision dates) floating around or do the tools hide such details and present a coherent picture to an operator? Likewise, does it matter how many features there are, with a Cartesian explosion leading to a five or six digit number of combinations? Tom Petch > -- > Mikael Abrahamsson email: swm...@swm.pp.se > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
