On Wed, Mar 11, 2015 at 04:03:02AM -0400, Alia Atlas wrote: > On Wed, Mar 11, 2015 at 3:55 AM, Juergen Schoenwaelder < > [email protected]> wrote: > > > On Wed, Mar 11, 2015 at 03:33:14AM -0400, Alia Atlas wrote: > > > Juergen, > > > > > > On Wed, Mar 11, 2015 at 3:24 AM, Juergen Schoenwaelder < > > > [email protected]> wrote: > > > > > > > On Fri, Mar 06, 2015 at 06:06:44PM -0500, Alia Atlas wrote: > > > > > Given the excellent progress that the WG has been making - due to > > your > > > > work > > > > > and interest, I have been working on a simple rechartering with Sue > > and > > > > > > > > Here is the diff related to topology: > > > > > > > > - o The ability to extract information about topology from the > > network. > > > > - Injection and creation of topology will not be considered as an > > > > initial work item. > > > > + o The ability to extract information about topology from the > > network. > > > > + These models will be based on a generic topology model to support > > > > + multiple uses. Injection and creation of topology will not be > > > > considered > > > > + as a work item. > > > > > > > > The first and third sentences are both about 'reading topology'. Does > > > > this imply that the generic model will also be limited to 'reading > > > > topology'? Or will the generic model also allow create topology? > > > > > > It's an interesting question. What use-cases do you see where > > > writing the topology is appropriate? > > > > If you want to do service management, you need to describe (configure) > > the desired service topology. This is largely an interface to the > > network manager (called a controller these days). > > > > True - I see that as needing significantly more information, but having a > generic topology model to build upon would be useful. >
The question was whether the generic topology is config true, config false or both. The proposed charter text is not clear. > > > If one thinks of reading the topology as reading operational state, > > > aren't read-write config and read-only operational recommended to be > > > separated in YANG models (at least for now)? > > > > Yes, we love to separate config state from operational state. But this > > has nothing to do with the scope of the work item added to the I2RS > > charter. > > > It is relevant if I2RS defines the operational topology for reading and > there isn't an active need for writing the topology. > > If there is an active need - presumably because of interest in modeling > interfaces to a network manager - then I can massage the text. I don't > see a reason to have separate drafts. > It would be nice to have this scope issue clarified so other WGs know what can be expected. Thanks. /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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
