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

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Wed, 28 Feb 2007 09:15:19 +0100

Hi,

A new draft is available.
This memo (
http://tools.ietf.org/html/draft-stephan-ops-xml-mib-module-template-00
) presents a XML template for specifying SMI objects and proposes a
common XSL base for sharing SMI objects definitions with XML
applications. 

It includes an example of XML application loading MIB objects of a XML
version of the SAMPLE-MIB of
draft-harrington-text-mib-doc-template-02.txt.

Comments are welcome to prepare the mini bof of Prague.

Regards
Emile

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Feb 2007 16:35:06 +0100

> Comments are welcome to prepare the mini bof of Prague.

I like to see a clear statement why this approach is better than using
a simple include directive and writing the MIB module directly in
exactly the way in should look like.

If there are strong reasons for using XML, I assume the way to go
would be to introduce appropriate markup constructs instead of
(mis-)using <t> and <list> for almost everything. But personally, I am
not yet convinced that there are strong reasons to do this. (And yes,
I have read the introduction.)

Note that I do not really plan to have a discussion on this here on
this mailing list. I am just giving you ideas to think about before
the bof so you can try to convince me (in case I end up in the bof
;-).

/js

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

---

From: "David Harrington" <[email-masked]>
Date: Wed, 28 Feb 2007 11:14:59 -0500

Hi,

While I wrote the Templates for MIB Documents to use an include
mechanism, I can see some benefit in writing the MIB module in XML,
with the intention of having xml2rfc process it into a document. 

The line length issue mentioned in Emile's document is a real
irritation, partly because the error reporting from xml2rfc is not
always good at identifying the line in the XML source where the
problem exists. XXE helps, but not totally.

So some people might prefer to write their MIB module in XML. I an not
yet convinced this is something the OPS area or MIB Doctors should
promote because I think there are likely to be problems with the
approach that will make it harder to write and review MIB documents. 

I suspect the requirement that the MIB module must be able to stand
alone from the rest of the document will probably cause problems if
writers try to utilize xml2rfc's and XXE reference handling
capabilities in the MIB module itself, but I suppose this is no
different than writing the whole document in a text editor.

I am happy to see people experiment with Emile's approach to see if it
makes life easier for MIB writers/editors and MIB Doctors.

dbh

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:[email-masked]] 
> Sent: Wednesday, February 28, 2007 10:35 AM
> To: STEPHAN Emile RD-CORE-LAN
> Cc: [email-masked]
> Subject: Re: [OPS-AREA] 
> draft-stephan-ops-xml-mib-module-template-00.txt:XML template 
> for MIB modules
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Feb 2007 09:27:14 -0800

> makes life easier for MIB writers/editors and MIB Doctors.

This is the sort of thing that a software tool should generate
from the SMIv2 source, so (IMO) we are dealing with implementation
details for that tool.  Since xml2rfc is essentially a mandatory
tool for IETF submission writers, it seems in scope to reach
some formal agreement on the 'feature-request' given to the tools team
for enhanced MIB authoring support.

> dbh

Andy

---

From: "STEPHAN Emile RD-CORE-LAN" <[email-masked]>
Date: Wed, 28 Feb 2007 19:08:51 +0100

HI,

First of all, thanks for reading and for reacting before the mini bof. That will improve the discussion in Prague.

Yours points of view cover the 3 major directions covered by the draft: the  IETF process for MIB modules standardization, the XML approach used and the the need of tying SMI and XML.

Regarding the IETF process, I have 2 concerns: 
	As more and more people are writing IETF document in XML, as RFC editor asks for the XML version of the draft if available, MIB editors need a comfortable way to edit MIB module part of the draft in XML too. I edit PCE WG MIBs draft in XML in that way; it works (see PCE DIS MIB below) without any complaint of Smilint. So there is not any side effect regarding MIB doctor tasks. 
	There is no other language inside the IETF standardization process than the SMI to encourage the specification of precise management object. So I propose to provide XML applications with the capability to load MIB module. 

