Return-Path: X-Original-To: teas@ietfa.amsl.com Delivered-To: teas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE6DC14F6E3; Fri, 7 Jun 2024 11:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.094 X-Spam-Level: X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rhV8BErVuonX; Fri, 7 Jun 2024 11:30:14 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E884C14F739; Fri, 7 Jun 2024 11:30:14 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-7041cda5dcfso382020b3a.2; Fri, 07 Jun 2024 11:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717785013; x=1718389813; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=DtPNGTW2hgKfT4GH/eO9FEf23g8aS2sW30aGaRB85QQ=; b=nixyWqdVv+yuQ0UVhkhsWtO7mCEaJX2Dt265RXH3DXwQDtk6Ur4nY5tz19QSVA+am1 212Ra0oxUup+eMsO3gpIYvimIrDSH1+O2/rQihz8YCjNzfq8cNsFbXyZuHDSQrRPdTtw LkjPgevYwUz4Ag8tf4bN+ynCvzNvE7oEdE8HziETTgyeFGsue9bQAOLAMENRsN00xwZn +D9d671derh8qbW95YPCj2l/3SYOdc2lzCkyJsclAQEgNVbM0JQn6NnNqnfdOXCgWXhJ h9z16w1Pq2rl4zpyO3T5+ypNpbM81bd4XD0EbNIlw6t0lN1SR4Lkv93GEZgs2hkxxWZB qZFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717785013; x=1718389813; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=DtPNGTW2hgKfT4GH/eO9FEf23g8aS2sW30aGaRB85QQ=; b=tQQtV1iH57sMcf9kCJrq1toazj54yYGDuDVW/2MqNwUq+NuM4cGAkv226yCJUu1c+7 EEUd2D5bjisJ8Ys566hMSsI4/Dq8ZoNMdkd/pLp/9xev4oS5/LLru9DZc7rj6DYJdf5P vRqKqDCnP3uUpXjwxlcpm+wIDjW6wlS7OG6OWd2i6vlnEiWyXm1aPS65N5oqdU6hVq2J vUl74nQcWf0gHLITvqacPexAmjE/uvfhGYuGsh8UZCTVZFQphkUgFCzhJPFgwpvVIVEQ SHSaHuBFHzlenL30LPVPH0CpuOFVRk1Yh6KanB/S9k0Lf+K27OhZAodUvvZBSVJNZKRW ySmA== X-Forwarded-Encrypted: i=1; AJvYcCXY8MkrnJIJGg3rOpj5Vf3oQWPcDTSdogMQJNaGuvlGlhAqRD/laobSSS6iFA6eyYGwWdLay1VrE8v63bbtxfrv9/O+AJx4ece3XvwHWbHG5jyHGtS3HEui7jzRFgoCPyaen4xFKkH23gDNssdPBAEMA9SnpsNFQI3S4UDi6LVNIL5zbSxm4sBBOw== X-Gm-Message-State: AOJu0YxSTLM93bFb78hd9ipSNnyhF58V222BwdB5lnV8hKC3xXKfHcLP uIlKGnjhxBgR07BQWSLi1HHcIN77hTtuce96h0NEeiKkXuwgpOA+ X-Google-Smtp-Source: AGHT+IEhbWr+G7KM2G3IgiIpvzLwCqLIt2ZjyJNiP5HLrEUa8BhUS7p429UiN58YOfCHk2jr679Upg== X-Received: by 2002:a05:6a20:3d8a:b0:1b2:565a:4d1c with SMTP id adf61e73a8af0-1b2f9a0d350mr4054596637.24.1717785013052; Fri, 07 Jun 2024 11:30:13 -0700 (PDT) Received: from smtpclient.apple (c-69-181-169-15.hsd1.ca.comcast.net. [69.181.169.15]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-6de221268cesm2926428a12.38.2024.06.07.11.30.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2024 11:30:10 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <5E5DB371-3050-4FB5-87B0-E1DF48FC3397@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CE725889-0D4E-4FF9-9C24-E59BA48202F2" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\)) Date: Fri, 7 Jun 2024 11:30:08 -0700 In-Reply-To: To: "Gunter van de Velde (Nokia)" References: <171775367359.61526.13460294319166688678@ietfa.amsl.com> X-Mailer: Apple Mail (2.3696.120.41.1.8) Message-ID-Hash: 3PCM4GZLZI4ZEYG7VVRFPGJXGMEFVYOR X-Message-ID-Hash: 3PCM4GZLZI4ZEYG7VVRFPGJXGMEFVYOR X-MailFrom: mjethanandani@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Dhruv Dhody , The IESG , "draft-ietf-teas-actn-vn-yang@ietf.org" , "teas-chairs@ietf.org" , "teas@ietf.org" , "vbeeram@juniper.net" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BTeas=5D_Re=3A_Gunter_Van_de_Velde=27s_Discuss_on_draft-ietf-tea?= =?utf-8?q?s-actn-vn-yang-27=3A_=28with_DISCUSS=29?= List-Id: Traffic Engineering Architecture and Signaling working group discussion list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_CE725889-0D4E-4FF9-9C24-E59BA48202F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Gunter/Dhruv, Gunter, you are right that the idea of YANG has been to make it a very = readable, and therefore understandable language. And this extends to how = node names are selected. The section that you quote below goes to the = heart of that desire, and has been captured after extensive discussion = in the NETMOD WG. If I understand you, there are two issues that you = highlighting. The use of acronyms in node names, and the naming of = parent vs child nodes. To the use of acronyms in node names, there is obviously a balance = between that and providing descriptive enough names that make the model = reading easy, i.e., avoid long XPaths. Generally, if the draft uses an = acronym and explains its usage in the draft, it is fair to use it in the = YANG model. Towards that end, the compromise that the WG came up with, = sounds reasonable to me. However, I do expect the authors to use the = description field in the YANG model to carry some of that description = from the draft, to help with readability. That is because once the YANG = model is separated from the draft, the description in the draft can get = lost. Therefore, if the YANG model names a node =E2=80=98vn=E2=80=99, I = expect the description field to expand it to say =E2=80=9CVirtual = Network (VN) ...=E2=80=9D. Moreover, lot of tools, including OpenAPI = generators, use the description field to describe usage, which makes it = all the more important to have good descriptions. The use of parent identifier in the child is a litte more straight = forward. There is really no need to. In this case, instead of = =E2=80=98vn-id=E2=80=99, =E2=80=98id=E2=80=99 would have sufficed. HTH. > On Jun 7, 2024, at 6:07 AM, Gunter van de Velde (Nokia) = wrote: >=20 > Hi Dhruv, > =20 > Using container names in leaf names is something that should be = avoided. It adds no additional meaning and increases the path length. > =20 > Descriptions clarify what a particular node or statement is intended = for, making the model easier to understand for those who read it. > =20 > There is a hint about this specified in: > = https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-20#sect= ion-4.3.1 = > =20 > =E2=80=9C > Identifiers SHOULD include complete words and/or well-known = acronyms > or abbreviations. Child nodes within a container or list SHOULD = NOT > replicate the parent identifier. YANG identifiers are hierarchical > and are only meant to be unique within the the set of sibling nodes > defined in the same module namespace. > =20 > It is permissible to use common identifiers such as "name" or "id" = in > data definition statements, especially if these data nodes share a > common data type. > =E2=80=9C > =20 > However, I'm uncertain whether the IETF mandates or enforces the use = of human-readable names for YANG nodes, or whether there are guidelines = to avoid including parent node names in the names of sibling nodes. > =20 > Perhaps @Mahesh Jethanandani (NETMOD = AD) could provide some insight on this matter? If this aspect hasn=E2=80=99= t been a priority and has not been enforced at the IETF, then I might be = overly concerned about the readability and style of YANG.=20 > =20 > G/ > =20 > =20 > =20 > =20 > =20 > From: Dhruv Dhody >=20= > Sent: Friday, June 7, 2024 2:09 PM > To: Gunter van de Velde (Nokia) > > Cc: The IESG >; = draft-ietf-teas-actn-vn-yang@ietf.org = ; teas-chairs@ietf.org = ; teas@ietf.org ; = vbeeram@juniper.net > Subject: Re: Gunter Van de Velde's Discuss on = draft-ietf-teas-actn-vn-yang-27: (with DISCUSS) > =20 > =20 > CAUTION: This is an external email. Please be very careful when = clicking links or opening attachments. See the URL nok.it/ext = for additional information. > =20 >=20 > Hi Gunter, > =20 > On Fri, Jun 7, 2024 at 12:01=E2=80=AFPM Gunter van de Velde (Nokia) = > = wrote: > I understand. It is always a compromise. I fight with this myself all = the time when suffering yang coding moments. > =20 > In this file i see for example src. Why not use =E2=80=98source=E2=80=99= ? same with other key-words. > =20 > =20 > Dhruv: It was kept as 'src' to match it with 'dest'. > If we change it, we should change to 'source' and 'destination'. And = also handle other leaves like multi-src, multi-dest, src-vn-ap-id, = dest-vn-ap-id and feature name 'multi-src-dest'. > =20 > Longer names also makes the tree diagram difficult to follow because = of the 80 char width (especially with the feature name). > =20 > =20 > About your example: > =20 > path "/virtual-network/vn/vn-id"; will become > path "/virtual-network/virtual-network/virtual-network-identifier"; > =20 > I question the fact that it is not required that the virtual-network = should be repeated for the =E2=80=9Cidentifier=E2=80=9D leaf. > More user friendly and less long would be: > path "/virtual-network/virtual-network/identifier"; > =20 > Once you are in the node virtual-network, you know you are handling a = virtual-network identifier. Why name it double? It makes the path longer = for no apparent reason as you correctly observed. > =20 > =20 > Dhruv: I agree. If the change is made, following your suggestion would = make sense. I was just illustrating my point :) > =20 > I am a little apprehensive in making this late change that will have a = huge churn in the document (and the model). The JSON examples would need = to be reworked as well as other YANG models that build on the VN model. = Could I add text in the description clause in the YANG module that = expands these abbreviations instead?=20 > =20 > But, if you feel strongly about this (and the responsible AD confirms) = I will make the requested change. =20 > =20 > Thanks, > Dhruv > =20 > =20 > =20 > =20 > =20 > =20 > G/ > =20 > =20 > From: Dhruv Dhody >=20= > Sent: Friday, June 7, 2024 12:35 PM > To: Gunter van de Velde (Nokia) > > Cc: The IESG >; = draft-ietf-teas-actn-vn-yang@ietf.org = ; teas-chairs@ietf.org = ; teas@ietf.org = ;vbeeram@juniper.net > Subject: Re: Gunter Van de Velde's Discuss on = draft-ietf-teas-actn-vn-yang-27: (with DISCUSS) > =20 > =20 > CAUTION: This is an external email. Please be very careful when = clicking links or opening attachments. See the URL nok.it/ext = for additional information. > =20 >=20 > Hi Gunter, > =20 > Thanks for your review. > =20 > On Fri, Jun 7, 2024 at 10:47=E2=80=AFAM Gunter Van de Velde via = Datatracker > wrote: > Gunter Van de Velde has entered the following ballot position for > draft-ietf-teas-actn-vn-yang-27: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position= s/ = =20 > for more information about how to handle DISCUSS and COMMENT = positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-teas-actn-vn-yang/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > # Gunter Van de Velde, RTG AD, comments for = draft-ietf-teas-actn-vn-yang-27 >=20 > Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ = > documenting the handling of ballots. >=20 > Many thanks for the RTG-DIR reviews from Darren Dukes and many thanks = to Vishnu > Pavan Beeram for the Shepherd write-up. >=20 > Please find below 1 blocking DISCUSS about the yang node names used, = that seems > reasonably simple to address >=20 > #DISCUSS items > #=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > ##DISCUSS1 > One of the motivations to use YANG is to have human readable structure = to > understand config and state of a device. When looking through the = document i > see many very abbreviated acronymns. e.g. vn, vn-id, src, src-vn-ap.id = , etc >=20 > If not overly lengthy, why not use node names in the style of source, > virtual-network, virtual-network-id, etc? There is no real reason to = abbreviate > in the yang model, assuming the node names are not overly long and it = makes > reading and understanding the leafs more trivial. >=20 > =20 > Dhruv: The complaint that we get with longer names is that the leafref = paths become too long and lose human readability.=20 > =20 > +--rw virtual-network > +--rw vn* [vn-id] > +--rw vn-id vn-id > =20 > =20 > path "/virtual-network/vn/vn-id"; will become > path "/virtual-network/virtual-network/virtual-network-identifier"; > =20 > The idea of expanding it once as a top container and using VN for = leaves inside seems like a good compromise. I would also consider VN to = be well-known for anyone dealing with this YANG file.=20 > =20 > Hope this explains our thinking, does it make sense to you?=20 > =20 > Thanks, > Dhruv Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_CE725889-0D4E-4FF9-9C24-E59BA48202F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Gunter/Dhruv,

Gunter, = you are right that the idea of YANG has been to make it a very readable, = and therefore understandable language. And this extends to how node = names are selected. The section that you quote below goes to the heart = of that desire, and has been captured after extensive discussion in the = NETMOD WG. If I understand you, there are two issues that you = highlighting. The use of acronyms in node names, and the naming of = parent vs child nodes.

To the use of acronyms in node names, there is obviously a = balance between that and providing descriptive enough names that make = the model reading easy, i.e., avoid long XPaths. Generally, if the draft = uses an acronym and explains its usage in the draft, it is fair to use = it in the YANG model. Towards that end, the compromise that the WG came = up with, sounds reasonable to me. However, I do expect the authors to = use the description field in the YANG model to carry some of that = description from the draft, to help with readability. That is because = once the YANG model is separated from the draft, the description in the = draft can get lost. Therefore, if the YANG model names a node =E2=80=98vn=E2= =80=99, I expect the description field to expand it to say =E2=80=9CVirtua= l Network (VN) ...=E2=80=9D. Moreover, lot of tools, including OpenAPI = generators, use the description field to describe usage, which makes it = all the more important to have good descriptions.
The use of parent identifier in the = child is a litte more straight forward. There is really no need to. In = this case, instead of =E2=80=98vn-id=E2=80=99, =E2=80=98id=E2=80=99 = would have sufficed.

HTH.

On Jun 7, 2024, at 6:07 AM, = Gunter van de Velde (Nokia) <gunter.van_de_velde@nokia.com> wrote:

Hi Dhruv,
 
Using container = names in leaf names is something that should be avoided. It adds no = additional meaning and increases the path length.
 
Descriptions = clarify what a particular node or statement is intended for, making the = model easier to understand for those who read it.
 
There is a hint = about this specified in:
 
=E2=80=9C
   Identifiers SHOULD include complete words and/or = well-known acronyms
   or abbreviations.  Child nodes within a = container or list SHOULD NOT
   replicate the parent identifier.  YANG = identifiers are hierarchical
   and are only meant to be unique within the the = set of sibling nodes
   defined in the same module namespace.
 
   It is permissible to use common identifiers such = as "name" or "id" in
   data definition statements, especially if these = data nodes share a
   common data type.
=E2=80=9C
 
However, I'm = uncertain whether the IETF mandates or enforces the use of = human-readable names for YANG nodes, or whether there are guidelines to = avoid including parent node names in the names of sibling nodes.
 
Perhaps @Mahesh = Jethanandani (NETMOD AD) could provide = some insight on this matter? If this aspect hasn=E2=80=99t been a = priority and has not been enforced at the IETF, then I might be overly = concerned about the readability and style of YANG. 
 
G/
 
 
 
 
 
From: Dhruv Dhody <dhruv.ietf@gmail.com> 
Sent: Friday, June 7, 2024 2:09 = PM
To: Gunter van de Velde (Nokia) = <gunter.van_de_velde@nokia.com>
Cc: The = IESG <iesg@ietf.org>; draft-ietf-teas-actn-vn-yang@ietf.org; teas-chairs@ietf.org; teas@ietf.org; vbeeram@juniper.net
Subject: Re: Gunter Van de Velde's = Discuss on draft-ietf-teas-actn-vn-yang-27: (with DISCUSS)
 
 
CAUTION: This is an = external email. Please be very careful when clicking links or opening = attachments. See the URL nok.it/ext for additional = information.

 

Hi Gunter,
 
On Fri, Jun 7, 2024 at 12:01=E2=80=AFPM Gunter van de Velde (Nokia) = <gunter.van_de_velde@nokia.com> wrote:
I understand. It is always a compromise. I fight with = this myself all the time when suffering yang coding moments.
 
In this file i see for example = src. Why not use =E2=80=98source=E2=80=99? same with other = key-words.
 
 
Dhruv: It was kept as 'src' to match it with = 'dest'.
If we change it, we = should change to 'source' and 'destination'. And also handle other = leaves like multi-src, multi-dest, src-vn-ap-id, dest-vn-ap-id and = feature name 'multi-src-dest'.
 
Longer names = also makes the tree diagram difficult to follow because of the 80 char = width (especially with the feature name).
 
 
About your example:
 
path =
"/virtual-network/vn/vn-id"; will become
path =
"/virtual-network/virtual-network/virtual-network-identifier";
 
I question the fact that it is not = required that the virtual-network should be repeated for the = =E2=80=9Cidentifier=E2=80=9D leaf.
More user friendly = and less long would be:
path =
"/virtual-network/virtual-network/identifier";
 
Once= you are in the node virtual-network, you know you are handling a = virtual-network identifier. Why name it double? It makes the path longer = for no apparent reason as you correctly observed.
 
 
Dhruv: I agree. If the change is made, following your = suggestion would make sense. I was just illustrating my point :)
 
