[sdnc/northbound.git]<https://gerrit.onap.org/r/gitweb?p=sdnc/northbound.git;a=tree;hb=refs/heads/master> / generic-resource-api<https://gerrit.onap.org/r/gitweb?p=sdnc/northbound.git;a=tree;f=generic-resource-api;hb=refs/heads/master> / model<https://gerrit.onap.org/r/gitweb?p=sdnc/northbound.git;a=tree;f=generic-resource-api/model;hb=refs/heads/master> / src<https://gerrit.onap.org/r/gitweb?p=sdnc/northbound.git;a=tree;f=generic-resource-api/model/src;hb=refs/heads/master> / main<https://gerrit.onap.org/r/gitweb?p=sdnc/northbound.git;a=tree;f=generic-resource-api/model/src/main;hb=refs/heads/master> / yang<https://gerrit.onap.org/r/gitweb?p=sdnc/northbound.git;a=tree;f=generic-resource-api/model/src/main/yang;hb=refs/heads/master> / GENERIC-RESOURCE-API.yang<https://gerrit.onap.org/r/gitweb?p=sdnc/northbound.git;a=blob_plain;f=generic-resource-api/model/src/main/yang/GENERIC-RESOURCE-API.yang;hb=refs/heads/master>
There is also a northbound model under sdnc/northbound/vnf-api. You will also want to check the LCM-API.yang model (under ccsdk or appc should be the same model as we move it from appc to ccsdk) Service providers may also have service provider specific northbound models and of course various adapters have yang models In any case a find across the ONAP tree services a set like this. Brian ./ccsdk/sli/core/sli/model/src/main/yang/sliapi.yang ./ccsdk/sli/core/sliapi/provider/src/main/yang/sliapi-provider-impl.yang ./ccsdk/sli/core/sliapi/model/src/main/yang/sliapi.yang ./ccsdk/sli/northbound/dataChange/model/src/main/yang/DataChange.yang ./ccsdk/sli/northbound/lcm/model/src/main/yang/lcm.yang ./ccsdk/sli/northbound/asdcApi/model/src/main/yang/ASDC-API.yang ./ccsdk/sli/northbound/asdcApi/model/src/main/yang/asdc-license-model.yang ./ccsdk/sli/northbound/asdcApi/model/src/main/yang/asdc-api-common.yang ./demo/vnfs/honeycomb_plugin/sample_plugin/sample-plugin-api/src/main/yang/sample-plugin.yang ./demo/vnfs/vLBMS/apis/health-vnf-onap-plugin/health-vnf-onap-plugin-api/src/main/yang/health-vnf-onap-plugin.yang ./demo/vnfs/vLBMS/apis/vlb-business-vnf-onap-plugin/vlb-business-vnf-onap-plugin-api/src/main/yang/vlb-business-vnf-onap-plugin.yang ./sdnc/northbound/vnfapi/model/src/main/yang/VNF-API.yang ./sdnc/northbound/vnfapi/model/src/main/yang/vnfsubmodule.yang ./sdnc/northbound/generic-resource-api/model/src/main/yang/GENERIC-RESOURCE-API.yang ./appc/appc-provider/appc-provider-model/src/main/yang/appc-provider-lcm.yang ./appc/appc-provider/appc-provider-model/src/main/yang/appc-provider.yang ./appc/appc-provider/appc-provider-bundle/src/main/yang/appc-provider-lcm.yang ./appc/appc-provider/appc-provider-bundle/src/main/yang/appc-provider.yang ./appc/appc-inbound/appc-design-services/model/src/main/yang/appc-design-services.yang ./appc/appc-inbound/appc-artifact-handler/provider/src/main/yang/artifact-handler-provider-impl.yang ./appc/appc-inbound/appc-artifact-handler/model/src/main/yang/artifact-handler.yang ./appc/appc-inbound/appc-interfaces-service/model/src/main/yang/appc-interfaces-service.yang ./appc/appc-oam/appc-oam-model/src/main/yang/appc-oam.yang ./appc/appc-oam/appc-oam-bundle/src/main/yang/appc-oam.yang ./appc/appc-sequence-generator/appc-sequence-generator-model/src/main/yang/sequence-generator.yang ./appc/appc-sequence-generator/appc-sequence-generator-bundle/src/main/yang/sequence-generator.yang ./appc/appc-sdc-listener/appc-yang-generator/src/test/resources/yang/expectedYang.yang ./appc/appc-dg/appc-dg-shared/appc-dg-mdsal-store/appc-dg-mdsal-model/src/main/yang/mdsal-store.yang ./appc/appc-dg/appc-dg-shared/appc-dg-mdsal-store/appc-dg-mdsal-bundle/src/main/yang/mdsal-store.yang From: John Quilty <[email protected]> Sent: Thursday, July 19, 2018 5:48 AM To: FREEMAN, BRIAN D <[email protected]>; [email protected] Subject: Supporting IETF Interface YANG model based on RFC8343? Hi Brian I am also looking at a JIRA issue about whether we should support RFC8343 (YANG data model for interface management) as it obsoletes RFC7223. I cannot find the interface YANG model used by SDNC. Is it based on RFC7223 or RFC8343? The difference is that the "/interfaces-state" subtree with read only data nodes is deprecated in RFC8343. All read only data nodes are now present in the "/interfaces" subtree (which previously only had read write data nodes). RFC7223 structure is still allowed in RFC8343 for backward compatibility reasons. New RFC8343 model: module: ietf-interfaces +--rw interfaces +--rw interface* [name] +--rw name string +--rw description? string +--rw type identityref +--rw enabled? boolean +--rw link-up-down-trap-enable? enumeration {if-mib}? +--ro admin-status enumeration {if-mib}? +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 {if-mib}? +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-ref +--ro lower-layer-if* interface-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 Regards John From: FREEMAN, BRIAN D <[email protected]<mailto:[email protected]>> Sent: 18 July 2018 14:13 To: '[email protected]' < [email protected]<mailto:[email protected]> >; John Quilty <[email protected]<mailto:[email protected]>> Subject: RE: Supporting YANG models based on RFC6020 and RFC7950 At least for GENERIC-RESOURCE-API. Vendor models exposed directly would be supported if ODL correctly communicates with the Yang 1.1 based device Brian From: FREEMAN, BRIAN D Sent: Wednesday, July 18, 2018 9:12 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: RE: Supporting YANG models based on RFC6020 and RFC7950 I thought this question had already been asked and the feedback was that only RFC6020 (Yang 1.0) was supported not RFC7950 (Yang 1.1) For VNF netconf interfaces I think there is recognition that Yang 1.1 models are available in a few devices and I thought folks were going to make it an option for the VNF Requirements. We are not supporting it on the northbound restconf interfaces on the controllers. I think you should follow up with the VNF Requirements project (Stephen Wright is PTL) if you are not already working with them. Brian From: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> On Behalf Of John Q Sent: Wednesday, July 18, 2018 6:42 AM To: [email protected]<mailto:[email protected]> Subject: [onap-discuss] Supporting YANG models based on RFC6020 and RFC7950 Hi I am looking to find out if there are any ONAP components using YANG parsers that cannot support models based on RFC7950 (also known as RFC6020bis). The ODL Yang parser can support both RFC6020 and RFC7950 Regards John -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11272): https://lists.onap.org/g/onap-discuss/message/11272 Mute This Topic: https://lists.onap.org/mt/23743179/21656 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
