Subject: RE: [OPS-AREA]draft-stephan-ops-xml-mib-module-template-00.txt:XML template forMIB modules

From: "Natale, Bob" <[email-masked]>
Date: Thu, 1 Mar 2007 01:30:43 -0500

Hi,

> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 2:43 PM
> ...
> Again, SMI to XML translations are out there for years. I am not
> against standardizing them if there is an added value of doing so. So
> we need to understand where the added value comes from.

I agree.  I gave much thought to the observation that some pretty good
SMI-to-XML translators have existed for some time but do not seem to
have made a deciding impact in the community or in the marketplace as
part of the rationale for the "MIB-to-SOA/WS-artifacts" effort I have
proposed.  XML is a nice improvement over the SMI's "adapted ASN.1" for
SOA/WS environments, but is not sufficient to make a material
difference...we simply have to provide "more" for that environment to
reach the "tipping point"...and by doing so we will also facilitate
making the existing SNMP instrumentation available to those "new age"
management tools.

Beyond that, I did not find the XML mark-up specified in the subject
draft to be as readable or generally useful as that of the SMI-to-XML
translators that I have reviewed (rarely, I admit) over the past
several years.  I understand the relationship to xml2rfc that Emile is
targeting, but I prefer the solution approach indicated by Juergen.

(While the foregoing was written in good faith, I admit that I'd love
to draw Emile away from spending more time on his proposal and get his
active participation on the "MIB-to-SOA/WS-artifacts" effort. :)
Almost every path to success I see for that effort will depend on a
high-quality SMI-to-XML conversion as its foundation.)

Cheers,
BobN

_______________________________________________
OPS-AREA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ops-area

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Mar 2007 08:33:27 +0100

> making the existing SNMP instrumentation available to those "new age"

So here is the challenge for your BOF: Please explain in very clear
terms what this "more" is to reach the "tipping point" - note that
I am not easily impressed by lists of buzz words. I like to know
where and how we save developer time, operator time, create a new
market, ... with those "SOA/WS-artifacts" (make sure you explain
what this actually is). And if you talk about things like "state of 
the industry", please make sure that someone like me has an idea what 
that means and why we care (SNMP history is full of decisions made
by claims about the industry and I am not sure this has been a 
very successful approach).

Again, this message is not meant to be a negative reaction; I just
want to provide questions to think about while you prepare material
for the meeting in Prague.

/js

-- 
Juergen Schoenwaelder		 Jacobs University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Fri, 2 Mar 2007 00:25:06 +0100

Hi,

My proposal promotes the usage of SMv2 for the increasing number of network management protocols which don't have any standard language to specify their management interface. 
 
The reason is clear: As they are not able to clearly align their management interface with existing MIBs, they cause data duplication in NMS while preventing any correlations.
 
I mostly agree with Andy. SNMP is not part of the scope. I support the idea of standardizing the extraction of SMI dynamic tables (and more) in XML. NETCONF is a typical client.
 
Nevertheless, I consider that the standardization process is the central point:
 
How can someone decently encourage people to specify XML management interface in SMI without providing them with a minimum tool for that? Can someone expect them to use other tools that XML one?
It is not credible to ask them to wait 1 year and a half. So we have to provide them with a solution based on XML, based on the SMI and based on the specification process of IETF. XSL is reach enough to arrange the details while deriving network management interfaces in each network protocol desire... and more. 
 
Regards
Emile

-----Message d'origine-----
De : Juergen Schoenwaelder [mailto:[email-masked]] 
Envoyé : jeudi 1 mars 2007 08:33
À : Natale, Bob
Cc : STEPHAN Emile RD-CORE-LAN; [email-masked]
Objet : Re: [OPS-AREA]draft-stephan-ops-xml-mib-module-template-00.txt:XMLtemplate forMIB modules

 

/js