Regarding the second point, it is clear the proposed XML template is just an overlay over SMI macros. So the intense usage of <t><list> is not elegant even if the Xpath may be reduced to //list[@smi]/list/t. On the other hand, as the SMI is already formal there is not a big benefit to double markups. 

Finally, several questions related to the need of minimum connection between SMI and XML:
*	Do we need to make MIB editing more friendly? What are the benefits of doing it?
*	Are there any protocols relying on XML data model that need to load, or that will take benefit of loading, part of MIB module for configuring or for monitoring? Is there something else proposed by IETF? 
*	Is that urgent? How are we going to deal with double management interface? Can we afford to go through a long standardization process related to XML SMI without providing some initial guidance and tools? 
*	Is this draft a first piece of the solution? What are the other pieces ?

 <<draft-ietf-pce-disc-mib-00.xml>> 

Regards
Emile

-----Message d'origine-----
De : David Harrington [mailto:[email-masked]] 
Envoyé : mercredi 28 février 2007 17:15
À : [email-masked]; STEPHAN Emile RD-CORE-LAN
Cc : [email-masked]
Objet : RE: [OPS-AREA] draft-stephan-ops-xml-mib-module-template-00.txt:XML template for MIB modules

Hi,

dbh

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 28 Feb 2007 20:43:02 +0100

On Wed, Feb 28, 2007 at 07:08:51PM +0100, STEPHAN Emile RD-CORE-LAN wrote:

> As more and more people are writing IETF document in XML, as RFC 
> editor asks for the XML version of the draft if available, MIB 
> editors need a comfortable way to edit MIB module part of the draft 
> in XML too. 

This is a claim for which I like to see substance. I have written xml2rfc
formatted documents that include MIB modules and I find it easier to write
the MIB module with my favourite editor, directly using all the tools I
have around to validate MIB modules and so on. Writing XML tags for all
the SMI constructs would have significantly increased the work. I like
to know why writing all this XML <t> markup should safe me any time.

> I edit PCE WG MIBs draft in XML in that way; it works (see PCE DIS MIB 
> below) without any complaint of Smilint. So there is not any side effect 
> regarding MIB doctor tasks. 

I works is nice, but not sufficient. What is the time saving?

> There is no other language inside the IETF standardization process than 
> the SMI to encourage the specification of precise management object. So 
> I propose to provide XML applications with the capability to load MIB 
> module.

Get your favourite SMI to XML translator and there you are.
 
> Regarding the second point, it is clear the proposed XML template is 
> just an overlay over SMI macros. So the intense usage of <t><list> is 
> not elegant even if the Xpath may be reduced to //list[@smi]/list/t. 
> On the other hand, as the SMI is already formal there is not a big 
> benefit to double markups. 

Here you contradict yourself. If the goal is to make SMI definitions
accessible to XML parsers, then it is pointless to say that all you get
is a bunch of <t> elements and you still have to parse the data contained
in the <t> elements.
 
> *	Do we need to make MIB editing more friendly? What are the benefits 

This is a very difficult subject since "more friendly" is difficult to
define and evaluate. For me, more markup is a waste of time; I would
prefer an approach which allows me to write less rather than more.

> *	Are there any protocols relying on XML data model that need to load, 
>       or that will take benefit of loading, part of MIB module for 
>       configuring or for monitoring? Is there something else proposed 
>       by IETF? 

There are tools out there that can translate SMI modules to XML documents
or even XML schemas. They have been used for years - running code. There
is not point in starting with another format of opaque <t> elements.

> *	Is that urgent? How are we going to deal with double management 
>   	interface? Can we afford to go through a long standardization 
>  	process related to XML SMI without providing some initial guidance 
>	and tools? 

The time it takes to standardize something depends on the energy behind
it. The question is whether enough people care about interoperability
here. 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.

> *	Is this draft a first piece of the solution? What are the other 

Yes. :)

/js