Re: [netmod] [Anima] mcr's YANG question raised during the ANIMA WG session

["Jan Lindblad (jlindbla)" <[e-mail]>]

Michael,

> I have taken a third pass at getting the extension of yang modules done.

Sorry for my slow response. I had a look at your latest version now, and I think it looks good from a general YANG pov. 

> This time, I am using RFC8791 (Structure), rather than YANG-DATA.
> I do not use Augment (or structure-augment).  Not sure how I would.

Yes, if what you want is to describe protocol messages, sx:structure would be a good way to package this.

> My module D, which wants to inherit from A, B and C, even though B and C also
> inherit from A, looks like this:
> 
>  sx:structure module-D-things {
>    uses module-D;
>  }
> 
>  grouping module-D {
>    description "A module D structure";
>    container module-D {
>      description "A wrapper container for the module-D things";
>      uses vA3:module-A-contents;
>      uses vB3:module-B-contents;
>      uses vC3:module-C-contents;
>      uses module-D-contents;
>    }
>  }
> 
>  grouping module-D-contents {
>    leaf attribute-D-Delta {
>      type binary;
>      description "DeltaThree";
>    }
>  }
> 
> This produces a tree printout of:
> 
> module: module-D3
> 
>  grouping module-D:
>    +-- module-D
>       +-- attribute-A-Alpha?   binary
>       +-- attribute-B-Beta?    binary
>       +-- attribute-C-Gamma?   binary
>       +-- attribute-D-Delta?   binary
>  grouping module-D-contents:
>    +-- attribute-D-Delta?   binary
> 
> This is not great, but better than before.

What aspect of this solution do you consider less than optimal? That's not quite obvious to me.

If any of this causes problems with SID generation, I'm afraid that's not my territory. :-)

> The results are still at:
> 
>    https://github.com/mcr/yang-augment-test
>    look at module-?3.yang and practice3.sh.

Thanks for putting this in concrete and easily accessible form, i.e. as compilable YANG modules on github.

Best Regards,
/jan


> 
> Please tell me/us (ANIMA WG) if we can do better.
> We have revisions to RFC8366 that we'd like to go forward with, but we need
> to make sure that we accomodate the extensions that are planned.
> Probably converting to RFC8791 is also a good thing.
> 
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
>