RE: sming meeting minutes draft... Questions for the wg.

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

> -----Original Message-----
> From: Andy Bierman [mailto:abierman@cisco.com]
> 
> At 01:53 PM 12/16/2002 -0800, Durham, David wrote:
> >Originally there was much excitement around the smi-ds proposal from the
> wg
> >participants. Now that we are peeling back the onion a bit I think we are
> >seeing some of the complexities of this approach emerge, and we are
> >experiencing some notable feature creep as well. So I wonder if the wg
> >sentiment is cooling and why. Two fundamental questions that I would like
> >people to (quickly) respond:
> >
> >Are people still interested in perusing the hierarchical instance naming
> >using oids as proposed in the smi-ds document?
> 
> I don't think you understand the significant feature of SMI-DS, which
> is the ability to create hierarchical data structures in the first place.
> The ability to name that data in a manner consistent with the hierarchy
> is a secondary feature.  The use of OIDs is pure SNMP baggage.

[DaveD] Yes, it allows hierarchical data structures, so did the nmrg
proposal. They both enable reuse of hierarchical data types as well. Smi-ds
added the benefits of embedding arrays and unions and changed the
interpretation the oid namespace to better accomplish this. 
> 
> I believe that the data structures that SMI-DS allows are very common
> in network management and need to be better supported.  The concept
> of a list within a list shows up in many applications. This is currently
> handled with a subordinate table or a hack like SnmpTagList (RFC 2573).
> 
[DaveD] I couldn't agree more. Though I would like to hear from others.

> If the WG does not believe better data modelling capabilities are
> needed in the SMI, then we should know that now (better late than never).
> Perhaps XML data structures and XML Schema should be used instead of
> SMI-DS. I think either SMI-DS or XML represents a significant advancement
> over the data modelling capabilities of SMIv2.
> 
[DaveD] This is the key question, isn't it? Should the smi mib evolve and
continue to be the nm data model for the IETF in the future, or should we be
migrating to something else? 
> 
> >Are you interested in helping by being an editor on one or more of the
> >documents listed below?
> >
> >
> >If feature creep and gratuitous changes are the only issues, that is
> >fixable. I want to understand if the fundamentals of the smi-ds proposal
> are
> >still viable and have wg support.
> 
> Can you enumerate any specific examples of feature creep in SMI-DS?
> The changes made over time have been a direct result of WG comments
> and do not represent new features.
> 
[DaveD] I wasn't accusing smi-ds of feature creep here. The open issues list
contained things such as syntax changes, support for XML-style names, XML
namespaces, etc. Ignoring these, I am interested in people's current
feelings on the fundamental approach taken in the last smi-ds proposal.
> 
> >-Dave
> 
> Andy
> 
> 
> 
> 
> 
> >> -----Original Message-----
> >> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> >> Sent: Monday, December 16, 2002 4:48 AM
> >> To: Durham, David; sming@ops.ietf.org
> >> Subject: RE: sming meeting minutes draft...
> >>
> >> I'd like to get a few more details on this (I think we got them
> >> at the meeting):
> >>
> >> > Revisited Charter and Milestones. Updated charter was put on
> >> > the mailing list. No issues raised on the list, no issues
> >> > raised at the meeting either. According to the charter
> >> > milestones we are a year behind. The original milestones
> >> > assumed the nmrg documents which were complete, but the wg
> >> > chose to investigate the smi-ds route. We will still need a
> >> > few iterations on the smi-ds/v3 documents before they will be
> >> > complete. The current proposed list of documents in priority order
> is:
> >> >
> >> > -        1. SMIv3 Language Definition: Andy Bierman
> >> > -        2. Capabilities MIB: Andy Bierman: DONE
> >> > -        3. SMIv3 Guidelines
> >> > -        4. Transition from SMIv2
> >> > -        5. SMIv3 MIB Modules (core types)
> >> > -        6. INET Modules (textual conventions)
> >> > -        7. RFC 2580 Conformance Updates
> >> >
> >> > We need volunteers for the documents or the wg will shut
> >> > down, and the smi will not progress. Previous volunteers for
> >> > the guidelines and transition documents are waiting for the
> >> > language definition. In principle, people support the smi-ds
> >> > work, but we will need people to sign up to get the work
> >> > done. Likewise from the discussion at the wg meeting it seems
> >> > that there is a lot of waffling on how we proceed item by
> >> > item through the open issues listed below.
> >> >
> >> My understanding at the meeitng was that Andy un-volunteered for some
> >> docs. And so I like to clearly understand who is currently volunteer
> >> for what. I also like to see commitments as follows:
> >>
> >> - Volunteers to commit to deliver a reasonable revision of the
> >>   document they volunteer for
> >> - From the WG to do serious review and to provide serious input
> >>   for the editors and the chair, so that we can get to consensus.
> >>
> >> The lack of WG participation and the lack of enthusiastic volunteers
> >> for all documents does not bode well. And as David said, we're
> >> already 1 year behind schedule.
> >>
> >> Thanks, Bert