Subject: Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

From: Young Lee <[email-masked]>
Date: Tue, 2 Jul 2019 14:49:35 +0000

Hi Tom,

Thanks for your comments. My apology for a delayed response. Please see inline for my comment.

Thanks.

Young

-----Original Message-----

From: tom petch [mailto:[email-masked]]

Sent: Thursday, June 20, 2019 11:25 AM

To: Young Lee <[email-masked]>; [email-masked]

Subject: Re: [Teas] FW: I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

----- Original Message -----

From: "Young Lee" <[email-masked]>

To: <[email-masked]>

Sent: Friday, June 14, 2019 7:44 PM

> Hi WG,

> The changes for this revision are as follows:

> - Added in Introduction Section on how the VN model can support 5G

transport context.

> - in Section 3.2: case 2 --- clarified how VN model is used along with

TE-topo Connectivity matrices construct and added a paragraph to introduce the JSON example of the models (in Section 7)

> - For YANG model: converted "ltp" from configurable parameter to

leafref type; added references for imported modules.

> - Editorial: affiliation changes for a co-author; Compliant with five

front page authors' list.

As I said of -03, rather short on references and some that are seem wrong.

Look, for example, at

draft-ietf-pim-igmp-mld-yang-15.

to see the sort of level of reference that a YANG module benefits from.

YL>> It will be good to be specific on which references are wrong and what needs to be added.

Several of the existing references should be Normative, according to YANG Guidelines.

YL>> Again, can you point which ones you think Normative?

You have

       import ietf-te-types { prefix "te-types";

           reference"I-D.ietf-teas-yang-te-types: Traffic Engineering

but in the list of prefixes, always a good thing to have, is

      | te-types| ietf-te-types  | [TE-Tunnel]     |

while the I-D References has

   [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic

             Engineering Tunnels and Interfaces", work in progress:

             draft-ietf-teas-yang-te.

which looks like a mismatch.

YL>> Yes, you're right. The reference should be TE-type as TE-type was separated out from TE-tunnel model. Will correct this in the revision.

VN is expanded in the text but I think needs expanding in the Title of the I-D and in the YANG module; others need expanding on first use; L3SM,  L2SM  and L1CSM

YL>> OK. Agreed.

And I think you should provide a reference for VN up front, something along the lines of "For more information on Virtual Networks, see [RFC8453]"

in the Introduction, first paragraph. (I don't think that RFC8453 is a brilliant reference for VN but I cannot find a better one).

YL>> Agree. Will add the VN reference up front.

Tom Petch

> Thanks.

> Young & Dhruv

> -----Original Message-----

> From: Teas [mailto:[email-masked]] On Behalf Of

[email-masked]

> Sent: Friday, June 14, 2019 1:28 PM

> To: [email-masked]

> Cc: [email-masked]

> Subject: [Teas] I-D Action: draft-ietf-teas-actn-vn-yang-05.txt

> A New Internet-Draft is available from the on-line Internet-Drafts

directories.

> This draft is a work item of the Traffic Engineering Architecture and

Signaling WG of the IETF.

>         Title           : A Yang Data Model for VN Operation

>         Authors         : Young Lee

>                           Dhruv Dhody

>                           Daniele Ceccarelli

>                           Igor Bryskin

>                           Bin Yeong Yoon

> Filename        : draft-ietf-teas-actn-vn-yang-05.txt

> Pages           : 56

> Date            : 2019-06-14

> Abstract:

>    This document provides a YANG data model generally applicable to

any

>    mode of Virtual Network (VN) operation.

---

From: tom petch <[email-masked]>
Date: Wed, 3 Jul 2019 10:12:16 +0000

Top posting about references, lack of.  You could do worse than use
teas-yang-te-topo as an exemplar for when to include references..

YANG should have a reference in Introduction, probably RFC7950,
Normative

In the YANG module, which will get extracted and so has to make sense on
its own, without the rest of the RFC-to-be

       feature multi-src-dest {
A good general principle is that any optional feature should have a
reference where I can see what it adds that is not in the base model.

the identity derived from
        identity vn-compute-state-type {
I would like to learn more about - what happens when a compute fails,
what happens while it is in progress?

      typedef vn-disjointness {
what is it? (I see no mention of disjoint in RFC8453)

      "VNAP related information";
perhaps a reference to RFC8453 s.6

      "Reference LTP in the TE-topology";
where can I find more about LTP - I see no ltp in RFC8453

       leaf connectivity-matrix-id
could reference te-topo for more information on connectivty-matrices

      "The list of metrics for VN";
te-topo has references for metrics; you could either reference them or
reference te-topo

       "a virtual network is identified by a vn-id";
well yes but I want to know more about id and name, their usage,
constraints thereon and so on; RFC8453 seeme silent on this

Tom Petch

----- Original Message -----
From: "Young Lee" <[email-masked]>
To: "tom petch" <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 02, 2019 3:49 PM

Hi Tom,

Thanks for your comments. My apology for a delayed response. Please see
inline for my comment.

Thanks.

Young

----- Original Message -----

To: <[email-masked]>

transport context.

> - in Section 3.2: case 2 --- clarified how VN model is used along with

TE-topo Connectivity matrices construct and added a paragraph to
introduce the JSON example of the models (in Section 7)

As I said of -03, rather short on references and some that are seem
wrong.

Look, for example, at

YL>> It will be good to be specific on which references are wrong and
what needs to be added.

Several of the existing references should be Normative, according to
YANG Guidelines.

You have

             draft-ietf-teas-yang-te.

YL>> Yes, you're right. The reference should be TE-type as TE-type was
separated out from TE-tunnel model. Will correct this in the revision.

VN is expanded in the text but I think needs expanding in the Title of
the I-D and in the YANG module; others need expanding on first use;
L3SM,  L2SM  and L1CSM

YL>> OK. Agreed.

And I think you should provide a reference for VN up front, something
along the lines of "For more information on Virtual Networks, see
[RFC8453]"

in the Introduction, first paragraph. (I don't think that RFC8453 is a
brilliant reference for VN but I cannot find a better one).

Tom Petch

[email-masked]

directories.

any