A YANG Data Model for Virtual Network (VN) Operations
draft-ietf-teas-actn-vn-yang-29

I have removed my discuss on this draft.  I do think that the standard template for these documents should be updated as the language doesn't match/model/resemble other Security Consideration sections.

Thanks for the consideration (and education).

Nit:  Section 1, para 6:  MSDC should be MDSC.

Thanks for the work done in this document. The domain is quite complex and renders the model also complex...

Just a minor regret: the examples are only with IPv4 addresses...

# 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 historical ABSTAIN AD review comments with information how the document editor team quickly worked to resolve these abstain observations.

#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

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

##[resolved] 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

##[Resolution] Authors updated the model to align with netmod recommendations

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"?

Thank you to Behcet Sarikaya for the GENART review.

Thank you for the work on this document.

Only one comment on my side: given that RFC 7926, 8309 and 8453 key terms are used, they should be normative references of this doc. In particular RFC 8453, which I was surprised to see as informative. The other two might be bypassed by reporting the must-understand concepts into this document directly.

Note to the IESG: if these ref are moved to normative (as they should) 2/3 are informational and were not Last Called.

Thanks for working on this specification.