+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 <[email protected]> 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:* [email protected] [mailto:onap-discuss-bounces@ > lists.onap.org] *On Behalf Of *NOSHPITZ, CLAUDE > *Sent:* Wednesday, July 05, 2017 4:08 PM > *To:* 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 > > > > ****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]> on behalf of "LANDO, > MICHAEL" <[email protected]> > *Date: *Wednesday, July 5, 2017 at 11:09 AM > *To: *Kedar Ambekar <[email protected]>, " > [email protected]" <[email protected]>, "ROZIN, EDEN" > <[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 <+972%203-545-1487> > > *Mobile*: +972 (54) 7833603 <+972%2054-783-3603> > > *e-mail*: *[email protected] <[email protected]>* > > > > > > *From:* [email protected] [mailto:onap-discuss-bounces@ > lists.onap.org <[email protected]>] *On Behalf Of *Kedar > Ambekar > *Sent:* Thursday, June 08, 2017 4:17 AM > *To:* [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:onap-discuss-bounces@ > lists.onap.org <[email protected]>] *On Behalf Of * > Lando,Michael > *Sent:* Monday, June 5, 2017 3:56 AM > *To:* Law, Owen <[email protected]>; [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 <+972%203-545-1487> > > *Mobile*: +972 (54) 7833603 <+972%2054-783-3603> > > *e-mail*: *[email protected] <[email protected]>* > > > > > > *From:* [email protected] [mailto:onap-discuss-bounces@ > lists.onap.org <[email protected]>] *On Behalf Of *Law, > Owen > *Sent:* Thursday, May 25, 2017 2:35 AM > *To:* [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. > > ============================================================ > ================================================================ > > _______________________________________________ > onap-discuss mailing list > [email protected] > https://lists.onap.org/mailman/listinfo/onap-discuss > >
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
