Subject: Re: [OPSAWG] Device profile in draft-shytyi-opsawg-vysm and YANG packages

From: Dmytro Shytyi <[email-masked]>
Date: Mon, 18 May 2020 20:59:57 +0200

Hello Rob,

Sorry for late response.
Thank you for your comment.
Indeed this document seems to be very interesting! (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/)

After reading the "https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/", as you mentioned, it seems like current version of "netmod-yang-packages" does not describe the schema mounts.

Maybe in this case we could consider multiple points:

- If I understood correctly, one of the possible solutions is:  adding to each module in the package the "mountpoint" field.

- When we have augmentation statement in the YANG module maybe we should add it to the "mountpoint" field too.

- For import-only packages maybe it is a good idea to add an array mount point with two elements: "pakage_name-where-module-that-is-augmented-located" and "augmentation_path-to-module".

I.E. when we have:

       module m_A - initial module     

      module m_B - module augments module m_A.
      package p_A- package where module m_A is located .

      package p_B- package where is located a module m_B that augments m_A.

We will have in the package p_B for module m_B mountpoint with two elements: " p_A" and "augmentation_path-inside-module-m_A".

Indeed it could be interesting to build a package definition for a uCPE profile.

______________
Dmytro SHYTYI

---- On Thu, 16 Apr 2020 12:44:15 +0200 Rob Wilton (rwilton) <mailto:[email-masked]> wrote ----

Hi,

This document seems to define a device profile for a uCPE devices (e.g. section 5 lists a set of YANG modules), along with a YANG module defining some extra properties for an LNE.

I didn’t know whether you are aware of the work in NETMOD for defining YANG packages (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/), but
 it might be interesting to see what a package definition for a uCPE profile looks like.

One area that would need to be investigated is the use of schema mounts.  I.e. for the package definition to be useful and correct it, the package definition may need to be extended to specify that some modules are mounted at particular
 points in the schema (rather than at the root).

Regards,
 Rob

[As an individual contributor]

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 19 May 2020 17:00:58 +0000

cross posting to NETMOD as well

From: Rob Wilton (rwilton) <[email-masked]>
Sent: Thursday, April 16, 2020 6:44 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Device profile in draft-shytyi-opsawg-vysm and YANG packages

Hi,

I didn't know whether you are aware of the work in NETMOD for defining YANG packages (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/), but it might be interesting to see what a package definition for a uCPE profile looks like.

One area that would need to be investigated is the use of schema mounts.  I.e. for the package definition to be useful and correct it, the package definition may need to be extended to specify that some modules are mounted at particular points in the schema (rather than at the root).

Regards,
Rob

---

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Tue, 19 May 2020 17:01:15 +0000

+NETMOD

> -----Original Message-----
> From: Dmytro Shytyi <[email-masked]>
> Sent: Monday, May 18, 2020 3:00 PM
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-netmod-
> [email-masked]
> Subject: Re: Device profile in draft-shytyi-opsawg-vysm and YANG packages
> 
> Hello Rob,
> 
> 
> 
> Sorry for late response.
> Indeed this document seems to be very interesting!
> (https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/)
> 
> 
> 
> 
> After reading the "https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-
> packages/", as you mentioned, it seems like current version of "netmod-yang-
> packages" does not describe the schema mounts.
> 
> 
> 
> - If I understood correctly, one of the possible solutions is:  adding to each
> module in the package the "mountpoint" field.
> 
> - When we have augmentation statement in the YANG module maybe we
> should add it to the "mountpoint" field too.
> 
> - For import-only packages maybe it is a good idea to add an array mount point
> with two elements: "pakage_name-where-module-that-is-augmented-located"
> and "augmentation_path-to-module".
> 
> I.E. when we have:
> 
>       module m_B - module augments module m_A