Re: [netconf] Which is the better way for vendor-specific extension?

Chaode,

This question might belong more to the domain of the NETMOD WG, which deals with modeling questions.

You are saying you find the augment mechanism "will be a heavy burden for the orchestrator", but you are not giving any examples or other explanations of why you think so. Then you propose an alternate mechanism with opaque key-value lists. I don't see in what way this would be any less burdensome (except maybe for the implementor, who may be tempted to skip the documentation step). Quite the contrary.

In order for the additional-info mechanism to work, all YANG models would need to include   uses additional-info-grouping;   statements everywhere the modeler could possibly imagine anyone wanting to extend the model. That sounds terribly burdensome to me. Or else, maybe you are suggesting the NETCONF protocol should be changed to allow such key value lists literally everywhere. Maybe that is why you posted to NETCONF? 

If you prefer (undocumented, or documented outside of YANG modules) key-value lists in your vendor extensions, you can go right ahead and implement that. Just use augment to add that additional-info-grouping structure anywhere you like. I can't say I'd recommend this approach, however.

Best Regards,
/jan

> On 17 May 2023, at 10:25, yuchaode <yuchaode=40huawei.com@dmarc.ietf.org> wrote:
> 
> Hi friends,
>  
> Since the definition of standard cannot always cover all the attributes of different vendors, vendor-specific extension is necessary to exist.
> Especially for IETF YANG data model, some of our drafts takes years to release. Vendors cannot wait for all the drafts are released, and their development has to begin with an immature version, and make some extensions based on their owned understanding.
>  
> When I learned YANG language on my first time, people told me that we can use some vendor-specific YANG models to augment the existing models to make this vendor-specific extension.
> For example, there is an ietf-example.yang, in which there are three attributes named attr-1, attr-2, attr-3.
> Vendor A thinks that these three attributes are not enough, he would like to extend attr-4. He can write a vendor-a-ext.yang to specify this attribute.
> So when to retrieve the ietf-example data, for vendor A, he can response with:
> {
>  “ietf-example:root”: {
> “attr-1”: a,
> “attr-2”: b,
> “attr-3”: c,
> “vendor-a-ext:attr-4”: d
>   }
> }
>  
> In multi-vendor scenario, there could be a lot of vendor-specific extension. If the source structure is very complex, the vendor-specific extension could be everywhere, this is messy and will be a heavy burden for the orchestrator.
> Is there any suggestion to deal with these flexible vendor-specific extension?
>  
> In some traditional protocols, such as CORBA, a fixed name-value pair structure is provided for vendor-specific extension.
> For vendor A’s scenario, it can work like below (here I use json format for better comparison):
> {
>   “root”: {
> “attr-1”: a,
> “attr-2”: b,
> “attr-3”: c,
>    “additional-info”: {
> “name”: “vendor-a-ext:attr-4”,
> “value”: d
> }
> }
> }
> So for the orchestrator, it is easy to recognize which part of attributes are standard and which part of attributes are vendor-specific. It will be of great help for their programing.
>  
> I remember there used to be a discussion and opposed to introduce this opaque structure, which was said to be harmful for standardization.
> But I also found such kinds of experience in openconfig, such like the properties structure in openconfig-platform module.
> So, which is a better way for vendor-specific extension?
>  
> The above is just my superficial views, welcome to have your comments. Thanks!
>  
> B.R.
> Chaode
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>