Hi Juergen, which specific objects/ subtrees are you referring to?
Essentially, in ietf-network and ietf-network-topology, we have all configuration information. The same is true for the Layer 3 topology - all configuration information. (I cannot comment on L2 topology as I am not involved there.) Are you saying that we should add an additional branch as a placeholder (and perhaps an augmentation target) for operational data, even if we have not otherwise defined any operational data? The only item in the topology that is read-only concerns the "server-provided" flag, but this concerns a separate issue that was also discussed (I am not sure if this is what you are referring to). It is analogous to the other discussion concerning distinguishing configuration that has been intended, versus one that is in effect etc . This concerns the issue that some topologies are populated by the server whereas some topologies can be populated by client applications. We have had discussions in the past whether to "split this up", having a (rw) branch to populate "intended" topologies and a (ro) branch for topologies "in effect". We decided against it for various reasons - every piece of information would essentially be duplicated inside the model (this is not your normal config vs oper data distinction, but would essentially reflect a limitation of the framework), leading to unnecessary additional complexity in the model (every augmentation has to be conducted in two places), more complex validation rules, etc. --- Alex -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Juergen Schoenwaelder Sent: Friday, October 09, 2015 12:22 AM To: Susan Hares <[email protected]> Cc: [email protected]; Martin Bjorklund <[email protected]>; Ladislav Lhotka <[email protected]>; Andy Bierman <[email protected]>; 'Jeffrey Haas' <[email protected]>; 'Alia Atlas' <[email protected]> Subject: Re: [i2rs] WG LC for Topology (10/1 to 10/14) Hi, there is a discussion on the yang doctors mailing list about the data model design that mixes state data and configuration data into one subtree and that uses a data model specific runtime object to identify what is config data and what is state data. One of the main outcomes of the IAB workshop back in 2002 was the need to clearly separate configuration from operational state and this has been driven the design of NETCONF and YANG. YANG data model validation rules, for example, make a distinction between config true and config false data. The config true or false property impacts what is returned by NETCONF's get-config operation. Also note that config data is not allowed to refer to config false data in constraints. It is unclear why the document does not follow the typical design pattern, namely to have a config true subtree /networks/network* and a config false subtree /networks-state/network* Section 3.5 describes this approach in the 3rd paragraph and states "As most data is defined in those groupings, the amount of additional definitions required will be limited." and there are no strong reasons given why this approach has not been followed. /js On Thu, Oct 01, 2015 at 06:41:34PM -0400, Susan Hares wrote: > This begins a 2 week WG Last call (10/1 to 10/14) > > > > draft-ietf-yang-network-topo - modeling draft > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-network-topo/ > > > > draft-ietf-i2rs-yang-l3-topology - L3 topology > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ > > > > draft-ietf-i2rs-yang-l2-topology - L2 topology > > http://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l2-network-topolo > gy/ > > > > Implementation status: > > > > This an OpenDaylight (ODL) implementation of the L3 topology and > general model. It is likely the L2 topology model will be supported in > future ODL > implementations. Jeff and I would appreciate anyone who has > implementations of these topology models to provide details on list or > offlist to the chairs. > > > > Sue Hares > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs -- 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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
