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 BEA65C14F704; Fri, 7 Jun 2024 08:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 8QV1YD9UtMs2; Fri, 7 Jun 2024 08:59:42 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 94C51C14E513; Fri, 7 Jun 2024 08:59:42 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id a1e0cc1a2514c-80b821f3dd6so38858241.2; Fri, 07 Jun 2024 08:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717775981; x=1718380781; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=HpZ6KMbhlH4gOIVNQ+T7Kegf6xd+AECJ1RCRPItvdNc=; b=kk66mHOwAkk7NdF/DBoCGX5Exgxh5DcMViGjOttyTjEFXbpaQpM3q+DYv0XbHIPTRz pA/Cm4qiGwQQBaC6NPrA90TSTQKAx1N5C7lheVCJE3A0L8f9nB9RdhgzL52FUkk4JHvs AAfb/Sdm2nm8HL0kf5rZG1xAgWZVudsdd/vH9Ldm4zxYh2I45CyNIFff6kADn33QbRUR Vh/UTp3OL9JFpVAZ2vu9Vdh5M7r2/bHiAeTh4ttOJBcgH3B1CeFmU+oeNfHj7UcZx7VV r255QTyirbKLEb/uB5FncHifSOESd28R0Fz98C3S95lz9mxXCOztuH7UzM9M214Ahf31 rauw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717775981; x=1718380781; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=HpZ6KMbhlH4gOIVNQ+T7Kegf6xd+AECJ1RCRPItvdNc=; b=PU4iwy0ZOL5Epvm00cqTMwEVvHwEUIOBkaZezZVIUnLQCNWU0Gg2GtaP5nYgu34NPL u16dAYLrEDF7uLMAu7S4fwQXI9rjoQ0c2qqSop9gDx5ef0aOMcnPG3sYSRkSLH35/VeL GNoub3fnylPmaYgfYmajvoR3D6P4WxRyA4d26QmmlPjUDBhlHbg0bMTIMFnWVdxUKoE8 mUpbQY65xu1uVjkWhUzSqma5oEOTjUz8Y53FmiL2irJmESSsiMdyVH6Z1LqOfaRIm3hi knNSLxASg1P5BUsuNS6tJLmqxLo8DUNcCfNjL6+xk8ah/Xge6LJNGY/83xQg46FmebX7 jFTA== X-Forwarded-Encrypted: i=1; AJvYcCVw7K65o8BboU6VJaQmh3bPqbFg+Yzmha8pCHa0MuS+fTB7+y9KoPDeH7S4Bvsxfg9r3nLH95Y4+ZBHC1jGDmhviHcN8uLuIV/3bM0J7/F4opB3wN1q+XZ08j8nA/iWiV0kwqIli7yUbPDH0JOyQX5L42uJ5H77dRzrnMEBCkT49jD4O9Z4M/daMw== X-Gm-Message-State: AOJu0YxiBKR7PdBztWgRFxLwRBD/h1e0kIzAUFQM/C7kIzFZDqr/hOrH moJ9nZYuhDfCRPv8H1Il2cDHBB13vL2Ln7mLtvNhRfORjeKOWpVugeTIIHul7SuQAGJ2vWOzqOq onAUfwNXXOLHF+/BgzeGbew37NqA= X-Google-Smtp-Source: AGHT+IHlxQGm36/7NWpssCi+wQcRmAoq8fUAn7NxrKbgp5qd1zhh5X06+msy8s4fR5r7LeJQ8JEVQga6T0XQwKJVsNI= X-Received: by 2002:a05:6102:f06:b0:48a:3332:595c with SMTP id ada2fe7eead31-48c2761e099mr3544407137.5.1717775981040; Fri, 07 Jun 2024 08:59:41 -0700 (PDT) MIME-Version: 1.0 References: <171775367359.61526.13460294319166688678@ietfa.amsl.com> In-Reply-To: From: Dhruv Dhody Date: Fri, 7 Jun 2024 16:59:01 +0100 Message-ID: To: "Gunter van de Velde (Nokia)" Content-Type: multipart/alternative; boundary="000000000000275982061a4ee3f0" Message-ID-Hash: TAKTPMIEYL7BR552YE6HAVIXBMWJ52TI X-Message-ID-Hash: TAKTPMIEYL7BR552YE6HAVIXBMWJ52TI X-MailFrom: dhruv.ietf@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: Mahesh Jethanandani , 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: --000000000000275982061a4ee3f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gunter, On Fri, Jun 7, 2024 at 2:07=E2=80=AFPM 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: > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-20#sec= tion-4.3.1 > > > > =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. > > > Dhruv: I understand where you are coming from. But within the context of this YANG module and for all practical purposes, these abbreviations are kind of well-known from the POV of the target audience of this model. BTW the discussion on these names came up during the early YANG doctors review as well - https://mailarchive.ietf.org/arch/msg/teas/D9vgIfwsTztWWwfRPd7zBy_Pqu4/ and the WG setteled on the current way where we use complete words as a top container and use abbreviation for child nodes which made sense as a good compromise :) Let's see what Mahesh has to say... Thanks, Dhruv > G/ > > > > > > > > > > > > *From:* Dhruv Dhody > *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) > > > > > > *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. Coul= d > I add text in the description clause in the YANG module that expands thes= e > 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 > *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) > > > > > > *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 Datatrack= er < > 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-ballot-positio= ns/ > 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/ > > > > ---------------------------------------------------------------------- > 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 documen= t > 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 mak= es > 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 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 > > > > > > --000000000000275982061a4ee3f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gunter,

