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&T 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&T ***
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 
<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

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&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: 
<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&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: 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,

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&T 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&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<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.amdocs.com_about_email-2Ddisclaimer&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=5dr94prXH2Bs3fZkzpVsASPcH93hpNUM-tY-Nz-yrlM&m=a5Mu7ykPu6M_rOwLL6yWqlWReJQVgEfHqKbxHi7_G7Y&s=WnDfWiG0Uh9AB5PXzffBB-H89gwP_91GmgCfY13bItw&e=>
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 
<https://www.amdocs.com/about/email-disclaimer>
_______________________________________________
onap-discuss mailing list
onap-discuss@lists.onap.org
https://lists.onap.org/mailman/listinfo/onap-discuss

Reply via email to