RE: SMIng Requirements: instance identification

["Durham, David" <david.durham@intel.com>]

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?

-Dave

> -----Original Message-----
> From: David Harrington [mailto:dbh@enterasys.com]
> Sent: Friday, March 02, 2001 1:14 PM
> To: Juergen Schoenwaelder
> Cc: andreaw@cisco.com; sming@ops.ietf.org
> 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
> > <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
> 
>