FW: sming wg meeting minutes from the 53rd IETF:

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

-----Original Message-----
From: Durham, David [mailto:david.durham@intel.com] 
Sent: Wednesday, April 03, 2002 10:44 PM
To: sming@ops.ietf.org
Subject: sming wg meeting minutes from the 53rd IETF:


SMIng minutes from the 53rd IETF WEDNESDAY, March 20, 2002 1530-1730:

Minutes reported by David Durham.
Special thanks to Ravi Sahita for taking minutes during the meeting.
David Durham chair.

- The chair presented agenda and a list of doc status.

- The status was that the wg was behind in its schedule. There are 2
proposals still in progress: SMI-DS and the NRMG SMIng proposal.

- The chair wants to see more people involved in discussions on the mailing
list.

* Andy Bierman presented v02 (third rev) of SMI-DS. SMI-DS provides improved
data modeling capabilities to express nested data structures using a
hierarchical oid namespace. This allows set operations to be made easier;
also one can avoid race conditions in get operations. This update improves
on the naming scheme to retain compatibility with SMIv2, but also allows
more containment layers. We can take advantage of these data definitions
with SNMP today but more protocol operations are needed to move aggregate
data around in one transaction.  To accomplish backwards compatibility, the
instance ids are now over to the right, so the SMIv2 index is still in the
same place.

Andy has added some new clauses like OID POINTER, UNIQUE-SCOPE,
SPARSE-AUGMENTS. Also added the notion of runtime retrievable conformance
information which implicitly maps to the mib instance data. Andy mentioned
Juergen was arguing that this same functionality could be better achieved by
just adding more mib objects or separate capabilities data as in the
Framework PIB. 

AUGMENTS has changed significantly. One can't augment types anymore, which
is basically retained for backward compatibility with SMIv2. 

Hierarchical instance naming has been changed to preserve SMIv2 objects, so
one can go from SMIv2->SMI-DS->SMIv2 and nothing is lost. However, to use
new features in SMIv3 and to go to SMIv2 can be done but it's not going to
be transparent. Still, the instance level supports nesting in order to move
aggregates around. Now SMI-DS OIDs can coexist with SMIv2 since the static
portions are identical. Nesting level 0,1 are identical, where levels >1 are
concatenated  to the RHS of the OID name. The static portion is registered
so that SMIv2 still works. Andy presented an array in array example with
types W, X and Y1 and Y2, with Y1 and Y2 nested in type Y. All instance ids
are moved to the right hand side. Each time a nested node is added a static
node is added to the oid. When getting such a type, you get all instances of
W first then all for X then all for Y1 and then Y2. Chair asked what this
means for getnext? Andy replied that you get column first order, and for
nest level upto and including 1, you don't change from the SMIv2 (achieving
backward compatibility). One can reuse the nested containment as the entire
struct can become another member within another structure including its
statically defined sub-oids (starting from the root static oid of the
containing structure).
 
A Conformance Level was added. This is a scalar number implicitly associated
with the corresponding instance data. Its purpose is to describe at runtime
the conformance level a particular device supports corresponding to a
particular mib structure. The challenge here is dealing with variance across
boxes... agent caps aren't available on the boxes previous to row
creation... so one wouldn't know what's available on the box initially.
Also, sometimes mib objects have no conformance levels, so this scalar will
be unused. The objects could also have min/full conformance associated with
a mib object.
Sharon asked how do to use this? Andy said these are psuedo mib objects for
real mib objects. Sharon - isn't a better approach to backoff if there is an
error? If the node subid is 0, that could be the anchor point of the
compliance section. Sharon- And that provides a mapping to the compliance
stmt in the mib? Andy-the conformance info struct has 4 objects,
confModuleCompliance - this tells what version the agent complies with,
confLevel - has confVariation - has syntax clause of object, confVarDesc -
description where variation of an agent caps/desc of object clause of a
module compliance macro. comment-Is this for runtime agent capabilities?
Andy gives an inet address example. You can add enums with syntax clause and
you can document if you need more.
Dave Perkins noted that this was examined with snmpconf, which found this
approach doesn't work. The fundamental thing was module compliance is better
known than agent caps. There's no requirement that you have module
compliance in a mib module. Besides you can have multiple mod comps. Though
compliance could give a range, you don't know where in that range of
behavior the person has implemented. You can only assume the min of the
specific value. Andy responded that's what 'other' is used for, to specify
exactly what you implemented. DaveP had two issues with this - Issue1:
Whether your behavior matches the defn of the object or the defn of the
application. Issue2: Does it comply with conformance or not? You don't have
to have a modcompliance in a MIB. Bert noted that you can leave it out but
another doc must be submitted which does compliance. Andy thinks this is the
80/20 kind of thing, there may always be other corner cases. DaveP - I agree
this is needed - but need to work out the details. Others firmly support
having this capability and Andy noted that a lot of work is done by app
developers to understand different versions. 
The issue then came up how would one use read-create, how would one say he
wants create and go and won't accept create and wait? Basically what if one
wants to see if rowstatus has been lowered to accept only create and go.
Andy replied that we would need to use Sharon's style where we do
conformance by a new subtree. Randy suggested that, like the app mib, it
would force the different vendors to implement same level of conformance.
Andy replied that if you have an oid with more than those subids, it can use
lowest prefix match. 

