Re: [onap-discuss] Supporting IETF Interface YANG model based on RFC8343?

2018-07-19 Thread WRIGHT, STEVEN A 
The obsolescence/upgrade of upstream specifications seems like a   problem we 
need a generic solution for. These may not be major feature upgrades, but we 
need to maintain parity with the larger industry.  Even if the RFC upgrade is 
not supported in this release, I would expect we would need to support it in a 
future release. Hence I would like to find a way to track this in JIRA and 
assign it to a future release so that we don't forget about it.  We can 
reconsider the task as we review the next release planning whether this sort of 
upgrade should be supported in that release. I can create a task/story  in 
VNFRQTS for the upgrade there, but I would need corresponding tasks for the 
upgrades that would need to be in place elsewhere in the ONAP platform 
components and have them assigned to those components.  
Does this seem a reasonable way to proceed?

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11273): https://lists.onap.org/g/onap-discuss/message/11273
Mute This Topic: https://lists.onap.org/mt/23743179/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [onap-discuss] Supporting IETF Interface YANG model based on RFC8343?

2018-07-19 Thread Brian 


[sdnc/northbound.git]
 / 
generic-resource-api
 / 
model
 / 
src
 / 
main
 / 
yang
 / 
GENERIC-RESOURCE-API.yang

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 
Sent: Thursday, July 19, 2018 5:48 AM
To: FREEMAN, BRIAN D ; onap-discuss@lists.onap.org
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 namestring
   +--rw description?string
   +--rw typeidentityref
   +--rw enabled?boolean
   +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   +--ro admin-statusenumeration {if-mib}?
   +--ro oper-status enumeration
   +--ro last-change?yang:date-and-time

[onap-discuss] Supporting IETF Interface YANG model based on RFC8343?

2018-07-19 Thread John Q 
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 namestring
   +--rw description?string
   +--rw typeidentityref
   +--rw enabled?boolean
   +--rw link-up-down-trap-enable?   enumeration {if-mib}?
   +--ro admin-statusenumeration {if-mib}?
   +--ro oper-status enumeration
   +--ro last-change?yang:date-and-time
   +--ro if-indexint32 {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-timeyang: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 
Sent: 18 July 2018 14:13
To: 'onap-discuss@lists.onap.org' < onap-discuss@lists.onap.org >; John Quilty 

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: onap-discuss@lists.onap.org; 
john.qui...@ericsson.com
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: onap-discuss@lists.onap.org 
mailto:onap-discuss@lists.onap.org>> On Behalf Of 
John Q
Sent: Wednesday, July 18, 2018 6:42 AM
To: onap-discuss@lists.onap.org
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 (#11265): https://lists.onap.org/g/onap-discuss/message/11265
Mute This Topic: https://lists.onap.org/mt/23743179/21656
Group Owner: onap-discuss+ow...@lists.onap.org
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-