[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SMIng Requirements: a proposal
As I considered how to approach what I felt was a requirements document
that was on an information modeling tangent, and recognizing that there
are different segments of the WG trying to achieve different things, I
suggest the requirements document could be restructured to recognize
three different levels of requirements.
The most conservative approach does nothing except merge the
requirements of SMI and SPPI, and merge the SMI and SPPI extensions to
create one adapted-ASN.1 language which supports both sets of
constructs. The requirements document could start with defining this
minimal set of requirements.
The charter seems to add some requirements that do not appear to be
requirements for either the SMI or the SPPI, such as object-orientation,
reusable components, inheritance, association-level constraints, and a
starting point that uses a language not based on ASN.1, but which bears
similarities to C++ or Java. The requirements document could have a
section which discusses what would be necessary to meet these additional
requirements, beyond what is required to simply merge the SMI and SPPI.
The information modeling approach adds additional requirements, such as
support for methods and signatures, abstract classes, dependency and
aggregation relationships, constructor/destructors, and other features
needed to make SMING an information modeling language. The requirements
document could detail these additional requirements, beyond what is
required to achieve the goals mentioned in the charter.
By developing the requirements document to recognize these three
different approaches, the community can assess the costs and benefits of
each level of requirements, and can make an informed judgement as to
which approach we should take. If one of the easier approaches is
chosen, the requirements of the more full-blown approach could be kept
in mind, to allow a later migration to an information-model based
"Durham, David" wrote:
> I will also point out (chair hat on), that the charter supports choice (b)
> as well. I would suggest if the Requirements attempt to bite off more than
> required to support the stated goals of this WG the document explicitly
> states such variances within the context of a SHOULD or MAY, not a MUST. The
> WG will then decide on the merits of any such additional requirements. Seems
> to me that LDAP concerns are clearly out of scope, however.
> And a question (hat off): As for how Keys (for instance identification) are
> defined in the Requirements document, how is this concept any different than
> the semantic of the SMI INDEX clause today, or the SPPI's UNIQUENESS clause?
> > -----Original Message-----
> > From: David Harrington [mailto:email@example.com]
> > Sent: Friday, March 02, 2001 1:14 PM
> > To: Juergen Schoenwaelder
> > Cc: firstname.lastname@example.org; email@example.com
> > Subject: Re: SMIng Requirements: instance identification
> > Thank you Juergen.
> > I also am a member of (b), and have been trying to decide how
> > to respond
> > to the requirements document that has been getting written by
> > this WG. I
> > suspected we might be on the wrong path when we started from the NIM
> > requirements document.
> > It is my impression that the "requirements" in the current
> > document are
> > based on "how do we modify SMING to map to some theoretical
> > definitions
> > of what an information modeling language should be" rather
> > than "how do
> > we merge the SMI and SPPI to reduce the number of languages
> > that we must
> > master?".
> > I have had conversations at various times with Keith and with John
> > Strassner and with a number of other IETF leaders, representing many
> > "factions" that would be impacted, and I get the impression that the
> > consensus is that this WG is going about solving the problem in a
> > totally wrong way. What we seem to be doing is using the SMI
> > and SPPI to
> > develop a completely new (read additional) language that can be
> > converted into either SMI or SPPI. This means we will have THREE
> > languages rather than TWO. I guess I studied the OLD MATH rather than
> > the NEW MATH; I don't understand how going from two to three
> > reduces the
> > number of languages.
> > I suggest that what we should be trying to do is to have ONE language
> > that can express the concepts of the SMI and the concepts of the SPPI,
> > and possibly other languages we choose to add later, and can convert
> > from that one language directly into the corresponding PDU encodings
> > without the intermediate step of converting to SMI or SPPI. In other
> > words, we should be developing a REPLACEMENT language, not a
> > supplementary language.
> > If we feel that compatibility with existing MIB compilers is important
> > to simplify deployment (and I do feel that may be important), then we
> > should be developing a replacement language which is a
> > superset of SMIv2
> > and SPPI, so existing tools (especially MIB compilers/importers) will
> > only require modification, not total replacement.
> > Let's stop designing an information modeling language and
> > strat merging
> > SMIv2 and the SPPI.
> > That's my $.02
> > dbh
> > Juergen Schoenwaelder wrote:
> > >
> > > >>>>> Andrea Westerinen writes:
> > >
> > > Andrea> In the end, these requirements need to reflect two points of
> > > Andrea> consensus: 1. Is keying part of the model/language or is it
> > > Andrea> part of the mapping? 2. If it is part of the model, what
> > > Andrea> keying approach lends itself to the broadest possible set of
> > > Andrea> mappings?
> > >
> > > Even though I am now drifting into a different subject: The real
> > > fundamental problem I have with the implicitly stated goal
> > of "meeting
> > > the broadest possible set of mappings". This points to a fundamental
> > > difference between two groups of SMIng folks:
> > >
> > > (a) There is a group of people who want to define a universal
> > > information modeling language which supports "the broadest
> > > possible set of mappings".
> > >
> > > (b) There is another group of people who are much less ambitious.
> > > They simply want to primarily merge and replace (!)
> > SMIv2 and SPPI
> > > in order to (i) reduce the total number of langauges we have by
> > > one and to (ii) reduce the total amount of work which
> > is spend on
> > > definiting MIBs/PIBs in the IETF and elsewhere.
> > >
> > > Depending on which group you belong to, the requirements look pretty
> > > different. I personally belong to group (b) since I believe this is
> > > the only complexity we can seriously handle.
> > >
> > > I can only encourage people to try to take a MIB or PIB and
> > to rewrite
> > > it in such a way that all protocol related things are not visible in
> > > the core data definition anymore and that the data
> > definitions can be
> > > mapped on both protocols equally well. My personaly experience with
> > > trying this on some examples was interesting and a real eye opener.
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder Technical University Braunschweig
> > > <firstname.lastname@example.org> Dept. Operating Systems &
> > Computer Networks
> > > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106
> > Braunschweig, Germany
> > > Fax: +49 531 391 5936
> > <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>
> > --
> > ---
> > David Harrington Network Management Standards Architect
> > email@example.com Office of the CTO
> > +1 603 337 2614 - voice Enterasys Networks
> > +1 603 332 1524 - fax Rochester NH, USA
David Harrington Network Management Standards Architect
firstname.lastname@example.org Office of the CTO
+1 603 337 2614 - voice Enterasys Networks
+1 603 332 1524 - fax Rochester NH, USA