OID pointers discussion followed. Basically Andy provides the concept of
typed pointers. He gave an example from RMON with a syntax pointer to
<type-name>. DaveP wanted to know how would one do 'data source null' with
this concept of pointers? Andy - Are you asking how do I put a 0.0 in there?
DaveP - No, reporting that information. Andy hasn't I thought that thru. 

Uniqueness: Andy believes it is a non feature of the SMI to force uniqueness
in the index. It makes things complicated, things have to be unique within
internet/admin domain/device - or not unique.

SPARSE AUGMENTS: Array variables can be augmented. Sparse augments has a
sparse condition which is a textual clause that is machine readable via
SPARSE-EXPRESSION keyword.

As for mapping SMI-DS to SMIv2: One can go back but the process won't be
transparent. Randy wanted to know how this oid naming is different from
SMIv2? When you flatten out the indices, it comes out the same on the wire.
Andy said it's not the same... You have different root oid in the SMI-DS
case... Same semantics but not the same oid numbers.

Open issues discussion:
* Merge SPPI? MIB readers read MIBs, tool developers need to read SMI, we
can define rules for mapping these; not protocol mappings like in SMIng.
* Syntax? SMIv2-like? Java-like? XML?
* Terminology? SMIv2-like? OO-like?
* Module COmpliance? - Needs to be variably declared, not per accessible
object descriptor. - max access should not be in typedefs. Example-
counter32 cannot be more than readonly access.
* Implied runtime Conformance info or just add more MIB objects? Andy and
room seem to be leaning toward the just add more mib objects approach, not
the implicit mapping Andy added to SMI-DS.
* INDEX clause issue. Issue was should it be defined inline per attributed
within the data definition (implied) or should it be outside akin to SMIv2.
After some discussion, people seem to prefer keeping the SMIv2-like INDEX
clause because this allows more flexibility in how one defines the index.
* SPARSE-EXPRESSION condition syntax. Suggestion to make this a simple
boolean expression.

Bob asked as this evolves for compatibility etc, do you have an assessment
on your effort to make mib modules easier to read? Andy replied that he is
assuming the writer is familiar with struct, union, typedefs, arrays etc.
You can refine a base type and that's it. This gives us more building blocks
and achieves a higher level of reuse. It will certainly eliminate a lot of
cut and paste. Randy noted that reuse doesn't necessarily make it easier to
use. That presupposes an ability to find out what to reuse.  Reuse is great
but not making a connection between this and a newcomer using this is bad.
Steve thinks we are focusing too much on a newcomer. He might go read
InetAddr in a doc and if it's named correctly - he can deal with it
properly. Randy replied that you have to know to look for it. If I'm dealing
with x.25, someone would have to find x.121 for me. How do I know x.121
exists? Jeff believes this is an age old discussion. When you repeat text by
value it's easier for newcomers, text by reference is easier for people who
know. Andy said that regardless, code/semantic organization is required in
some way. Wes- agreed that reuse makes it easier to write, and 9 out of 10
questions about the SMI are how do I put a table in a table. SMI-DS makes it
much easier for new authors to be able to do what they want to. Steve also
agrees that reuse promotes not re-inventing which is a good thing. 

