Andy:
<chair hat> Thank you for bringing up your questions regarding NACM, I2RS topologies, and revised data stores. This area of discussion may be part of Alex’s work that he indicates he’s going to review. Splitting the conversation into “current” yang and “revised datastores” yang is a very good idea. I encourage the authors to do so. </chair hat off> IMO the way this server-provided property is being done is a short-sighted point solution, but this should be a fundamental part of the revised datastores work. Is there something special about network topology such that server-provided data for a different module will require a different solution? If not, is the topo module solution reusable? Sue Hares From: i2rs [mailto:[email protected]] On Behalf Of Andy Bierman Sent: Thursday, February 16, 2017 2:00 PM To: [email protected] Subject: [i2rs] topo model use of NACM Hi, The use of NACM for server-provided data is under-specified (at best) from sec. 4.1: Finally, there is an object "server-provided". This object is state that indicates how the network came into being. Network data can come into being in one of two ways. In one way, network data is configured by client applications, for example in case of overlay networks that are configured by an SDN Controller application. In annother way, it is populated by the server, in case of networks that can be discovered. If server-provided is set to false, the network was configured by a client application, for example in the case of an overlay network that is configured by a controller application. If server-provided is set to true, the network was populated by the server itself, respectively an application on the server that is able to discover the network. Client applications SHOULD NOT modify configurations of networks for which "server-provided" is true. When they do, they need to be aware that any modifications they make are subject to be reverted by the server. For servers that support NACM (Netconf Access Control Model), data node rules should ideally prevent write access by other clients to network instances for which server- provided is set to true. The SHOULD NOT above is really odd, considering is not supported by YANG or the NC/RC protocols. "data node rules should ideally prevent" s/should/SHOULD/ Ideally prevent? Is that a new engineering term? Either this new usage of NACM works or it doesn't. Also, there is no guidance or examples of the NACM config that the server is supposed to magically create for server-provided topology data. There is nothing in NACM at all about server-created data rules. This is not supported by NACM. Does the I2RS text imply that the server-provided property extends to the NACM sub-trees? They are also subject to replacement by the server? The client SHOULD NOT change these NACM rules? IMO the way this server-provided property is being done is a short-sighted point solution, but this should be a fundamental part of the revised datastores work. Is there something special about network topology such that server-provided data for a different module will require a different solution? If not, is the topo module solution reusable? Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
