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

From: "Bill Fenner" <[email-masked]>
Date: Thu, 1 Mar 2007 20:18:46 -0500

I've thought about this issue a fair bit, and I've always thought that
the right answer is  to edit the MIB in an XML schema designed for the
SMI, and if necessary xslt it to some presentation format.  The format
described in Emile's document is the output of this transform, not the
right format for composition.

I wrote some nroff macros a few years ago to help with MIB writing;
they automatically assign OIDs, automatically generate the SEQUENCE,
fill in default values for STATUS and MAX-ACCESS, etc.  Those are the
kinds of value that I see getting from a SMI-aware composition
language - not the encapsulation of the textual version of the SMI in
formatting methods that weren't designed for it.

  Bill

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 1 Mar 2007 19:08:21 -0800

Hi -

> From: "Bill Fenner" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, March 01, 2007 5:18 PM
> Subject: [OPS-AREA] Re: draft-stephan-ops-xml-mib-module-template-00.txt: XMLtemplate for MIB modules
...
> formatting methods that weren't designed for it.
...

Having a way to *allow* the text formatting tool to handle the layout of
DESCRIPTION clause text (but within the stylistic conventions common
for MIB modules) is probably the biggest time-saver; ensuring
uniform indentation of the other parts of OBJECT-TYPEs probably
the second biggest.  I was able "persuade" nroff to assist me, but had
no such luck with xml2rfc.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 Mar 2007 19:50:07 -0800

> right format for composition.

Exactly.
The format for composition should be plain SMIv2.
Back when I wrote MIBs (before xml2rfc), the
nroff nonsense often took as much effort
as the rest of the SMIv2 section.

Asking a human MIB writer to generate the sort of markup that is proposed
in Emile's draft is a non-starter.  Asking a human tools writer
to generate this markup for a given SMIv2 module is a good idea.
The actual tags (e.g., <t>, <list>) should only be of interest
to the tool developers.

> formatting methods that weren't designed for it.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Mar 2007 19:35:31 +0100

> The actual tags (e.g., <t>, <list>) should only be of interest

It is relatively trivial to write an smidump backend that spits out
lots of <t> elements. But I still do not get the idea why this is
useful. If the SMIv2 module is written in SMIv2, what is the value of
turning this into XML and use a complex formatter to turn it back into
SMIv2? Including MIB modules into xml2rfc works fine for me as does
writing the whole MIB module within an <artwork> element. I simply do
not see the added value.

Concerning MIB authoring support with autmated numbering etc: There
are (programmable) editors which can help people who find it too hard
to write out the SEQUENCE definitions or to do the renumbering. If you
are concerned about pretty printing, there are tools readily available
for this. Perhaps all we need is a list of tools that people should be
aware of instead of creating yet another new technology for a problem,
which I believe has already many solutions, addressing the various MIB
editing styles people tend to prefer.

/js

PS: I do not mind if people hack xml2rfc so that people can write up
    tons of <t> elements; this is yet another way of doing things and
    this is fine if people like it. I do have a problem, however, if
    such an editing format is being advertised as a format that one
    has to use in order to drive whatever tools; in that case, I
    strongly prefer to keep SMIv2, the standardized source format for
    SMIv2 MIB modules. If the goal is to abstract from SMIv2 specific
    and to reuse definitions across management interfaces, then people
    should recall the SMIng effort and see whether something can be
    learned from that.

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 02 Mar 2007 11:05:01 -0800

> writing the whole MIB module within an <artwork> element. I simply do

I was not aware that xml2rfc can generate cross-linked HTML MIB documentation,
and include SMIv2 modules without any editing required.  As I said,
I don't write MIBs anymore.

Andy

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Mar 2007 21:33:39 +0100

On Fri, Mar 02, 2007 at 11:05:01AM -0800, Andy Bierman wrote:
 
> I was not aware that xml2rfc can generate cross-linked HTML MIB
> documentation, and include SMIv2 modules without any editing
> required.

Including worked for me the last time I did a bigger MIB module, but
that is some time ago as well. For smaller ones, I just write them in
the <artwork> section, using tools to extract them from the xml2rfc
output format and to do checking etc. (actually just a few make rules
and all from within emacs, but that is personal preference).

xml2rfc does not generate cross-linked HTML MIBs and I doubt it very
much that <t>SYNTAX InterfaceIndex</t> is helping much in doing so.
(But there are tools that generate cross-linked HTML pages; they
probably exist for more than 10 years now.)

Again, I do not want to give a negative impression; all I want is that
people pushing for new network management work come up with a clear
statement what the problem is that is being solved, why existing
solutions do not adequately solve the problem, and what the benefit is
of solving the problem in the first place in the IETF (and I am sure
that ADs will also ask who is committing time to write and review
docs).

<soap>
  IETF processes are heavy weight and expensive; so there must be a
  very good reason to start something. If people just need a tool, get
  a few people together to simply code it up; ideally it is running
  code that drives standards; creating standards to encourage tool
  development may not work that well.
</soap>

/js

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