I am a little = apprehensive in making this late change that will have a huge churn in = the document (and the model). The JSON examples would need to be = reworked as well as other YANG models that build on = the VN model. Could I add text in the description clause in the = YANG module that expands these abbreviations instead? 
 
But, if you = feel strongly about this (and the responsible AD confirms) I will make = the requested change.  
 
Thanks,
Dhruv
 
 
 
 
 
 
G/
 
 
From: Dhruv = Dhody <dhruv.ietf@gmail.com> 
Sent: Friday, June 7, 2024 12:35 = PM
To: Gunter van de Velde (Nokia) = <gunter.van_de_velde@nokia.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-teas-actn-vn-yang@ietf.org; teas-chairs@ietf.org; teas@ietf.org;vbeeram@juniper.net
Subject: Re: Gunter Van de Velde's = Discuss on draft-ietf-teas-actn-vn-yang-27: (with DISCUSS)
 
 
CAUTION: This is an = external email. Please be very careful when clicking links or opening = attachments. See the URL nok.it/ext for additional = information.

 

Hi = Gunter,
 
Thanks for your review.
 
On Fri, Jun 7, 2024 at = 10:47=E2=80=AFAM= Gunter Van de Velde via Datatracker <noreply@ietf.org> = wrote:

Gunter Van de Velde has entered the following = ballot position for
draft-ietf-teas-actn-vn-yang-27: = Discuss

