Re: [onap-discuss] YANG.XML format
+Eden,Zahi BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development * NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago *** Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: CHAPNICK, AVI Sent: Saturday, July 08, 2017 11:05 AM To: TIMONEY, DAN <dt5...@att.com>; Rozin, Eden <er4...@intl.att.com>; Thomas Nadeau <thomas.nad...@amdocs.com>; FREEMAN, BRIAN D <bf1...@att.com>; NOSHPITZ, CLAUDE <cn5...@att.com>; Lando,Michael <ml6...@intl.att.com>; Kedar Ambekar <ake...@techmahindra.com> Cc: WRIGHT, STEVEN A <sw3...@att.com>; onap-discuss@lists.onap.org Subject: RE: [onap-discuss] YANG.XML format Hi, Some of the questions below refers to SDNC managed devices YANG schemas , which ODL gets from the devices once the device is mounted. Are we planning to allow getting customized version of those schemas from SDC for allowing fixing problems on the managed devices yang? Some of the answers referred to the yang models which are being used to define SDNC NB interfaces (Service RPC+ data model + storage schema) As Dan explained today these are required in compile time and for that there is no sense of getting in runtime via SDC. In APPC we do allow getting YANG schema from SDC in runtime , we are using these to define the structure and the storage schema of the specific VNF APPC Is managing. Loading NB yang schema dynamically to ODL is tricky , mainly as ODL is not providing API for that and forces you to upload a synthetic OSGI bundle with yang schema embedded. I have started the engagement with ODL community for adding this support while back , if SDNC has the same interest (which makes a lot of sense to me.) maybe its good time to revive this discussion. Avi, From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of TIMONEY, DAN Sent: Saturday, July 8, 2017 4:03 AM To: ROZIN, EDEN <er4...@intl.att.com<mailto:er4...@intl.att.com>>; Thomas Nadeau <thomas.nad...@amdocs.com<mailto:thomas.nad...@amdocs.com>>; FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>>; NOSHPITZ, CLAUDE <cn5...@att.com<mailto:cn5...@att.com>>; LANDO, MICHAEL <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>; Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>> Cc: WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format All, The YANG.XML artifact type name is perhaps a bit confusing. The actual artifact itself is in XML format. The YANG.XML designation indicates that the structure of the file is defined by a Yang model. The Yang model itself isn't distributed by SDC. In the case of SDNC, we need to have the Yang model available to us at compile time so that we can use it to generate the code to parse XML files defined by that model. So, right now there really wouldn't be much use at least to SDNC in distribution of the Yang model itself via SDC. In the longer term, though, we are looking into being able to handle Yang models more dynamically. So when we get that working, we may very well be very interested in receiving Yang models from SDC. But that would not be in scope for release 1. Hope this helps, Dan Sent from MyOwn, an AT BYOD solution. From: "ROZIN, EDEN" <er4...@intl.att.com<mailto:er4...@intl.att.com>> Date: Thursday, July 6, 2017 at 12:50:05 PM To: "Thomas Nadeau" <thomas.nad...@amdocs.com<mailto:thomas.nad...@amdocs.com>>, "FREEMAN, BRIAN D" <bf1...@att.com<mailto:bf1...@att.com>>, "NOSHPITZ, CLAUDE" <cn5...@att.com<mailto:cn5...@att.com>>, "LANDO, MICHAEL" <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>, "Kedar Ambekar" <ake...@techmahindra.com<mailto:ake...@techmahindra.com>> Cc: "WRIGHT, STEVEN A" <sw3...@att.com<mailto:sw3...@att.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. The artifacts types are configurable, so there is a way to add 'YANG' as another type for artifacts upload. All the artifacts are located inside the distributed CSAR that contain all the relevant Service information. If SDN-C would like to get the artifacts, they can.
Re: [onap-discuss] YANG.XML format
Hi, Some of the questions below refers to SDNC managed devices YANG schemas , which ODL gets from the devices once the device is mounted. Are we planning to allow getting customized version of those schemas from SDC for allowing fixing problems on the managed devices yang? Some of the answers referred to the yang models which are being used to define SDNC NB interfaces (Service RPC+ data model + storage schema) As Dan explained today these are required in compile time and for that there is no sense of getting in runtime via SDC. In APPC we do allow getting YANG schema from SDC in runtime , we are using these to define the structure and the storage schema of the specific VNF APPC Is managing. Loading NB yang schema dynamically to ODL is tricky , mainly as ODL is not providing API for that and forces you to upload a synthetic OSGI bundle with yang schema embedded. I have started the engagement with ODL community for adding this support while back , if SDNC has the same interest (which makes a lot of sense to me.) maybe its good time to revive this discussion. Avi, From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of TIMONEY, DAN Sent: Saturday, July 8, 2017 4:03 AM To: ROZIN, EDEN <er4...@intl.att.com>; Thomas Nadeau <thomas.nad...@amdocs.com>; FREEMAN, BRIAN D <bf1...@att.com>; NOSHPITZ, CLAUDE <cn5...@att.com>; LANDO, MICHAEL <ml6...@intl.att.com>; Kedar Ambekar <ake...@techmahindra.com> Cc: WRIGHT, STEVEN A <sw3...@att.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format All, The YANG.XML artifact type name is perhaps a bit confusing. The actual artifact itself is in XML format. The YANG.XML designation indicates that the structure of the file is defined by a Yang model. The Yang model itself isn't distributed by SDC. In the case of SDNC, we need to have the Yang model available to us at compile time so that we can use it to generate the code to parse XML files defined by that model. So, right now there really wouldn't be much use at least to SDNC in distribution of the Yang model itself via SDC. In the longer term, though, we are looking into being able to handle Yang models more dynamically. So when we get that working, we may very well be very interested in receiving Yang models from SDC. But that would not be in scope for release 1. Hope this helps, Dan Sent from MyOwn, an AT BYOD solution. From: "ROZIN, EDEN" <er4...@intl.att.com<mailto:er4...@intl.att.com>> Date: Thursday, July 6, 2017 at 12:50:05 PM To: "Thomas Nadeau" <thomas.nad...@amdocs.com<mailto:thomas.nad...@amdocs.com>>, "FREEMAN, BRIAN D" <bf1...@att.com<mailto:bf1...@att.com>>, "NOSHPITZ, CLAUDE" <cn5...@att.com<mailto:cn5...@att.com>>, "LANDO, MICHAEL" <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>, "Kedar Ambekar" <ake...@techmahindra.com<mailto:ake...@techmahindra.com>> Cc: "WRIGHT, STEVEN A" <sw3...@att.com<mailto:sw3...@att.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. The artifacts types are configurable, so there is a way to add 'YANG' as another type for artifacts upload. All the artifacts are located inside the distributed CSAR that contain all the relevant Service information. If SDN-C would like to get the artifacts, they can. Eden From: Thomas Nadeau [mailto:thomas.nad...@amdocs.com] Sent: Thursday, July 06, 2017 12:26 AM To: FREEMAN, BRIAN D <bf1...@att.com<mailto:bf1...@att.com>>; NOSHPITZ, CLAUDE <cn5...@att.com<mailto:cn5...@att.com>>; Lando,Michael <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>; Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>; Rozin, Eden <er4...@intl.att.com<mailto:er4...@intl.att.com>> Cc: WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: RE: [onap-discuss] YANG.XML format +1 While I'd love for all the new features in 1.1 to be available, the bottom line is as Brian said: actual production device support which in my estimation will take a bit longer. --Tom From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FREEMAN, BRIAN D Sent: Wednesday, July 5, 2017 4:12 PM To: NOSHPITZ, CLAUDE <cn5...@att.com<mailto:cn5...@att.com>>; LANDO, MICHAEL <ml
Re: [onap-discuss] YANG.XML format
Hi, Referring to Kedar’s question below, Can you please clarify the use case where the VNF vendor will push the Yang file through SDC to SDNC, rather than using the NetConf interface (assuming the VNF vendor supports NetConf interface) available in SDN-C . Is the requirement mentioned below is for preloading the Yang files in SDN-C cache without using the NetConf native mechanism of get-schema ? Is there any capability in SDN-C which can receive Yang files (.yang and not .xml) and use that for generating custom DG actions ? Thanks Manoj [https://www.netcracker.com/assets/img/netcracker-social-final.png] ƕ From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Thomas Nadeau Sent: Thursday, July 06, 2017 2:56 AM To: FREEMAN, BRIAN D; NOSHPITZ, CLAUDE; LANDO, MICHAEL; Kedar Ambekar; ROZIN, EDEN Cc: WRIGHT, STEVEN A; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format +1 While I’d love for all the new features in 1.1 to be available, the bottom line is as Brian said: actual production device support which in my estimation will take a bit longer. --Tom From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FREEMAN, BRIAN D Sent: Wednesday, July 5, 2017 4:12 PM To: NOSHPITZ, CLAUDE <cn5...@att.com>; LANDO, MICHAEL <ml6...@intl.att.com>; Kedar Ambekar <ake...@techmahindra.com>; ROZIN, EDEN <er4...@intl.att.com> Cc: WRIGHT, STEVEN A <sw3...@att.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format The industry is still on yang 1.0 so I would focus on that version for now. Yang 1.1 is emerging and ODL Carbon has limited support for it but its very new. I only know of one device that supposedly supports yang 1.1. Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of NOSHPITZ, CLAUDE Sent: Wednesday, July 05, 2017 4:08 PM To: LANDO, MICHAEL <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>; Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>; ROZIN, EDEN <er4...@intl.att.com<mailto:er4...@intl.att.com>> Cc: WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Is there a normative set of RFCs/standards that we plan to adhere to for the YANG work in ONAP? I’m asking as an observer (without specific YANG expertise :-) wanting to make sure we pave the way for a coherent developer experience moving forward. The ONAP Wiki references RFC 6020<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6020.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=RrxQS3rYr0AtdSaucYzM1p0Ywlc_r0QmOL64pUO2GLI=> (YANG 1.0) -- is this superseded (?) by RFC 7950<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6991.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=MamwuVtlJ_7ueE9d6KuMZU34GCLcgJoUnEv0zgFIssA=> (YANG 1.1)? And then there’s the JSON encoding proposed in RFC 7951<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7951=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4xEpN-BrZSWWL8xoZm6LLvdvnaSJP4ociN7TpUFL5FI=>. It would be useful to consolidate around a consistent representation, given that different toolchains/consumers may need to interoperate. Is there a need to reference the various core data models (RFCs 6991<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6991=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4QRzzK-sxY3vek1cqPt9QdXpE8le474yarm_TT84zu0=>, 7223<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7223.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=1ZORtyRTKrCMEFOfGCOju2loc02tKIslNz2bkiBe63Y=>, 7317<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7317.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=pPHmyk2Y0FvxM9Ubaqkn89dmpYX-reOexeGv6nKMdhM=>, and all their friends), or is their use otherwise clearly implied? There was discussion along these lines in the “VNF Management Requirements for OpenECOMP” document<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Reference-2BDocuments-3Fpreview-3D-252F1015849-252F1017888-252FVNF-2BManagement-2BRe
Re: [onap-discuss] YANG.XML format
+1 While I’d love for all the new features in 1.1 to be available, the bottom line is as Brian said: actual production device support which in my estimation will take a bit longer. --Tom From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of FREEMAN, BRIAN D Sent: Wednesday, July 5, 2017 4:12 PM To: NOSHPITZ, CLAUDE <cn5...@att.com>; LANDO, MICHAEL <ml6...@intl.att.com>; Kedar Ambekar <ake...@techmahindra.com>; ROZIN, EDEN <er4...@intl.att.com> Cc: WRIGHT, STEVEN A <sw3...@att.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format The industry is still on yang 1.0 so I would focus on that version for now. Yang 1.1 is emerging and ODL Carbon has limited support for it but its very new. I only know of one device that supposedly supports yang 1.1. Brian From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of NOSHPITZ, CLAUDE Sent: Wednesday, July 05, 2017 4:08 PM To: LANDO, MICHAEL <ml6...@intl.att.com<mailto:ml6...@intl.att.com>>; Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>; ROZIN, EDEN <er4...@intl.att.com<mailto:er4...@intl.att.com>> Cc: WRIGHT, STEVEN A <sw3...@att.com<mailto:sw3...@att.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Is there a normative set of RFCs/standards that we plan to adhere to for the YANG work in ONAP? I’m asking as an observer (without specific YANG expertise :-) wanting to make sure we pave the way for a coherent developer experience moving forward. The ONAP Wiki references RFC 6020<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6020.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=RrxQS3rYr0AtdSaucYzM1p0Ywlc_r0QmOL64pUO2GLI=> (YANG 1.0) -- is this superseded (?) by RFC 7950<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6991.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=MamwuVtlJ_7ueE9d6KuMZU34GCLcgJoUnEv0zgFIssA=> (YANG 1.1)? And then there’s the JSON encoding proposed in RFC 7951<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7951=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4xEpN-BrZSWWL8xoZm6LLvdvnaSJP4ociN7TpUFL5FI=>. It would be useful to consolidate around a consistent representation, given that different toolchains/consumers may need to interoperate. Is there a need to reference the various core data models (RFCs 6991<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6991=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4QRzzK-sxY3vek1cqPt9QdXpE8le474yarm_TT84zu0=>, 7223<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7223.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=1ZORtyRTKrCMEFOfGCOju2loc02tKIslNz2bkiBe63Y=>, 7317<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7317.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=pPHmyk2Y0FvxM9Ubaqkn89dmpYX-reOexeGv6nKMdhM=>, and all their friends), or is their use otherwise clearly implied? There was discussion along these lines in the “VNF Management Requirements for OpenECOMP” document<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Reference-2BDocuments-3Fpreview-3D-252F1015849-252F1017888-252FVNF-2BManagement-2BRequirements-2Bfor-2BOpenECOMP.pdf=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=_eTL0pDKKxFtg2kDy6IvwGjgoKdsfMZ9Xb7y9xOsnvs=>, which is seeded into the VNF Requirements project. Maybe the questions I’m asking (and those that Kedar posed previously) just ought to be referred to that workstream… Thanks! --Claude From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of "LANDO, MICHAEL" <ml6...@intl.att.com<mailto:ml6...@intl.att.com>> Date: Wednesday, July 5, 2017 at 11:09 AM To: Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>, "ROZIN, EDEN" <er4...@intl.att.com<mailto:er4...@intl.att.com&g
Re: [onap-discuss] YANG.XML format
+1, support for Yang 1.1 was added in ODL Carbon, but that is still on the initial release so take it for what it is worth for the time being. It will be hardened over time. Regards, Ryan Goulding On Wed, Jul 5, 2017 at 4:11 PM, FREEMAN, BRIAN D <bf1...@att.com> wrote: > The industry is still on yang 1.0 so I would focus on that version for now. > > > > Yang 1.1 is emerging and ODL Carbon has limited support for it but its > very new. I only know of one device that supposedly supports yang 1.1. > > > > Brian > > > > > > *From:* onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-bounces@ > lists.onap.org] *On Behalf Of *NOSHPITZ, CLAUDE > *Sent:* Wednesday, July 05, 2017 4:08 PM > *To:* LANDO, MICHAEL <ml6...@intl.att.com>; Kedar Ambekar > <ake...@techmahindra.com>; ROZIN, EDEN <er4...@intl.att.com> > *Cc:* WRIGHT, STEVEN A <sw3...@att.com>; onap-discuss@lists.onap.org > *Subject:* Re: [onap-discuss] YANG.XML format > > > > Security Advisory:* This Message Originated Outside of AT *** > > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > Is there a normative set of RFCs/standards that we plan to adhere to for > the YANG work in ONAP? > > I’m asking as an observer (without specific YANG expertise :-) wanting to > make sure we pave the way for a coherent developer experience moving > forward. > > > > The ONAP Wiki references RFC 6020 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6020.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=RrxQS3rYr0AtdSaucYzM1p0Ywlc_r0QmOL64pUO2GLI=> > (YANG 1.0) -- is this superseded (?) by RFC 7950 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6991.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=MamwuVtlJ_7ueE9d6KuMZU34GCLcgJoUnEv0zgFIssA=> > (YANG 1.1)? > > > > And then there’s the JSON encoding proposed in RFC 7951 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7951=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4xEpN-BrZSWWL8xoZm6LLvdvnaSJP4ociN7TpUFL5FI=>. > It would be useful to consolidate around a consistent representation, given > that different toolchains/consumers may need to interoperate. > > > > Is there a need to reference the various core data models (RFCs 6991 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6991=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4QRzzK-sxY3vek1cqPt9QdXpE8le474yarm_TT84zu0=>, > 7223 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7223.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=1ZORtyRTKrCMEFOfGCOju2loc02tKIslNz2bkiBe63Y=>, > 7317 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7317.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=pPHmyk2Y0FvxM9Ubaqkn89dmpYX-reOexeGv6nKMdhM=>, > and all their friends), or is their use otherwise clearly implied? > > > > There was discussion along these lines in the “VNF Management > Requirements for OpenECOMP” document > <https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Reference-2BDocuments-3Fpreview-3D-252F1015849-252F1017888-252FVNF-2BManagement-2BRequirements-2Bfor-2BOpenECOMP.pdf=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=_eTL0pDKKxFtg2kDy6IvwGjgoKdsfMZ9Xb7y9xOsnvs=>, > which is seeded into the VNF Requirements project. Maybe the questions I’m > asking (and those that Kedar posed previously) just ought to be referred to > that workstream… > > > > Thanks! > > > > --Claude > > > > > > *From: *<onap-discuss-boun...@lists.onap.org> on behalf of "LANDO, > MICHAEL" <ml6...@intl.att.com> > *Date: *Wednesday, July 5, 2017 at 11:09 AM > *To: *Kedar Ambekar <ake...@techmahindra.com>, " > onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>, "ROZIN, EDEN" > <er4...@intl.att.com> > *Subject: *Re: [onap-discuss] YANG.XML format > > > > Security Advisory:* This Message Originated Outside of AT *** > Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. > > +Edan > > > > > > *BR,* > > > > *Michael Lando* > > Opensource & Frontend Team Lead, SDC > > AT Network Application Development · N
Re: [onap-discuss] YANG.XML format
The industry is still on yang 1.0 so I would focus on that version for now. Yang 1.1 is emerging and ODL Carbon has limited support for it but its very new. I only know of one device that supposedly supports yang 1.1. Brian From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of NOSHPITZ, CLAUDE Sent: Wednesday, July 05, 2017 4:08 PM To: LANDO, MICHAEL <ml6...@intl.att.com>; Kedar Ambekar <ake...@techmahindra.com>; ROZIN, EDEN <er4...@intl.att.com> Cc: WRIGHT, STEVEN A <sw3...@att.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. Is there a normative set of RFCs/standards that we plan to adhere to for the YANG work in ONAP? I’m asking as an observer (without specific YANG expertise :-) wanting to make sure we pave the way for a coherent developer experience moving forward. The ONAP Wiki references RFC 6020<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6020.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=RrxQS3rYr0AtdSaucYzM1p0Ywlc_r0QmOL64pUO2GLI=> (YANG 1.0) -- is this superseded (?) by RFC 7950<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc6991.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=MamwuVtlJ_7ueE9d6KuMZU34GCLcgJoUnEv0zgFIssA=> (YANG 1.1)? And then there’s the JSON encoding proposed in RFC 7951<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7951=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4xEpN-BrZSWWL8xoZm6LLvdvnaSJP4ociN7TpUFL5FI=>. It would be useful to consolidate around a consistent representation, given that different toolchains/consumers may need to interoperate. Is there a need to reference the various core data models (RFCs 6991<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6991=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=4QRzzK-sxY3vek1cqPt9QdXpE8le474yarm_TT84zu0=>, 7223<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7223.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=1ZORtyRTKrCMEFOfGCOju2loc02tKIslNz2bkiBe63Y=>, 7317<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7317.txt=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=pPHmyk2Y0FvxM9Ubaqkn89dmpYX-reOexeGv6nKMdhM=>, and all their friends), or is their use otherwise clearly implied? There was discussion along these lines in the “VNF Management Requirements for OpenECOMP” document<https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.onap.org_display_DW_Reference-2BDocuments-3Fpreview-3D-252F1015849-252F1017888-252FVNF-2BManagement-2BRequirements-2Bfor-2BOpenECOMP.pdf=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=e3d1ehx3DI5AoMgDmi2Fzw=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM=_eTL0pDKKxFtg2kDy6IvwGjgoKdsfMZ9Xb7y9xOsnvs=>, which is seeded into the VNF Requirements project. Maybe the questions I’m asking (and those that Kedar posed previously) just ought to be referred to that workstream… Thanks! --Claude From: <onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org>> on behalf of "LANDO, MICHAEL" <ml6...@intl.att.com<mailto:ml6...@intl.att.com>> Date: Wednesday, July 5, 2017 at 11:09 AM To: Kedar Ambekar <ake...@techmahindra.com<mailto:ake...@techmahindra.com>>, "onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>" <onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org>>, "ROZIN, EDEN" <er4...@intl.att.com<mailto:er4...@intl.att.com>> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. +Edan BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Kedar Ambekar Sent: Thursday, June 08, 2017 4:17 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format Hi Michael,
Re: [onap-discuss] YANG.XML format
Is there a normative set of RFCs/standards that we plan to adhere to for the YANG work in ONAP? I’m asking as an observer (without specific YANG expertise :-) wanting to make sure we pave the way for a coherent developer experience moving forward. The ONAP Wiki references RFC 6020<https://www.rfc-editor.org/rfc/rfc6020.txt> (YANG 1.0) -- is this superseded (?) by RFC 7950<https://www.rfc-editor.org/rfc/rfc6991.txt> (YANG 1.1)? And then there’s the JSON encoding proposed in RFC 7951<https://tools.ietf.org/html/rfc7951>. It would be useful to consolidate around a consistent representation, given that different toolchains/consumers may need to interoperate. Is there a need to reference the various core data models (RFCs 6991<https://tools.ietf.org/html/rfc6991>, 7223<https://www.rfc-editor.org/rfc/rfc7223.txt>, 7317<https://www.rfc-editor.org/rfc/rfc7317.txt>, and all their friends), or is their use otherwise clearly implied? There was discussion along these lines in the “VNF Management Requirements for OpenECOMP” document<https://wiki.onap.org/display/DW/Reference+Documents?preview=%2F1015849%2F1017888%2FVNF+Management+Requirements+for+OpenECOMP.pdf>, which is seeded into the VNF Requirements project. Maybe the questions I’m asking (and those that Kedar posed previously) just ought to be referred to that workstream… Thanks! --Claude From: <onap-discuss-boun...@lists.onap.org> on behalf of "LANDO, MICHAEL" <ml6...@intl.att.com> Date: Wednesday, July 5, 2017 at 11:09 AM To: Kedar Ambekar <ake...@techmahindra.com>, "onap-discuss@lists.onap.org" <onap-discuss@lists.onap.org>, "ROZIN, EDEN" <er4...@intl.att.com> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. +Edan BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Kedar Ambekar Sent: Thursday, June 08, 2017 4:17 AM To: onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format Hi Michael, Couple of questions around YANG. 1. If I have YANG model from VNF Vendor in JSON format, can I use it in SDC ? Or it accepts only in XML format ? 2. Not remember where, but I read that ONAP SDC does not distribute YANG model to SDNC. Is this correct ? 3. If # 2 is correct, can YANG be fed directly to SDNC by invoking any API ? ODL API ? Thank you.. From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Lando,Michael Sent: Monday, June 5, 2017 3:56 AM To: Law, Owen <owen@team.telstra.com<mailto:owen....@team.telstra.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format The current guide line is that the file be a valid xml and that the file ending be.xml. No additional requirements/validations are done for this artifact. BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Law, Owen Sent: Thursday, May 25, 2017 2:35 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-discuss] YANG.XML format Hi ONAPers: There is an option in SDC to add deployment artefacts as part of the service composition – is there a specific guideline on what format is needed for the YANG.XML ? Regards Owen Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=FYvXSElfSmWIXOeZxWIxQysejuz9-TXmaL6uftBh8MY=R--ZI_iRaoBn-HH2hiFLvWRayidFxdhf6JlbghF3HN4=zuxLhU26Z-QENdqYywiQxyoHugmT9np_hi_N4HnJWyQ=> externally http://tim.techmahindra.com/tim/disclaimer.html<h
Re: [onap-discuss] YANG.XML format
+Edan BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Kedar Ambekar Sent: Thursday, June 08, 2017 4:17 AM To: onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format Hi Michael, Couple of questions around YANG. 1. If I have YANG model from VNF Vendor in JSON format, can I use it in SDC ? Or it accepts only in XML format ? 2. Not remember where, but I read that ONAP SDC does not distribute YANG model to SDNC. Is this correct ? 3. If # 2 is correct, can YANG be fed directly to SDNC by invoking any API ? ODL API ? Thank you.. From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Lando,Michael Sent: Monday, June 5, 2017 3:56 AM To: Law, Owen <owen@team.telstra.com<mailto:owen@team.telstra.com>>; onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: Re: [onap-discuss] YANG.XML format The current guide line is that the file be a valid xml and that the file ending be.xml. No additional requirements/validations are done for this artifact. BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Law, Owen Sent: Thursday, May 25, 2017 2:35 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-discuss] YANG.XML format Hi ONAPers: There is an option in SDC to add deployment artefacts as part of the service composition – is there a specific guideline on what format is needed for the YANG.XML ? Regards Owen Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.techmahindra.com_Disclaimer.html=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=FYvXSElfSmWIXOeZxWIxQysejuz9-TXmaL6uftBh8MY=R--ZI_iRaoBn-HH2hiFLvWRayidFxdhf6JlbghF3HN4=zuxLhU26Z-QENdqYywiQxyoHugmT9np_hi_N4HnJWyQ=> externally http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html=DwMGaQ=LFYZ-o9_HUMeMTSQicvjIg=FYvXSElfSmWIXOeZxWIxQysejuz9-TXmaL6uftBh8MY=R--ZI_iRaoBn-HH2hiFLvWRayidFxdhf6JlbghF3HN4=XDy5dphHs4UEWk4Bd5WeR54dPgl9d7QZlpbj6JOwzJ4=> internally within TechMahindra. ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] YANG.XML format
Hi Michael, Couple of questions around YANG. 1. If I have YANG model from VNF Vendor in JSON format, can I use it in SDC ? Or it accepts only in XML format ? 2. Not remember where, but I read that ONAP SDC does not distribute YANG model to SDNC. Is this correct ? 3. If # 2 is correct, can YANG be fed directly to SDNC by invoking any API ? ODL API ? Thank you.. From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Lando,Michael Sent: Monday, June 5, 2017 3:56 AM To: Law, Owen <owen@team.telstra.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] YANG.XML format The current guide line is that the file be a valid xml and that the file ending be.xml. No additional requirements/validations are done for this artifact. BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org<mailto:onap-discuss-boun...@lists.onap.org> [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Law, Owen Sent: Thursday, May 25, 2017 2:35 AM To: onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> Subject: [onap-discuss] YANG.XML format Hi ONAPers: There is an option in SDC to add deployment artefacts as part of the service composition – is there a specific guideline on what format is needed for the YANG.XML ? Regards Owen Disclaimer: This message and the information contained herein is proprietary and confidential and subject to the Tech Mahindra policy statement, you may review the policy at http://www.techmahindra.com/Disclaimer.html <http://www.techmahindra.com/Disclaimer.html> externally http://tim.techmahindra.com/tim/disclaimer.html <http://tim.techmahindra.com/tim/disclaimer.html> internally within TechMahindra. ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
Re: [onap-discuss] YANG.XML format
The current guide line is that the file be a valid xml and that the file ending be.xml. No additional requirements/validations are done for this artifact. BR, Michael Lando Opensource & Frontend Team Lead, SDC AT Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: ml6...@intl.att.com<mailto:ml6...@intl.att.com> From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Law, Owen Sent: Thursday, May 25, 2017 2:35 AM To: onap-discuss@lists.onap.org Subject: [onap-discuss] YANG.XML format Hi ONAPers: There is an option in SDC to add deployment artefacts as part of the service composition – is there a specific guideline on what format is needed for the YANG.XML ? Regards Owen ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
[onap-discuss] YANG.XML format
Hi ONAPers: There is an option in SDC to add deployment artefacts as part of the service composition – is there a specific guideline on what format is needed for the YANG.XML ? Regards Owen ___ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
