RE: [OPS-AREA] RE: Comments on XSDMI BoF proposal
"Romascanu, Dan (Dan)" <[email protected]> Wed, 6 Jun 2007 14:47:28 +0200
| Newsgroups | gmane.ietf.ops-nm |
|---|---|
| Message-ID | <EDC652A26FB23C4EB6384A4584434A040D8023@307622ANEX5.global.avaya.com> |
This is a multi-part message in MIME format. --===============1130395102== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7A838.D794CB3A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7A838.D794CB3A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 ________________________________ From: Jon Saperia [mailto:[email protected]]=20 =09 XML-based management leverages lessons learned from the WWW.=20 While document-based rather than command-based, tasks can=20 often be grouped into a document-type interface, such as a=20 web page. With automated translation from XML into HTML (and=20 related technologies), we can work on developing task-based-document NM interfaces.=20 =09 I think we need to spend more time thinking about operator=20 use-cases, not just technical designs of SMIs. I think it=20 would help to start thinking in terms of modular data models=20 similar to MIB modules, not just a <running> config, but we=20 need to develop an SMI that helps to differentiate config and=20 state info, which SMIv2 doesn't do, Maybe all we need to do=20 is recommend that MIB modules have separate subtrees for=20 config and for state, much as we now recommend separate=20 subtrees for objects and notifications.=20 =20 =09 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.=20 =20 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] =20 [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.=20 =20 Dan =20 =09 =09 ------_=_NextPart_001_01C7A838.D794CB3A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.3086" name=3DGENERATOR></HEAD> <BODY text=3D#000000 bgColor=3D#ffffff> <DIV><STRONG><EM><FONT face=3DArial color=3D#0000ff=20 size=3D2></FONT></EM></STRONG> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Jon Saperia = [mailto:[email protected]]=20 <BR></FONT></DIV> <BLOCKQUOTE=20 = cite=3DmidEDC652A26FB23C4EB6384A4584434A040D7E8D@307622ANEX5.global.avaya= .com=20 type=3D"cite"> <BLOCKQUOTE type=3D"cite"><PRE wrap=3D"">XML-based management = leverages lessons learned from the WWW.=20 While document-based rather than command-based, tasks can=20 often be grouped into a document-type interface, such as a=20 web page. With automated translation from XML into HTML (and=20 related technologies), we can work on developing=20 task-based-document NM interfaces.=20 I think we need to spend more time thinking about operator=20 use-cases, not just technical designs of SMIs. I think it=20 would help to start thinking in terms of modular data models=20 similar to MIB modules, not just a <running> config, but we=20 need to develop an SMI that helps to differentiate config and=20 state info, which SMIv2 doesn't do, Maybe all we need to do=20 is recommend that MIB modules have separate subtrees for=20 config and for state, much as we now recommend separate=20 subtrees for objects and notifications.=20 </PRE></BLOCKQUOTE><PRE wrap=3D""><!----> 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.=20 </PRE></BLOCKQUOTE> <DIV><BR>I have seen a couple of references in the discussion to State = and=20 netconf. Can we be more specific about what we mean by state = here. =20 Configuration state? When I think of other types of state such = as=20 operational state or quality state I think of either read MIB objects = or=20 notifications (traps/informs).<BR><SPAN=20 class=3D626144512-06062007><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2>[DR] </FONT></EM></STRONG></SPAN><BR><SPAN=20 class=3D626144512-06062007><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2>[DR] My interpretation was state as in state of the = system which=20 is the super-set of configuration state, but not limited to = configuration=20 state. It is David however who introduced the term in the thread, so=20 I would rather have him=20 answer. </FONT></EM></STRONG></SPAN></DIV> <DIV><SPAN class=3D626144512-06062007></SPAN> </DIV> <DIV><SPAN class=3D626144512-06062007><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Dan</FONT></EM></STRONG></SPAN></DIV> <DIV><SPAN=20 class=3D626144512-06062007> </SPAN><BR><BR></DIV></BLOCKQUOTE></BODY= ></HTML> ------_=_NextPart_001_01C7A838.D794CB3A-- --===============1130395102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-NM mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ops-nm --===============1130395102==--