From nobody Wed May 17 01:53:56 2023 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FF6C151552 for ; Wed, 17 May 2023 01:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFzi89N_kVqY for ; Wed, 17 May 2023 01:53:50 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2076CC14CF15 for ; Wed, 17 May 2023 01:53:49 -0700 (PDT) Received: from smtpclient.apple (213-67-237-150-no99.tbcn.telia.com [213.67.237.150]) by mail.tail-f.com (Postfix) with ESMTPSA id 6B4EC1AE02AA; Wed, 17 May 2023 10:53:47 +0200 (CEST) From: Jan Lindblad Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_750ADBC9-E64D-45B4-95D3-C2C34C91D7B8" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Date: Wed, 17 May 2023 10:53:46 +0200 In-Reply-To: Cc: "netconf@ietf.org" To: yuchaode References: X-Mailer: Apple Mail (2.3696.120.41.1.3) Archived-At: Subject: Re: [netconf] Which is the better way for vendor-specific extension? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: NETCONF WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 May 2023 08:53:54 -0000 --Apple-Mail=_750ADBC9-E64D-45B4-95D3-C2C34C91D7B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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?=20 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 = wrote: >=20 > Hi friends, > =20 > 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. > =20 > 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: > { > =E2=80=9Cietf-example:root=E2=80=9D: { > =E2=80=9Cattr-1=E2=80=9D: a, > =E2=80=9Cattr-2=E2=80=9D: b, > =E2=80=9Cattr-3=E2=80=9D: c, > =E2=80=9Cvendor-a-ext:attr-4=E2=80=9D: d > } > } > =20 > 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? > =20 > In some traditional protocols, such as CORBA, a fixed name-value pair = structure is provided for vendor-specific extension. > For vendor A=E2=80=99s scenario, it can work like below (here I use = json format for better comparison): > { > =E2=80=9Croot=E2=80=9D: { > =E2=80=9Cattr-1=E2=80=9D: a, > =E2=80=9Cattr-2=E2=80=9D: b, > =E2=80=9Cattr-3=E2=80=9D: c, > =E2=80=9Cadditional-info=E2=80=9D: { > =E2=80=9Cname=E2=80=9D: =E2=80=9Cvendor-a-ext:attr-4=E2=80=9D, > =E2=80=9Cvalue=E2=80=9D: 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. > =20 > 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? > =20 > The above is just my superficial views, welcome to have your comments. = Thanks! > =20 > B.R. > Chaode > _______________________________________________ > netconf mailing list > netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = --Apple-Mail=_750ADBC9-E64D-45B4-95D3-C2C34C91D7B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=3D40huawei.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:
{
 =E2=80=9Cietf-example:root=E2=80=9D: {
=E2=80=9Cattr-1=E2=80=9D: a,
=E2=80=9Cattr-2=E2=80=9D: b,
=E2=80=9Cattr-3=E2=80=9D: c,
=E2=80=9Cvendor-a-ext:attr-4=E2=80=9D: 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=E2=80= =99s scenario, it can work like below (here I use json format for better = comparison):
{
  = =E2=80=9Croot=E2=80=9D: {
=E2=80=9Cattr-1=E2=80=9D: = a,
=E2=80=9Cattr-2=E2=80=9D: b,
=E2=80=9Cattr-3=E2=80=9D: c,
   =E2=80=9Cadditional-info=E2=80=9D: {
=E2=80=9Cname=E2=80=9D: =E2=80=9Cvendor-a-ext:attr-4=E2=80=9D,<= o:p class=3D"">
=E2=80=9Cvalue=E2=80=9D: 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
https://www.ietf.org/mailman/listinfo/netconf

= --Apple-Mail=_750ADBC9-E64D-45B4-95D3-C2C34C91D7B8--