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: [email protected] [mailto:[email protected]] 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; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of FREEMAN, BRIAN D Sent: Wednesday, July 5, 2017 4:12 PM To: NOSHPITZ, CLAUDE <[email protected]>; LANDO, MICHAEL <[email protected]>; Kedar Ambekar <[email protected]>; ROZIN, EDEN <[email protected]> Cc: WRIGHT, STEVEN A <[email protected]>; [email protected] 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of NOSHPITZ, CLAUDE Sent: Wednesday, July 05, 2017 4:08 PM To: LANDO, MICHAEL <[email protected]<mailto:[email protected]>>; Kedar Ambekar <[email protected]<mailto:[email protected]>>; ROZIN, EDEN <[email protected]<mailto:[email protected]>> Cc: WRIGHT, STEVEN A <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT&T *** 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&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=RrxQS3rYr0AtdSaucYzM1p0Ywlc_r0QmOL64pUO2GLI&e=> (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&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=MamwuVtlJ_7ueE9d6KuMZU34GCLcgJoUnEv0zgFIssA&e=> (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&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=4xEpN-BrZSWWL8xoZm6LLvdvnaSJP4ociN7TpUFL5FI&e=>. 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&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=4QRzzK-sxY3vek1cqPt9QdXpE8le474yarm_TT84zu0&e=>, 7223<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7223.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=1ZORtyRTKrCMEFOfGCOju2loc02tKIslNz2bkiBe63Y&e=>, 7317<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_rfc_rfc7317.txt&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=pPHmyk2Y0FvxM9Ubaqkn89dmpYX-reOexeGv6nKMdhM&e=>, 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&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=e3d1ehx3DI5AoMgDmi2Fzw&m=c8azFFyBCbVT2IK4S94QFCPLlzij-q0AtVmAN2w7ELM&s=_eTL0pDKKxFtg2kDy6IvwGjgoKdsfMZ9Xb7y9xOsnvs&e=>, 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: <[email protected]<mailto:[email protected]>> on behalf of "LANDO, MICHAEL" <[email protected]<mailto:[email protected]>> Date: Wednesday, July 5, 2017 at 11:09 AM To: Kedar Ambekar <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "ROZIN, EDEN" <[email protected]<mailto:[email protected]>> Subject: Re: [onap-discuss] YANG.XML format ***Security Advisory: This Message Originated Outside of AT&T *** Reference http://cso.att.com/EmailSecurity/IDSP.html for more information. +Edan BR, Michael Lando Opensource & Frontend Team Lead, SDC AT&T Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··········································································· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: [email protected]<mailto:[email protected]> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Kedar Ambekar Sent: Thursday, June 08, 2017 4:17 AM To: [email protected]<mailto:[email protected]> 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: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Lando,Michael Sent: Monday, June 5, 2017 3:56 AM To: Law, Owen <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> 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&T Network Application Development · NetCom Tel Aviv | Tampa | Atlanta | New Jersey |Chicago ··········································································· Office: +972 (3) 5451487 Mobile: +972 (54) 7833603 e-mail: [email protected]<mailto:[email protected]> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Law, Owen Sent: Thursday, May 25, 2017 2:35 AM To: [email protected]<mailto:[email protected]> 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&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=FYvXSElfSmWIXOeZxWIxQysejuz9-TXmaL6uftBh8MY&m=R--ZI_iRaoBn-HH2hiFLvWRayidFxdhf6JlbghF3HN4&s=zuxLhU26Z-QENdqYywiQxyoHugmT9np_hi_N4HnJWyQ&e=> externally http://tim.techmahindra.com/tim/disclaimer.html<https://urldefense.proofpoint.com/v2/url?u=http-3A__tim.techmahindra.com_tim_disclaimer.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=FYvXSElfSmWIXOeZxWIxQysejuz9-TXmaL6uftBh8MY&m=R--ZI_iRaoBn-HH2hiFLvWRayidFxdhf6JlbghF3HN4&s=XDy5dphHs4UEWk4Bd5WeR54dPgl9d7QZlpbj6JOwzJ4&e=> internally within TechMahindra. ============================================================================================================================ This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer ________________________________ The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