SMI-DS Syntax Discussion: 
Randy believes that syntax is just a user interface issue. Andy thinks it is
naive to think anyone going to use this is immune to knowing SMIv2, You will
always have to know the syntax of those MIBs that exist today. Andy pointed
out that when going from v1 to v2 things were transparently compatible,
without changing anything on the wire. 
It was asked that given in the mib objects there is a syntax current clause
- can that be made default? Andy responded that he thought that is a 2nd
order issue. He is trying to reduce pages of text... To avoid repeating
descriptions via constructs like unions and structs. 
Bob wanted to know if we're making any progress - are there any benchmarks
to measure our success? Randy though that this could this be a good project
for a focus group of college freshmen? Andy thinks it's all subjective,
Steve makes a good point, once one looks at a definition once, having
containment and C like data structures, he doesn't care what the structure
of some sub-aggregate is. This search to find out if this MIB is
appropriate, shifts them away from the real problem. Once can see this
problem in code with seven different versions of strcpy. Steve mentioned
that when we talk about metrics we should consider code size of agent
implementations, but Randy believes that depends on how optimized your code
generation process is, how much redundant code is generated.

Dave went on to recap the NMRG proposal looking at some of the differences
between it and SMI-DS. For one, sming allows hierarchical data structures
without first assigning oids to them. So you can map to tables and protocols
like COPS etc or even to XML. On the negative side, people felt they have to
do twice as much work because assigning oids was another separate step.
Andy's proposal added relative oids to the reusable data structure
definitions. Andy pointed out that theoretically we have protocol
independent MIBs and MIB independent protocols, and SMI solves this so that
the writers don't have to do this every time. It was also pointed out that
mapping of pointers to data structures were causing problems when mapping
pointers to oids and the corresponding instance space in the sming proposal.
The syntax of the NMRG proposal was made to look more like C to make new
comers feel readily familiar with it. Also, the NMRG proposal has provided
an abnf grammar for the language. Andy said he would get to an abnf for
SMI-DS later. 

What followed was a formulation of questions for consensus on four issues,
1. hierarchical oids for N levels of nesting 2. level of reuse/independence
of oid naming from the data structure definitions. 3. Support of multiple
protocols. 4. Syntax. The consensus of the room was determined, and these
same questions will be asked on the mailing list.

Starting with hierarchical oids, Dave asked if we want to do hierarchical
oid format as in SMI-DS? Sharon pointed out that we need to be aware that
we'll break a lot of apps. The manager side needs to be aware if this is
done in existing mibs for example if she is querying ifTable. Andy believes
this will be a new mib then. Steve asked Randy that if you take ifTable, if
he augments anything in the table with hierarchical naming, would he agree
that if.12 can do whatever it wants? Randy agrees as long as the oid for the
augments does not end up being a subtree of the tree being augmented the
manager can do a getnext and not see this new tree. Andy mentioned that we
had the same problem with Unsigned Int64's. The code that understands the
foo mib is the only one that knows what the instance id is. Randy pointed
out that if you have an existing mib and doing a mib walk this is not going
to affect that. Sharon thinks this is good but it needs to be spelled out
clearly in the doc. Jeff agrees SMI-DS is good and for this particular
issue, if we generalize this from 2 to N dimensions, there are benefits. So,
Jeff's strongly in favor of Andy's proposal for hierarchical oid support and
would go to the Nth degree (levels of nesting). 
	
*** The consensus of the room was unanimous that n-levels of nested data
structures via hierarchical oids should be supported by the SMIng.

Next the chair revisited the issue concerning flexibility of reuse: 
Andy pointed out that the issue is code design in general... a container
which represents one instance in general or you typedef the array and reuse
by reference. Randy pointed out that in the SMI-DS definition when Andy
defines an array and the index is a foreign key, you could get into a
scoping situation. But he thinks that issue has pretty much gone away now.
Andy said what Randy really wants to do is contain the structs and n would
go to 3 instead of 2 and it would no longer be transparent. Dave pointed out
that what Juergen was saying was that for backward compatibility you may
want to map new structured data to existing flattened tables. Randy raised
the issue of having elements in index clauses which were not an element of
that struct. Jeff pointed out that if you change the index, then you should
deprecate the table and start over again. 

