Subject: [OPS-AREA] Converting SNMP MIBs to SOA/Web Services Management Artifacts

From: "Natale, Bob" <[email-masked]>
Date: Wed, 28 Feb 2007 11:45:09 -0500

Hi,
 
[Rushing out to a meeting....]
 
Just in case people did not catch the announcement, the following I-D
was posted for the Prague mini-BOF indicated below:
"Converting SNMP MIBs to SOA/Web Services Management Artifacts", 
http://www.ietf.org/internet-drafts/draft-natale-snmp-mibs-to-ontology-
00.txt
<http://www.ietf.org/internet-drafts/draft-natale-snmp-mibs-to-ontology
-00.txt> .
 
This topic is considerably broader than the MIB-to-XML work proposed by
Emile, but (while a primary purpose of the BOF and the WG it proposes
is to identify the right set of artifacts) it is almost certain that
correct and efficient XML encoding of MIBs will be at the basis of the
desired artifacts, so it is good that we are having that discussion
(and that Emile's BOF presentation precedes this one on the agenda).
 
Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM
...
5. Mini-BOF G: OWL techniques for MIB to XML documents and schema
translation - Bob Natale (total: 40 min)
 
Specification of a standard methodology for translating SNMP MIBs into
outputs more directly usable by emerging SOA/web services management
tools, and specification of a standard methodology for validating those
translations.  Appropriate translation outputs are TBD by the WG, but
can be expected to include one or more of the following: XML, RDF,
WSDL,
WS-Policy, WS-Event/Notification, Ontology.  The translation output(s)
should allow for extension of the respective managed element data model
in the native SOA/web services environment.  Because of the
extensibility objective, reverse translation back into SNMP MIB format
is a non-goal of the WG, but the possibility should be considered when
weighing alternatives.
 
Cheers,
BobN
_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Feb 2007 10:01:41 -0800

Hi Bob,

I agree with you about the scope of the problem,
and I'm looking forward to the BoF.

I'm very interested in the problem of automated translation,
and a procedural model (based on NETCONF standard and extended
operations) that can directly integrate with SOA/WSDL NMS applications.

The only paragraph in your draft I really disagree with
is the final bullet in Sec. 3, about possible WG charter items:

  o  Nothing that is inconsistent with management entity support for
     SNMPv3 security and access control mechanisms will be introduced
     into the solution(s) standardized by this effort.

IMO, this requirement removes the possibility for real improvement
in the areas of access control and security integration.
In reality, an SNMP agent isn't going to be accepting the NM connection
for this new SOA interface.  It is more practical to use
a user-session-based protocol like NETCONF (or CLI over SSH2 even),
and interface to the SNMP engine in the agent implementation.

An access control model that accounts for verbs, classes, nested data,
and other SOA-like details is going to be easier to implement than VACM.

I believe the only component needed from 'the SNMP world' is SMIv2.
Standard translation from SMIv2 to XSD allows a high-level API to
reuse the semantics and algorithmic name translation of individual
MIB tables and objects in the definition of 'methods' (or verbs or
procedures or operations, or whatever else these are called).

These methods are not a normative component of SNMP.
They are usually not defined at all, and if they are,
it is usually in non-normative appendices or examples.

Basing a high-level API on low-level SNMP get* and set operations
is going to be much more complicated than almost any other
implementation choice.  Encoding SNMP operations in XML is
a "worst of both worlds" scenario.

Andy

> http://www.ietf.org/internet-drafts/draft-natale-snmp-mibs-to-ontology-00.txt.
>  
> Emile, but (while a primary purpose of the BOF and the WG it proposes is 
> to identify the right set of artifacts) it is almost certain that 
> desired artifacts, so it is good that we are having that discussion (and 
> that Emile's BOF presentation precedes this one on the agenda).
>  
> can be expected to include one or more of the following: XML, RDF, WSDL,
> ------------------------------------------------------------------------
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 28 Feb 2007 20:41:57 +0200

Just a logistics detail at this point. The second OPS Area meeting moved
to Wednesday afternoon sessions I and II. See
https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=
68. The good news is that we have now at hand 2 hours on Monday and 3
hours for Wednesday. We'll work on a re-shuffled agenda to be posted in
the coming days. 
 
Dan

  _____  

	From: Natale, Bob [mailto:[email-masked]] 
	
	Meeting 2 - Thursday March 22, 2007 - 9:00 to 11:30AM
	...
	5. Mini-BOF G: OWL techniques for MIB to XML documents and
schema
	translation - Bob Natale (total: 40 min)

---

From: "Natale, Bob" <[email-masked]>
Date: Wed, 28 Feb 2007 19:48:45 -0500

Hi Andy,

I think you might be right about the SNMPv3 security bullet.  Two
considerations:

1. There will definitely be implementations in which the "SOA/WSDL NMS
applications" (to use your term*) will use the converted MIB data
models to speak their language to a proxy agent that converts back into
SNMP operations/messages, talks to the SNMP agents for the managed
entities, and then performs the return translations.  Are you sure we
don't need to protect SNMPv3 security capabilities for that scenario?

2. Also, don't you think it might be possible to offer improvements wrt
access control and security integration, as you note, as a superset of
an approach that protects SNMPv3 security for the case described above?

So, I'd just like some additional consideration from you and others
about this before going ahead and deleting the bullet.

In conjunction with the above, I think you are also right that the
centrality of SMIv2 as the "technology" of interest here needs to be
made clearer and emphasized more.

I plan a -01 rev prior to Prague (although it probably won't go into
the official I-D database until afterwards).  I'll be happy to have
co-authors as well (for those who want to contribute text, etc.).

* - Terminology in the SOA/Web Services Management space is really
unsettled...all suggestions/guidance will be appreciated in identifying
the right set of terms we should use.

Cheers,
BobN

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, February 28, 2007 1:02 PM
To: Natale, Bob
Cc: OPS Area
Subject: Re: [OPS-AREA] Converting SNMP MIBs to SOA/Web Services
Management Artifacts

Hi Bob,

An access control model that accounts for verbs, classes, nested data,
and other SOA-like details is going to be easier to implement than
VACM.

Andy

00.txt.
> Emile, but (while a primary purpose of the BOF and the WG it proposes
is 
> desired artifacts, so it is good that we are having that discussion
(and 
WSDL,
> is a non-goal of the WG, but the possibility should be considered
when
-----------------------------------------------------------------------
-

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Feb 2007 17:23:17 -0800

> don't need to protect SNMPv3 security capabilities for that scenario?

I never liked SNMP Proxy, so I'm not a fan of this use case.
I think we can avoid specifics by writing a good Security Considerations
section, which would include mappings between each 'high-level'
operation and the minimum security level in VACM.
(E.g., edit-config --> auth/priv, get-config --> auth/no-priv,
close-session --> no-auth/no-priv).

> an approach that protects SNMPv3 security for the case described above?

There are several RPC-related features I want to use in NETCONF
that do not map well to VACM:

  1) Exec operations (e.g., ping).
     VACM forces a static data model, instead of a verb, that
     gets filled in with parameters and activated with RowStatus.
     This is a clumsy and even obsolete programming paradigm.

  2) Create data model instances with agent-supplied index components,
     and return the agent-supplied values in the 'set response'.
     Sometimes the manager doesn't control or care about the instance ID.
     I don't think it would be easy to do this with SNMP and VACM.

  3) Perform access control on the type of verb (e.g., config, monitor,
     exec, debug) or by namespace URI of the verb (or nested parameters
     to the verb).

It is CLI, not SNMP, that is driving XML-based NM like NETCONF.
I am not convinced that constraining any new high-level API
for the sake of SNMP Proxy would be a popular decision.

Andy