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