Re: SMIng Requirements: instance identification

[David Harrington <dbh@enterasys.com>]

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
> <schoenw@ibr.cs.tu-bs.de>  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
dbh@enterasys.com           Office of the CTO
+1 603 337 2614 - voice     Enterasys Networks
+1 603 332 1524 - fax       Rochester NH, USA