RE: [OPS-AREA] RE: Comments on XSDMI BoF proposal
David Harrington <ietfdbh <at> comcast.net>
2007-06-06 13:07:43 GMT
I was referring to the separation of config and state data, as
described in RFC4741.
I do think the distinction made in rfc4741 is not very clear, so work
would need to be done.
Would this result in duplication of information? Without a draft
making a specific proposal for this, I cannot say. It might.
> -----Original Message-----
> From: Jon Saperia [mailto:saperia <at> jdscons.com]
> Sent: Wednesday, June 06, 2007 8:52 AM
> To: Romascanu, Dan (Dan)
> Cc: David Harrington; Andy Bierman; Ops-Nm
> Subject: Re: [OPS-AREA] RE: [OPS-NM] Comments on XSDMI BoF proposal
> 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?
> Romascanu, Dan (Dan) wrote:
> > ________________________________
> > From: Jon Saperia [mailto:saperia <at> jdscons.com]
> > XML-based management leverages lessons learned
> > from the WWW.
> > While document-based rather than
> > tasks can
> > often be grouped into a document-type
> > such as a
> > web page. With automated translation from XML
> > into HTML (and
> > related technologies), we can work on
> > task-based-document NM interfaces.
> > I think we need to spend more time thinking
> > about operator
> > use-cases, not just technical designs of SMIs.
> > think it
> > would help to start thinking in terms of
> > 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
> > 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,
> > 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
> > 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
OPS-NM <at> ietf.org