On Fri, Jun 7, 2024 at 2:07=E2=80=AFPM Gunter van de = Velde (Nokia) <gunter.v= an_de_velde@nokia.com> wrote:

Hi Dhr= uv,

=C2=A0

Using = container names in leaf names is something that should be avoided. It adds = no additional meaning and increases the path length.

=C2=A0

Descri= ptions clarify what a particular node or statement is intended for, making = the model easier to understand for those who read it.

=C2=A0

There = is a hint about this specified in:

https://datatracker.ietf.org/doc/html/draf= t-ietf-netmod-rfc6087bis-20#section-4.3.1

=C2=A0

=E2=80= =9C

=C2=A0=C2=A0 Identifiers SHOULD include complete words and/or we= ll-known acronyms

=C2=A0=C2=A0 or abbreviations.=C2=A0 Child nodes within a contai= ner or list SHOULD NOT

=C2=A0=C2=A0 replicate the parent identifier.=C2=A0 YANG identif= iers are hierarchical

=C2=A0=C2=A0 and are only meant to be unique within the the set = of sibling nodes

=C2=A0=C2=A0 defined in the same module namespace.=

=C2=A0

=C2=A0=C2=A0 It is permissible to use common identifiers such as= "name" or "id" in

=C2=A0=C2=A0 data definition statements, especially if these dat= a nodes share a

=C2=A0=C2=A0 common data type.

=E2=80= =9C

=C2=A0

Howeve= r, 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 in= cluding parent node names in the names of sibling nodes.

=C2=A0

Perhap= s @Mahesh J= ethanandani (NETMOD AD) could provide some insight on this matte= r? 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.

=C2=A0


Dhruv: I understand where you are = coming from. But within the context of this YANG module and for all practic= al purposes, these abbreviations=C2=A0are kind of well-known from the POV o= f the target audience of this model.

BTW = the discussion on these names came up during the early YANG doctors review = as well - https://mailarchive.ietf.org/arch/msg/teas/D9vgIfwsTztWW= wfRPd7zBy_Pqu4/ and the WG setteled on the current way where we use com= plete words as a top container and use abbreviation for child nodes which m= ade sense as a good compromise :)=C2=A0

L= et's see what Mahesh has to say...

Th= anks,
Dhruv




=C2=A0
=

G/<= /u>

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

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.

=C2=A0

Hi Gunter,

=C2=A0

I unde= rstand. It is always a compromise. I fight with this myself all the time wh= en suffering yang coding moments.=

