Re: [OPS-AREA] RE: Comments on XSDMI BoF proposal
Jon Saperia <[email protected]> Wed, 06 Jun 2007 08:52:05 -0400
| Newsgroups | gmane.ietf.ops-nm |
|---|---|
| Message-ID | <[email protected]> |
Thanks for the clarification, lets see what Dave says. If it is as you say, then I would say what is the justification for introducing duplication of information? /jon Romascanu, Dan (Dan) wrote: > > > > > > > ________________________________ > > From: Jon Saperia [mailto:[email protected]] > > > XML-based management leverages lessons learned > from the WWW. > While document-based rather than command-based, > tasks can > often be grouped into a document-type interface, > such as a > web page. With automated translation from XML > into HTML (and > related technologies), we can work on developing > > task-based-document NM interfaces. > > I think we need to spend more time thinking > about operator > use-cases, not just technical designs of SMIs. I > think it > would help to start thinking in terms of modular > data models > similar to MIB modules, not just a <running> > config, but we > need to develop an SMI that helps to > differentiate config and > state info, which SMIv2 doesn't do, Maybe all we > need to do > is recommend that MIB modules have separate > subtrees for > config and for state, much as we now recommend > separate > subtrees for objects and notifications. > > > > Maybe, but at this point in time all the base of > standard MIB modules is > not designed this way. What are we going to do, re-write > these MIB > modules, or part of them? This does not seem an > achievable task. > > > > I have seen a couple of references in the discussion to State > and netconf. Can we be more specific about what we mean by state here. > Configuration state? When I think of other types of state such as > operational state or quality state I think of either read MIB objects or > notifications (traps/informs). > [DR] > [DR] My interpretation was state as in state of the system which > is the super-set of configuration state, but not limited to > configuration state. It is David however who introduced the term in the > thread, so I would rather have him answer. > > Dan > > > > > > -- Jon Saperia (cell) 617-201-2655 (Eve.) 978-461-0264 _______________________________________________ OPS-NM mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ops-nm