I fear that a dumb client sending a <get/> without a proper filter to select the data that is relevant for the client will not necessarily get smarter by defining additional operations.
Sometimes access control can help to control dumb clients that try to get everything (and then ignore most of the data they receive); simply make sure that only the information is accessible to a client that is actually needed by a client. In other words, the filtering logic does not have to be hard coded in the data model. /js On Tue, Dec 06, 2016 at 09:03:09PM +0000, Alex Campbell wrote: > 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 <netmod-boun...@ietf.org> on behalf of Robert Wilton > <rwil...@cisco.com> > Sent: Wednesday, 7 December 2016 3:58 a.m. > To: Athanasios Kyparlis; netmod@ietf.org > 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 <netmod-boun...@ietf.org><mailto:netmod-boun...@ietf.org> on > behalf of Robert Wilton <rwil...@cisco.com><mailto:rwil...@cisco.com> > Sent: Monday, December 5, 2016 1:10:47 PM > To: netmod@ietf.org<mailto:netmod@ietf.org> > 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 > netmod@ietf.org<mailto:netmod@ietf.org> > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
