Chris,
One concern is simply one of scale: doing this will increase the size of the document. At what point do things become sufficiently awkward that we want to have a separate, concurrent document. In other words, if the requirement is for concurrent delivery, is co-location really a requirement? Regards, Tony > On Mar 29, 2019, at 9:17 AM, Christian Hopps <cho...@chopps.org> wrote: > > > The base YANG modules for IS-IS and OSPF both include operational state to > describe TLV data. During the discussion about OSPFv3's version of this data, > I brought up the issue of when and how the base modules should be augmented > to add new TLV types to the model, suggesting it be done inline and with the > RFC that adds the new feature/functionality to the protocol. > > I'll go farther here and say this should apply to all the YANG required for > management of the new feature, and it should all be added inline with the > feature (i.e., in the same draft). In other words new features/functionality > should include the YANG augment required to manage said > features/functionality. > > This has been suggested/tried previously with SNMP with varying (low) levels > of success. The difference here is 1) YANG additions (a new module perhaps > just augmenting the base) is easy, whereas SNMP wasn't. Additionally, > operators weren't using SNMP to fully manage functionality (e.g., not doing > configuration) so a requirement for extra work was harder to justify. > Operators *do* want to fully manage their networks/servers with YANG though. > > The argument against this during the meeting was that it would create many > small modules. I don't find this compelling (i.e., "so"? :) > > Assume I'm an operator -- the actual consumer of this management stuff: > > - If I'm going to use this new feature X, I need to be able to manage it. So > I need it YANG for it. Not only do I need any new TLV data in the operational > state, but I need the configuration and any other operational state right > along with it. Otherwise each vendor has to add new YANG to their vendor > modules, or the feature is useless to me. I can't use something if I can't > turn it on. > > - I don't care about having many smaller modules that augment the base module > -- at all. Quite the opposite actually, when new functionality is accompanied > by it's own module it provides me a simple way to see if that functionality > is present as the module will be present in the YANG capabilities announced > by the device. > > I'd be interested in hearing reasons we (as a WG) shouldn't just expect a > YANG module (even if it's small) to be included with drafts that add new > functionality. > > Thanks, > Chris. > _______________________________________________ > 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
