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: <[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 Mobile: +972 (54) 7833603 e-mail: [email protected]<mailto:[email protected]> From: [email protected] [mailto:[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:[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. ============================================================================================================================
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
