Subject: [NGO] OPS-AREA Prague BOF Proposal: SNMP MIB to Ontology translation

From: "Natale, Bob" <[email-masked]>
Date: Tue, 2 Jan 2007 14:31:07 -0500

Hi,
 
Sending this proposal to both OPS-AREA and NGO lists, per guidance from
Dan.  I was worried that it might be a bit too far out there, but Dan
convinced me to stick my neck out anyway. :)
 
- - - - -
A WG to define standard methods for converting the body of existing
SNMP MIBs to OWL-based ontolologies, and standard methods for
validating the resulting ontologies.
 
- IETF standard MIBs are the prime target; compliant vendor-specific
enterprise MIBs would naturally follow.
 
- Such a mechanism could be an accelerant for the new breed of "SOA
Management" vendors who are not well-versed in IETF 
application, systems, and network management.
  
- This WG would examine the viability of starting from or building off
the existing (non-standard) methods of converting SNMP MIBs to XML
schema and documents.
 
- This WG would examine the viability of extending the NETCONF protocol
to work with such ontologies.
 
- This WG would then examine the viability of build-time extensibility
and run-time composability mechanisms associated with compliant
ontologies.
 
- At the end of this process, compliant ontologies developed
independently of pre-existing SNMP MIBs would be indistinguishable from
those developed from such MIBs, enabling a more modern and SOA-aware
method (OWL-S) of managed object data model construction. 
 
- At the end of this process, compliant ontologies might be extensible
in ways that are incompatible with reverse translation back into SNMP
MIBs.  Such reverse translation is not a goal of this effort.
 
The underlying predicates are:
- The body of SNMP MIBs comprises management knowledge and artifacts of
incalculable value to the industry, irrespective of instrumentation
mechanisms, access methods, and protocol(s) used to manipulate MIB
data.
- The nascent "SOA Management" industry could be relatively quickly
enriched, even if via WS<whatever>-to/from-SNMP proxies, via more
SOA-friendly management data models.  The expectation here is that
ontology-based management data models will be more accessible to and
usable by "SOA Management" tools than ASN.1 MIBs are.
 
"SOA Management" in quotes throughout because, while this label is
being used by a dozen or so significant vendors, I'm not sure it's
accurately descriptive or that it will stick long-term.
- - - - -
 
Personally, I see a clear and near-term real-world need for such
standard methods in my own work, and I believe that the emerging "SOA
Management" industry desperately needs it (but might not know it yet)
-- but I admit that most of that is purely subjective assessment at
this time.  I have the impression that earlier MIB-to-XML undertaken by
some thought-leaders among us was good work that did not get widely
deployed ("commercialized" is what I really mean).  If that is
accurate, we should consider the causes and whether they will have a
similar effect wrt this proposal.
 
Lastly, if anyone feels that this might be a good idea but is not as
well-expressed as it could be above, please revise as appropriate.
Another MITRE reviewer has commented that specifying OWL and OWL-S at
this stage might be premature.  That's probably a good point, but my
own research has really not turned up a viable alternative (based on my
limited knowledge/judgment).
 
Cheers,
BobN
Principal Engineer, GIG NetOps
Enterprise Services Systems Engineering
www.mitre.org

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Jan 2007 12:24:17 -0800

Hi Bob,

> convinced me to stick my neck out anyway. :)

This sounds great to me, especially if you are willing to Chair the WG. ;-)
I think NETCONF can support a service-oriented API, with service-specific
RPC methods and notifications.

IMO, the CLI model (config service, show service, etc.) is already closer
to an SOA than SNMP/SMIv2, and this is how a lot of NE devices are currently
being managed.  However, high-level procedures to manage specific services,
using standard MIB objects as parameters, should be possible.

In am very much in favor of abandoning the "raw data operation" API
mindset of SNMP (and NETCONF edit-config!), and viewing the API as a collection of
services, each with their own set of procedures and notification definitions.

The fly in the ointment is the startup config file which represents
the entire configuration upon reboot -- the 'document-oriented' APIs
(e.g., CLI, NETCONF standard operations) assume the entire desired state
of the NE device can be represented in text commands, and any box
of the same device-type can consume this startup config file at boot-time
and function correctly within the network.  Operators usually want
visibility (i.e., human readability) of this file.

Any SOA-based API, whether SNMP or CLI based, will need to be compatible
with this important feature.

Andy

>  
> - - - - -
> A WG to define standard methods for converting the body of existing SNMP 
> MIBs to OWL-based ontolologies, and standard methods for validating the 
> resulting ontologies.
>  
> and run-time composability mechanisms associated with compliant ontologies.
>  
> mechanisms, access methods, and protocol(s) used to manipulate MIB data.
> "SOA Management" in quotes throughout because, while this label is being 
> used by a dozen or so significant vendors, I'm not sure it's accurately 
> descriptive or that it will stick long-term.
> - - - - -
>  
> Personally, I see a clear and near-term real-world need for 
> such standard methods in my own work, and I believe that the emerging 
> "SOA Management" industry desperately needs it (but might not know it 
> yet) -- but I admit that most of that is purely subjective assessment at 
> deployed ("commercialized" is what I really mean).  If that is accurate, 
> we should consider the causes and whether they will have a similar 
> effect wrt this proposal.
>  
> this stage might be premature.  That's probably a good point, but my own 
> research has really not turned up a viable alternative (based on my 
> www.mitre.org <http://www.mitre.org>
>  
>  
> 
> 
> ------------------------------------------------------------------------
>