When responding, please keep the = subject line intact and reply to all
email addresses = included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ball= ot-positions/ 
for more information about how to handle DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-vn-yang/<= /a>



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

# Gunter Van de Velde, RTG AD, = comments for draft-ietf-teas-actn-vn-yang-27

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/documenting the handling of ballots.

Many thanks for the RTG-DIR reviews from Darren Dukes and = many thanks to Vishnu
Pavan Beeram for the Shepherd = write-up.

Please find below 1 blocking = DISCUSS about the yang node names used, that seems
reasonably simple to address

#DISCUSS items
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
##DISCUSS1
One of the motivations to = use YANG is to have human readable structure to
understand = config and state of a device. When looking through the document i
see many very abbreviated acronymns. e.g. vn, vn-id, = src, src-vn-ap.id, etc

If not overly lengthy, why not use node names = in the style of source,
virtual-network, = virtual-network-id, etc? There is no real reason to abbreviate
in the yang model, assuming the node names are not overly = long and it makes
reading and understanding the leafs more = trivial.

 
Dhruv: The = complaint that we get with longer names is that the leafref paths become = too long and lose human readability. 
 
  +--rw =
virtual-network
     +--rw vn* [vn-id]
        +--rw =
vn-id           &nb=
sp;         vn-id
 
 
path "/virtual-network/vn/vn-id"; will =
become
path =
"/virtual-network/virtual-network/virtual-network-identifier";
 
The idea of expanding it = once as a top container and using VN for leaves inside seems like a good = compromise. I would also consider VN to be well-known for anyone dealing = with this YANG file. 
 
Hope this explains our = thinking, does it make sense to you? 
 
Thanks,
Dhruv


Mahesh = Jethanandani
mjethanandani@gmail.com






= --Apple-Mail=_CE725889-0D4E-4FF9-9C24-E59BA48202F2--