[Teas] Mahesh Jethanandani's No Objection on draft-ietf-teas-actn-vn-yang-26: (with COMMENT)

Mahesh Jethanandani via Datatracker <noreply@ietf.org> Thu, 06 June 2024 01:27 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 710F8C1782B5; Wed, 5 Jun 2024 18:27:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Mahesh Jethanandani via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.14.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171763724944.20645.7859164476586035283@ietfa.amsl.com>
Date: Wed, 05 Jun 2024 18:27:29 -0700
Message-ID-Hash: BWYS2CS3V53SV4J4VBRYI2FP4NHAFPPR
X-Message-ID-Hash: BWYS2CS3V53SV4J4VBRYI2FP4NHAFPPR
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: Mahesh Jethanandani <mjethanandani@gmail.com>
Subject: [Teas] Mahesh Jethanandani's No Objection on draft-ietf-teas-actn-vn-yang-26: (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/ICl5XcrJkXxJrd7VFnxD3S9KhsQ>
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>

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-teas-actn-vn-yang-26: No Objection

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:
----------------------------------------------------------------------

Section 1, paragraph 11
>    The VN operational state is included in the same tree as the
>    configuration consistent with Network Management Datastore
>    Architecture (NMDA) [RFC8342].  The origin of the data is indicated
>    as per the origin metadata annotation.

The last statement is not clear to me. What "data" is being referred to? What
is "origin metadata annotation"?

Section 1.1, paragraph 1
>    Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used
>    in this document.

I support Francesca's comment here. In addition, I expect the document to
highlight which key terms in this document are being "imported" from the other
documents. More than that, what would be helpful would be have a table that
contains a list of acronyms used in the document.

Section 4.3.3, paragraph 3
>    Note that the YANG model is tightly coupled with the TE Topology
>    model [RFC8795].  Any underlay technology not supported by [RFC8795]
>    is also not supported by this model.  The model does include an empty
>    container called "underlay" that can be augmented.  For example the
>    SR-policy information can be augmented for the SR underlay by a
>    future model.

Based on the first sentence, it is clear that this is not a generic Virtual
Network YANG model. Why then call it that? Why not call it a TE Virtual Network
YANG model, and leave room for someone to define a generic VN model?

Section 6, paragraph 30
>      grouping vn-ap {

I see a single uses statement for this grouping. Is this grouping expected to
be used by other modules? If not, why not inline the grouping where it is being
used?

Section 6, paragraph 30
>      grouping access-point {

Similar comment here. I see a single uses statement for this grouping. If this
grouping is not expected to be used by other modules, why not inline the
grouping where it is being used?

Section 6, paragraph 30
>          leaf multi-src {
>            if-feature "multi-src-dest";
>            type boolean;
>            default "false";
>            description
>              "Is the source part of multi-source, where
>               only one of the source is enabled";
>          }

Is there no requirement to know what are the other sources? As structured, if
this boolean is true, only one source can be stored as part of the module.
Which of the multiple 'src' will be stored in 'leaf src'? In other words should
'container src' not contain a 'list src' with 'src', 'src-vn-ap-id' as members
of the list?

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 10
>  that, what would be helpful would be have a table that contains a list of ac
>                                    ^^^^^^^
Consider using only "have" or the present participle "be having".

Section 1.3, paragraph 4
> inks, intra-domain | paths, and inter- domain links. If we were to create a V
>                                 ^^^^^^^^^^^^^
This word seems to be formatted incorrectly. Consider fixing the spacing or
removing the hyphen completely.

Section 2.1, paragraph 7
> ogies (a single node topology AN1 and a underlay topology (with nodes S1 to S
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3.2, paragraph 12
>  in the [RFC8454]. It also allows to group the set of edge-to-edge links (i.e
>                                   ^^^^^^^^
Did you mean "grouping"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 4.3.1, paragraph 2
> y is used to convey the result of the each VN member as a reference to the c
>                                   ^^^^^^^^
Two determiners in a row. Choose either "the" or "each".

Section 4.3.1, paragraph 15
> set by customer, making for a simplified operations for the customer. - VN Ty
>                             ^^^^^^^^^^^^^^^^^^^^^^^
The plural noun "operations" cannot be used with the article "a". Did you mean
"a simplified operation" or "simplified operations"?