From: Athanasios Kyparlis Sent: Tuesday, December 6, 2016 4:06 PM To: 'Alex Campbell' <[email protected]>; Robert Wilton <[email protected]>; [email protected] Subject: RE: [netmod] Modelling different "levels" of data in YANG
To answer Rob's question (if I understand it correctly), the client would know the data is not included in a regular get, as the data definition will only exist in the action/rpc output definition. Thanks From: Alex Campbell [mailto:[email protected]] Sent: Tuesday, December 6, 2016 4:03 PM To: Robert Wilton <[email protected]<mailto:[email protected]>>; Athanasios Kyparlis <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [netmod] Modelling different "levels" of data in YANG IMO using an action or rpc is an okay solution for now, certainly better than than not including the data at all. Perhaps in the future the client could specify which YANG modules it cares about, in addition to a subtree filter. Then you could put the extended diagnostic information into another module (using "augment"), and clients that don't know about the extended diagnostic information wouldn't request it, and clients that do would know to only request it when they need it. The problem also makes me think of ConfD's "hide groups", but it's hard to see how those would be extended to support programmatic interfaces. ________________________________ From: netmod <[email protected]<mailto:[email protected]>> on behalf of Robert Wilton <[email protected]<mailto:[email protected]>> Sent: Wednesday, 7 December 2016 3:58 a.m. To: Athanasios Kyparlis; [email protected]<mailto:[email protected]> Subject: Re: [netmod] Modelling different "levels" of data in YANG Hi Athanasios, Thanks for the suggestion. As per my reply to Vladimir, I think that this solves the question of how to get them, but doesn't really solve the issue of how a client is expected to know that they wouldn't be included in a regular get request. Thanks, Rob On 05/12/2016 18:25, Athanasios Kyparlis wrote: Maybe not ideal, but could we use an action or rpc for them? ________________________________ From: netmod <[email protected]><mailto:[email protected]> on behalf of Robert Wilton <[email protected]><mailto:[email protected]> Sent: Monday, December 5, 2016 1:10:47 PM To: [email protected]<mailto:[email protected]> Cc: Peter Jones Subject: [netmod] Modelling different "levels" of data in YANG Hi, We are currently working on modelling 802.3 Ethernet YANG within the 802.3 YANG study group. One interesting issue that has come up is the scope of the operational state data that could be modeled: At the top level, an operator may just want to know whether an Ethernet interface is up or down. At a second level, if the Ethernet interface is down, then there is some high level diagnostics information that may be useful to an operator to diagnose why the interface isn't up (e.g. alarms information, optical power levels, auto-negotiation protocol status). There is also a third level, of very detailed, 802.3 hardware register information defined in 802.3 Clause 45. Such information is probably of most relevance to the engineers developing and programming Ethernet chips and PHYs, but is sometimes useful for resolving potential vendor inter-operation issues. Retrieving this information out of the Ethernet chips can be comparatively slow. The question that was being discussed is whether it is appropriate to model all three levels on information in the 802.3 Ethernet YANG models, or whether only the top level and second level information can/should be modeled via YANG? If we were to model the third level information in YANG then it would seem highly desirable for that information to not be returned in response to a general NETCONF <get/> request because the information is generally not of relevance and has potential performance issues in returning it. Instead, it would seem desirable to only return this data if it was specifically requested (e.g. a <get/> request on the node containing the third level information), or if a hypothetical filter extension was specified and used to explicitly include it in the response. Given that there doesn't seem to a great way to currently achieve this in YANG, this makes me think that it isn't sensible to model this third level of detailed information in YANG at this time. Do others agree? Have others faced similar issues, and if so, how have you solved them? Input welcome. Thanks, Rob _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
