RE: WG Last Call draft-ietf-sming-reqs-04.txt

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

On the issue of specifications for the language, I believe that
the current non-conformance problems that we see with SMIv1 and
SMIv2 are due to:
  1) the approach of using a base specification (ASN.1:1988) and
     a delta specification (RFCs 1155, 1212, and 1215 for SMIv1,
     and RFCs 2578, 2579, and 2580 for SMIv2). An implementor of
     a MIB module parser had to read the ASN.1:1988 spec (and
     understand it), then read the delta documents, and then
     figure out how the two went together. There were 
     misunderstandings of ASN.1:1988 by
     the original authors of the RFCs, and adaptations due to
     usage. The result is that SMIv1 is not very well specified,
     SMIv2 is much better specified, but it still has a few holes
     due to the approach. Bottom line: the approach made it much
     harder for implementors of parsers.

  2) No early, easy to use, and correct open source implementations
     of MIB module parsers. MOSY was the only thing available in the
     beginning. It wasn't correct, and wasn't "complete" in its
     checking. The result was that parser implementors started from
     scratch, and many got pieces wrong. Writing a robust parser
     including semantic checking is a lot of work. It is at least
     an order of magnitude harder than a parser created in a
     Compiler course of a university. It is a lot more than
     writing YACC and LEX specifications (or specifications for
     your favorite parser generator tool).   

  3) There was no conformance specifications for parsers. And there
     was an attitude that conformance specifications were inappropriate.
     The result was that there was nothing that could be used
     to beat up implementors of bad parsers. There was way too much
     ambiguity in the SMIv1 specifications, and there was little
     motivation to correct bad parsers.

  4) There was no test organization that tested parsers. This would
     have helped resolve in the SMI a) the ambiguities, 2) the
     inconsistencies, 3) the incompleteness, and 4) the lack of
     understandability. We have seen this with other technology
     specifications, that having a good testing facility improves
     the implementations and the specifications.  

So, I support a having a complete specification for SMIng in a
single document. However, I do not believe that this requirement
is sufficient to result in good implementations of parsers.

Regards,
/david t. perkins