Vinod, I would think that different implementations would want to choose their own values for the implementation details below, so this sort of information should definitely not be part of the standard YANG modules. Being able to provide this sort of information as annotations in YANG, however, is often very useful. Many projects do.
The standard YANG extension keyword already allows this practice, so if you
just replace the equals sign below "=" with space " ", this would already be
valid YANG and presumably useful for your implementation, assuming you declare
your extensions properly.
I don't see any need to change or extend YANG for your use case.
/jan
> Views on received suggestions/comments
> We accept the mechanism of decorating YANG modules/submodules with
> annotations is NOT a correct approach, as pointed out, there are maintenance
> issues.
> As suggested, we can choose one of the alternative which defines the
> annotations in separate module/sub-module. For Example: similar to augment,
> we can use the compiler-annotation extension to have an argument, which
> identifies the target node which is being annotated.
> ca:compiler-annotation /candidate-servers/server{
> ca:app-data-structure{
> ca:data-structure="map";
> ca:key="name";
> }
> ca:app-derived{
> ca:extended-name="special-server";
> }
> }
--
Jan Lindblad, [email protected], +46 702855728
Solutions Architect/Business Development, Tail-f
Tail-f is now a part of Cisco
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
