Subject: Re: [Teas] WG I-D Status actn-vm

From: Dhruv Dhody <[email-masked]>
Date: Tue, 14 Jul 2020 00:23:46 +0530

Hi Tom,

Apologies for the late reply. I have made an update and handled all your
pending comments! Please have a look -
https://datatracker.ietf.org/doc/draft-ietf-teas-actn-vn-yang/

Thanks!
Dhruv

On Fri, Apr 24, 2020 at 4:03 PM tom petch <[email-masked]> wrote:

> From: Teas <[email-masked]> on behalf of Dhruv Dhody <
> [email-masked]>
> Sent: 22 April 2020 07:37
> To: TEAS WG Chairs; TEAS WG ([email-masked])
> Subject: [Teas] WG I-D Status
>
> Hi Chairs, WG,
>
> Please find the status -
>
> ==
>
> A Yang Data Model for VN Operation (draft-ietf-teas-actn-vn-yang-08)
> Updates:
>   Mainly YANG guidelines update
>   All earlier issues resolved
>
> <tp>
> Looking at -08 I struggle to see a resolution of some of the issues I
> raised 3Jul2019.
>
> YANG deserves a reference in Introduction
>
>
Done!

> YANG should be upper case, not yang
>
>
Done!

> 1,3 places te-types in teas-yang-te
> The module imports it from teas-yang-te-types
>
>
Updated to the RFC 8776

> identity  .. computatione-failed
>
>
Fixed

> disjoint I cannot find in RFC8453 - a reference would be helpful
>
>
I use the te-types typedef instead of defining a new one!

> ltp likewise
Added

> vn-id seems underspecified.  Has it semantics or is it just a number?  Are
> there restrictions on the range?  Many I-D create a raft of YANG types
> which seem to complicate the model - here I wonder if a vn-id  type would
> help.
>
>
Added typedef.

> Tom Petch
>
>
> Next Steps:
>   Yang Doctors Review
>
> ==
>
> YANG models for VN/TE Performance Monitoring Telemetry and Scaling
> Intent Autonomics (draft-ietf-teas-actn-pm-telemetry-autonomics-02)
> Updates:
>   Mainly YANG guidelines update
> Next Step:
>   Solicit more reviews
>
> ==
>
> Traffic Engineering (TE) and Service Mapping Yang Model
> (draft-ietf-teas-te-service-mapping-yang-03)
> Updates:
>   Mapping to Network Yang Models added (L3NM and L2NM)
>   YANG guidelines update
> Question to the WG:
>   Is this the right place to include mapping to the network model as well?
>
> ==
>
> Thanks!
> Dhruv
>
> _______________________________________________
> Teas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teas
>

---

From: tom petch <[email-masked]>
Date: Wed, 15 Jul 2020 10:02:08 +0000

From: Dhruv Dhody <[email-masked]>
Sent: 13 July 2020 19:53
Hi Tom,

Apologies for the late reply. I have made an update and handled all your pending comments! Please have a look - https://datatracker.ietf.org/doc/draft-ietf-teas-actn-vn-yang/

<tp>
Getting there.  I had not realised how much this leant on te-topo but now I am more familiar with the latter I find myself in less need of references but suspect that others will find them useful.  I note that there is a -24 for yang-te - I do not know what has changed.

A general comment.  A much used and useful convention is that a list is plural and content singular so rather than 
list vn-ap
uses vn-ap
you could have 
list vn-aps
uses vn-ap
or 
container aps
list ap
container vns
list vn
I realise that other teas I-D use the suffix -list but for me that is clumsier than a simple 's'

s.1.3 has the wrong prefix for te-topo

I find the use of uri for ids interesting; any scheme? any length?  probably worth some advice here given people's predilection for disastrous identifiers:-)
And do you mean datastores, or modules?  I struggle to see how the uri could differ  across datastores.

LTP should be expanded in the YANG even if I do now recognise it.  It has a different meaning in other technologies.

IANA /TDB/TBD/ !

Tom Petch
Thanks!
Dhruv

On Fri, Apr 24, 2020 at 4:03 PM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Teas <[email-masked]<mailto:[email-masked]>> on behalf of Dhruv Dhody <[email-masked]<mailto:[email-masked]>>
Sent: 22 April 2020 07:37
To: TEAS WG Chairs; TEAS WG ([email-masked]<mailto:[email-masked]>)
Subject: [Teas] WG I-D Status

Hi Chairs, WG,

Please find the status -

==

<tp>
Looking at -08 I struggle to see a resolution of some of the issues I raised 3Jul2019.

Done!

Done!

Updated to the RFC 8776

Fixed

ltp likewise

Added

vn-id seems underspecified.  Has it semantics or is it just a number?  Are there restrictions on the range?  Many I-D create a raft of YANG types
which seem to complicate the model - here I wonder if a vn-id  type would help.

Added typedef.

Tom Petch

Next Steps:
  Yang Doctors Review

==

==

==

Thanks!
Dhruv

_______________________________________________
Teas mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/teas

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 15 Jul 2020 16:01:09 +0530

Hi Tom,

Thanks for keeping us on our toes :)
I will consider these in the next update.

Regarding uri, I was influenced by RFC 8345 and thought it made sense
here as well (with my reading being the datastore to be related to
NMDA). I will get that confirmed.

Thanks!
Dhruv

---

From: tom petch <[email-masked]>
Date: Thu, 16 Jul 2020 10:34:38 +0000

Sent: 15 July 2020 11:31

Hi Tom,

<tp>
I see what you mean about RFC8345.  I do not understand what it says either and disagree strongly with its recommendation to embody semantics, a regular source of grief.

uri does cover a lot, dozens of schemes, complex syntax multiple elements, plenty of scope for poor choices.  YANG does not even restrict the length which SMI does.  I have not seen it used much, rather string gets used without restriction.

Tom Petch
Thanks!
Dhruv