[Teas] Gunter Van de Velde's Abstain on draft-ietf-teas-actn-vn-yang-27: (with COMMENT)

Gunter Van de Velde via Datatracker <noreply@ietf.org> Sat, 08 June 2024 08:10 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4D2C14F6A9; Sat, 8 Jun 2024 01:10:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Gunter Van de Velde via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171783423036.33553.6975322185327764538@ietfa.amsl.com>
Date: Sat, 08 Jun 2024 01:10:30 -0700
Message-ID-Hash: COXGKWTYK4LUTWCYEIB24KBPBSU45UTJ
X-Message-ID-Hash: COXGKWTYK4LUTWCYEIB24KBPBSU45UTJ
X-MailFrom: noreply@ietf.org
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: draft-ietf-teas-actn-vn-yang@ietf.org, teas-chairs@ietf.org, teas@ietf.org, vbeeram@juniper.net
X-Mailman-Version: 3.3.9rc4
Reply-To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Subject: [Teas] Gunter Van de Velde's Abstain on draft-ietf-teas-actn-vn-yang-27: (with COMMENT)
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/Jv6aFBz7OGm3xQI89EDpHxYWbTg>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

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

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# 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 one non-blocking ABSTAIN regarding the YANG node names used.
While this should be relatively straightforward to address, it will involve
quite a bit of effort to correct the node names throughout all instances.

#ABSTAIN items
#=============
##(resolved) ABSTAIN1
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 acronyms. e.g. vn, vn-id, src, src-vn-ap.id, etc

Agreed with Dhruv (author): abbreviations will be expanded upon in descriptions
as the abbreviations used are well known in TEAS area.

##ABSTAIN2
Using full/fragments of parent-node names in sibling-node names is something
that netmod has recommendations against.

Reference:
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-20#section-4.3.1

“
   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.
“

Note: Originally these were blocking DISCUSS, however using non-recommended
yang node names, is not one of the agreed reasons to have a discuss
https://datatracker.ietf.org/doc/statement-iesg-discuss-criteria-in-iesg-review-20140507/

The yang tree documented can be implemented and will interop. Hence i moved the
original blocking DISCUSS to a non-blocking ABSTAIN position with following
meaning: "I oppose this document but understand that others differ and am not
going to stand in the way of the others."