=C2=A0=

In thi= s file i see for example src. Why not use =E2=80=98source=E2=80=99? same wi= th other key-words.

=C2=A0=

=C2=A0

Dhruv: It was kept as 'sr= c' to match it with 'dest'.<= u>

If we change it, we should ch= ange to 'source' and 'destination'. And also handle other l= eaves like=C2=A0multi-src, multi-dest, src-vn-ap-id, dest-vn-ap-id and feat= ure name 'multi-src-dest'.

=C2=A0

Longer names also makes the t= ree diagram difficult to follow because of the 80 char width (especially wi= th the feature name).

=C2=A0

=C2=A0

About = your example:

=C2=A0= 

path "/virtual-network/vn/vn-id"; wil=
l become
p=
ath "/virtual-network/virtual-network/virtual-network-identifier"=
;

=C2=A0=

I ques= tion the fact that it is not required that the virtual-network should be re= peated for the =E2=80=9Cidentifier=E2=80=9D leaf.

More u= ser friendly and less long would be:<= /u>

path "/virtual-network/virtual-network/ide=
ntifier";

=C2=A0=

Once y= ou are in the node virtual-network, you know you are handling a virtual-net= work identifier. Why name it double? It makes the path longer for no apparent reason as you correctly observed.

=C2=A0=

=C2=A0

Dhruv: I agree. If the change= is made, following your suggestion would make sense. I was just illustrati= ng my point :)

=C2=A0

I am a little apprehensive in= making this late change that will have a huge churn in the document (and t= he model). The JSON examples would need to be reworked as well as=C2=A0other YANG models that=C2=A0build=C2=A0on the=C2=A0VN mode= l. Could I add text in the description clause in the YANG module that expan= ds these abbreviations instead?=C2=A0

=C2=A0

But, if you feel strongly abo= ut this (and the responsible AD confirms) I will make the requested change.= =C2=A0=C2=A0

=C2=A0

Thanks,<= /p>

Dhruv

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

G/

=C2=A0=

=C2=A0=

From: Dhruv Dhody <dhruv.ietf@gmail.com>
Sent: Friday, June 7, 2024 12:35 PM
To: Gunter van de Velde (Nokia) <gunter.v= an_de_velde@nokia.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-teas-actn-vn-yang@ietf.org<= /a>; teas-chairs@ietf.org; teas@ietf.org; vbeeram@juniper.net
Subject: Re: Gunter Van de Velde's Discuss on draft-ietf-teas-ac= tn-vn-yang-27: (with DISCUSS)

=C2=A0

=C2=A0

CAUTION: This is an external email. Please be very careful when = clicking links or opening attachments. See the URL nok.it/ext for addit= ional information.

=C2=A0

Hi Gunter,

=C2=A0

Thanks for your review.

=C2=A0

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

Gu= nter 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-ballot-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/



----------------------------------------------------------------------
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 Vi= shnu
Pavan Beeram for the Shepherd write-up.

Please find below 1 blocking DISCUSS about the yang node names used, that s= eems
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 abbrev= iate
in the yang model, assuming the node names are not overly long and it makes=
reading and understanding the leafs more trivial.

=C2=A0

Dhruv: The complaint that we = get with longer names is that the leafref paths become too long and lose human=C2=A0readability.=C2=A0

=C2=A0

=C2=A0 +--rw virtual-network
=C2=A0=C2=A0=C2=A0=C2=A0 +--r=
w vn* [vn-id]
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 +--rw vn-id=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 vn=
-id
=C2=A0

=C2=A0

p=
ath "/virtual-network/vn/vn-id"; will become


p=
ath "/virtual-network/virtual-network/virtual-network-identifier"=
;

=C2=A0

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 w= ith this YANG file.=C2=A0<= /p>

=C2=A0

Hope this explains our thinki= ng, does it make sense to you?=C2=A0<= /u>

=C2=A0

Thanks,

Dhruv

=C2=A0

=C2=A0

--000000000000275982061a4ee3f0--