*** The conclusion was that 100% coverage for all cases of reuse is probably
not achievable. Juergen should clarify the advantages of mapping abstract
hierarchical data structures back to existing flatten mibs. No consensus can
be determined until we clearly formulate what this concept is here. 

Next addressed was the issue of dealing with multiple protocols:
The chair asked if the wg wants to consider things like mapping to a
standard CLI? Andy would like to  keep the charter focused to map to COPS-PR
and SNMP.  He thinks the objections are for having MIBs and PIBs, so we
instead have one underlying schema that gets accessed in different ways. But
we need someone from SPPI side to solve the COPS-PR mapping. dbh noted that
one of the things that came up previously in this wg were methods- looking
at CLI, it does work like methods. Steve however wonders if CLI ops are row
adds to tables so if you think along those lines it gets simpler. 

*** The conclusion was that we should focus on SNMP as a wg, and someone
should do a COPS-PR mapping. CLI and other such mechanism should not be our
focus at least initially, particularly given the lack of a standardized CLI.

The next issue was around what to do concerning syntax:
Should we keep SMIv2 Look & Feel? or switch to XML or a more Clike syntax? -
Newer people might be familiar with something more mainstream such as these.
There was general agreement to defer this discussion till later. Still the
question remains as to what the proposals are going to use for the time
being? 
Jeff believes we need a direction, Randy is right in that syntax is boring
but he thinks we should follow Andy's proposal. It was also pointed out that
we have to think in terms of what tools are currently available... - by
keeping the SMI consistent - we have several available tools. By using XML
there are also tools out there. By switching to something else, someone will
have to develop a compiler and toolkit for it. 
Randy wants to keep the discussion focused on modeling issues and protocol
mappings etc. Notations that diverge too much from what is in the SMI is not
good. We should focus in the semantics of things, then, we can decide on the
syntax. But he would like to keep things focused on functional issues.
Bob agrees with what Randy said. - Believes that long-term we would be
better off getting away on our own private set of notations and tools. It
would be nice if we all use the same set of tools.
There was a comment that SNMP and SMIv2 are being extended for use in telco,
and this looks like its getting too complex, meaning the problems are
complex in telco and SMIv2 seems to be getting complex also to deal with it.
Randy pointed out that GDMO is hard to understand since there are templates,
that have behaviors, that have external objects- this promotes reuse and
modular code but you need a very powerful browser, unless you wrote it you
won't understand it. Bert wondered if this is an issue of the design or the
complexity of the data? Randy thinks it's due to excessive modularity. Andy
doesn't want to make SMI-DS any more complex that it is right now. He has
seen some easy to understand code and some hard, so complexity is in the
hands of the designers. He thinks another syntax that would be workable
would be XML.
Wes pointed out as Andy has repeated many times - make it easy for the
majority. There are 3 groups of people that would comprise this majority.
Those that write mibs, those that implement them - these guys understand
c,C++,java, and then the group that read the mibs. The latter has two
subgroups, the manager app side and the n/w admin, who wrap their head
around them to use them. He doesn't think C is perfect for both ends. He
doesn't think English is perfect for both ends either. We should not do what
CIM did in reusing everything. We shouldn't go overboard with OO and reuse. 
Jeff noted that he'd like to support the growing consensus that we continue
with SMIDS/SMIv2-like syntax, focus on features, and near the end decide for
XML schema or SMI or something else. Changing other things will not make a
difference, what makes MIBs difficult to write are the rules we added. C
programmers can map { to BEGIN and } to END - so Jeff suggests we keep the
syntax as close to SMIv2 as possible. 

*** The consensus of the room was to continue using a SMIv2-like syntax for
the time being.

The chair asked if there was support for holding an Interim meeting. Roughly
10 people responded they would attend an interim meeting for SMIng to
progress. 

-End of session-