On Fri, Sep 04, 2015 at 11:33:27AM +0100, Robert Wilton wrote: > Hi Juergen, > > Thanks for the review and comments. > > Yes, when I originally thought of this idea I intended using XML > attributes, but after discussion with a couple of colleagues, we saw a > couple of issue with using them: > > 1) One of the desired requirements in draft-openconfig-netmod-opstate-01 > (section 4.5 last paragraph) is to have a unique path to identify the > intended cfg node vs the applied cfg node. I couldn't see how this > could be solved with attributes. I'm also not sure whether the separate > applied config data store solves this problem, although presumably a NMS > could store all paths as a (datastore, path) pairing.
Yep, I do not agree with this requirement. Datastores are an architectural concept in both NETCONF and YANG and hence an NMS needs to understand what a datastore is. > 2) I wanted to be able to represent config nodes for configuration that > are in the process of being deleted (i.e. applied but not intended), and > wasn't convinced that this could be achieved cleanly using attributes. Yep. This may require some careful design. > 3) There doesn't seem to be any standard encoding for attributes in JSON > ... although of course this doesn't prevent attributes from being used > in XML based encodings. See draft-ietf-netmod-yang-metadata-01 section 4.2 for the proposed JSON encoding. /js -- 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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
