SMIng Meeting Minutes from IETF55:

TUESDAY, November 19, 2002 Time: 1930-2200
Minute takers: Ravi Sahita
Minutes reported by David Durham
WG Chair: David Durham

Issue: Updated documents have not been produced. We need volunteers to 
progress the SMI-DS related document set. Need more participation on the 
mailing list.

Chair:

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 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.  



Wes Hardaker presented SMIng enhancements that would be useful to his OOPS 
proposal:

Nested data structures such as Subarrays in arrays (eg. where you can have 
multiple interfaces and multiple addresses assigned to each 
interface) make indexing subelements difficult. Wes proposes that 
internal indices are given a local number. Advantage is that we have a 
local index to it including external indexes. This enbables all 
elements to be mapped to an OID.
Something like:
	INDEXS otherIndex
	FROM otherTable ::=  {base 1}

What does this have to do with the SMI: If you pick an augmentation 
table.  Not a problem for previous SMI structures, but problematic to have 
nested structures because need to go down to the index. 

There was a lot of discussion whether or not this is useful. It 
provides a way to separate the data instance index part of the oid from the 
data type part of the oid. There was concern that this mechanism would 
affect transpartent forward translations from SMIv2 MIBs, but this will 
apprarently only affect new SMIv3 definitions where there is nesting and not 
SMIv2 stuff. Andy made it clear we should only have one version of the SMI 
and not create the need to continually support two versions. There was no 
consensus in the room that Wes's proposal was a necessary or 
appropriate language mechanism. Wes was to post to the list some cases 
where this is valuable, removing oids where possible, to better support 
compression because his new PDUs have a base root oid. 


Next it was pointed out that external augmentations are a pain from the 
protocol's perspective with multiple random OID assignments.  Any chance we 
can fix this in SMIv3 via a forced local extension node?: Currently, if the 
agent doesn't have the MIB definition locally, the agent needs to 
interpret the oids without the MIB. One thing that makes 
augmentation tables difficult is that if you don't know an agent 
supports the table you wouldn't know to get it. It helps 
understanding for those who are trying to query agents.  Andy pointed out 
his original proposal fixed this by having a 0.enterprise ID where you 
could augment right inline the oid hierarchy, but this went away when the 
indices were all grouped back on the right of the oid to preserve 
forward mapping of existing tables. Wes proposes that this is only for new 
structures in SMIv3, but Andy believe we really need to go back to 
understand the importance with the forward translation because we don't 
want to have two versions of the smi going forward. The purpose is to make 
the new oops protocol mappings work better with SMIv3 structures. 

Again, there was no consensus in the room around this proposal. More 
thought is needed to fully understand what the problem is before we add 
more syntax to the smi, and Wes volunteered to elaborate on the problem on 
the mailing list.


Next, Wes suggests that smiv3 notifications should be able to contain 
structs and possibly even arrays. Currently only support for single 
objects.  Example: would like to be able to send all addresses 
associated with linkup.  It would be nice to support new 
notifications with more complex/complete data (like syslog). The limited 
data that snmpv3 notifications support is a reason why operators use 
prefer to use syslog instead of snmp. Wes is trying to define new PDUs to 
make access to new more complete structures easier.  This affects smiv3 
because notifications would now be able to support aggregate types 
instead of just base types, but this would not be backwards with snmpv3. 
There was more support in the room for this proposal over the rest, 
however, enabling backward compatibility w/ snmpv3 requires more 
thought. Others concluded that a similar result could be achieved if 
strings are used and a standard syslog-like string format were 
defined... No changes would be required to the language or snmpv3 to 
accomplish this.

Andy Bierman presents the SMIv3 Open issues:

* NULL choice for union types:

Like and SQL NULL value. Want to be able to create a template for a 
generic table (eg. RMON control entry)... can create an instance of that 
table and leave out stuff that you didn't need in your usage scenario. In 
sming it was implements X and implements Y but not Z, which is like 
partial inheritance.  Instead, he proposes the parent gets to tell you what 
it can pick and choose, so it's not equivalent to partial 
inheritance. Still, Andy is not convinced that this is worth the trouble it 
might cause. 

* Oid naming for aggresgates and sub-aggregates:

How to tell you want to access row three down in the second nested array. It 
was previously suggested having a zero to apply on the left to 
distinguish the constant part from the instance identifier part. If have a 
nested array want to get internal array now. Want more granularity to get 
one object or get everything. This may be a moot point if the protocol 
changes, and you don't get the support in SNMPv3 for it, so you only 
support the fancy new aggregate new stuff with new protocol.  Also 
weren't sure if adding .0's everywhere is backward compatible. Other 
organizations have oids with 0's in them. For example, the IEEE 
sometimes defines their own mibs, such as for the 802.1X protocol. The OID of 
the IEEE 802.1 branch for mibs is { iso(1) std(0) iso8802(8802) 
ieee802dot1(1) ieee802dot1mibs(1)}, so every mib put out by the IEEE 802.1 
group will have a zero in the OID. The only rule currently is that the last 
subidentifier per object can't be 0. 

Andy would advocate doing new things with the new protocol and not trying to 
retrofit into the existing SNMPv3 protocol. They should still work with 
snmpv3, but they will be suboptimal there.

The issue was raised that when you have multiple levels of nesting in your 
oid, then your encoding rules either result in ambiguities or 
undesirable behaviors in get next and get bulk. Andy believes that if you 
are trying to get a leaf, and all the indices are on the right, there are no 
ambiguities.  The suboptimal behavior of get next is the same bad 
behavior that we already have today. The orders that we got were always 
suboptimal. Getting rows would be correct, but we instead get the 
columns. Still, the worst case and the specific issue was poor behavior 
with unions, because the order is questionable. 

The question was raised: Why not having a separate branch for all new 
SMIv3 structures. Having naming that is helpful to us instead of being in 
the way.  If you have only one layer of nesting then it falls out that the 
indices are on the right, because they are in the right place anyway. 
Bring this to the list, too complex to deal with now. Juergen 
previously had objections to putting the new definitions under a new 
branch, he thought it would break things. Others point out that 
changing the root oid will make things much more complicated, eg. 
dealing with all the enterprise-specific branches, users may get 
confused about the differences between the branches, related 
information appears under completely different branches, etc.

* NOTIFICATION definitions in TYPEs:

Proposal to move notifications into the types to be more OO-like. It is not 
always true a notification can be tied to a specific set of data, 
however.  Also not sure what problem this issue solves. Juergen 
previously also wanted master NOTIFICATION (link up), and derived 
NOTIFICATIONs. Suggestion was to take this to the list until we can 
understand what Juergen wanted to do originally. Moving on...

* Inline vs. by-reference TYPEs and VARs:

Extend types by inline or by reference and only allow named types. 
Interim decided that we only do it by reference, never inline. By 
reference allows all constructs to be reusable. Adds some complexity in 
terms of versioning.  We would never allow a type to be silently 
extended, you would have to clone it. Another issue is it makes MIBs 
harder to read because you have to search for type definitions. Some have 
suggested that this makes things unreadable.  Turns out that people think 
referencing things by type is an annoyance. Some things are simply not 
meant to be reused. The MIB writer has to have some 
responsibility with the freedom. Inline definitions should be allowed to aid 
readability. *** The consensus in the room was to kill the proposal to 
force all types to be reusable. ***

* Descriptor naming issues for TYPEs. 

BCP document would define what the limit is for different protocol 
mappings, and the current limit that names are to be restricted to 
<=32/64 will be eliminated. Hums agree.

Require uniqueness only within the scope of the parent node. Can you have 
descriptors that define the same data types. It needs to be fully 
qualified.  It is important to distinguish between the name of the type 
(eg. TC) and the name of an object (the oid). This discussion is 
specifically around type descriptors.  You can use the module name 
descriptor to find import name clashes.

Finally, it was suggested we move to XML style names; mixed case with 
hypens. Hums agreed this would be good to do.

* Conformance section changes to support SMIv3. 

Existing MODULE-COMPLIANCE macro won't work for SMIv3 objects. 
Descriptors are not unique within the module. Existing problems with SMIv2 
need to be fixed such as OBJECT clauses for INDEX objects. Need to create  a 
construct for each complex VAR declaration... Could fully specify 
attribute names; but it would be better to have a shorthand notation. Andy 
suggests he will work on this offline, it's not an open issue, he just 
needs to finish it. 

* Change control issues for variables

Need to be able to add new attributes to existing VARs, just as we add new 
columns to an existing table now. We should be able to create a new type 
which is a superset of an old type and allow VAR SYNTAX to change. Use 
conformance section for version identification. Allow the writer to 
replace FooType with BarType which is a superset of FooType. This could be 
done with a Cut & paste operation, and can only add new definitions to the 
end. If it is defining a subclass, need to increase the naming depth. It 
would be useful to have an include clause since we want to be able to 
compose new object definitions from the old definitions. This is 
specifically for change control. Only semantics of fooType need to stay the 
same, just need to add columns to a table in a radically new way. 

* SMI syntax changes

Many syntax changes proposed by at the last interim. Need to decide case by 
case on the mailing list. Examples: Imports; LEAF, NODE or ATTRIBUTE; 
OBJECT-GROUP ->GROUP; NOTIFICATION-GROUP -> GROUP; Base type names; 
Remove MODULE - this module should be implied. There were no comments. 
There was little support for syntax changes in the room.

* Migration of SMIv2 CLRs to SMIv3

Suggestion was to take them out of the SMI and put them into a separate 
document particular to a protocol mapping. But we don't want to put the 
sign that says no left on main and collect it with all other crappy 
little road signs and put them in the same place. But, at the same time, we 
need to make the language document somewhat future proof so when 
protocols are upgraded, we don't have to update the full standard 
document... Concensus in the room was to put these rules in a separate 
informational document & thus easier to change. 

* Support for Configuration:

Need to distinguish between different types of objects: 
Configuraton (acl list, bgp peer, users/passwords) vs. Control 
(per-session debug commands, reset card) vs. State (ifOperStatus) vs. 
Statistics (eg. ifInOctets). Need mechanism to describe high-level 
configuration methods:Could be purely documentation, but they need to be 
clearly specified in the MIB document... These could be more, such as the 
minimum procedural requirements for a particular task. Don't call these 
methods! Call them use cases or scenarios.  Specifically what is needed: 
Mechanism to describe what has to be created in initial PDU, what can be 
edited after creation, what is the cascading deletion order, etc. 

* Support for XML naming , XSD translation.
 
It would make the IETF more consistent if the SMI were to be the base 
definition for everything, XML, COPS-PR etc. Would like to make sure there is 
only one data definition, regardless of the number of protocols. Some 
hints to make language definitions easier: Need to identify XML 
Namespace for MIB; Add optional XML-NAMESPACE "<URI>" clause in 
MODULE-IDENTITIY, or use XML namespace MODULE name; Need to identify XML 
element names: Optional XML-NAME "string" clause in TYPE or VAR 
constructs used to override descriptor as element name. Need to map ARRAY 
population characteristics to minOccurs, maxOccurs attributes. 

The question was raised, why so much emphasis on XML. Some question if it 
was appropriate to put XML name mappings inline vs. in a separate XML 
mapping document as there could be a separate sppi mappings document. 
Given Andy's suggestions for support of XML naming, some expressed that 
perhaps a better outcome of this wg effort would be to declare that 
XMLSchema should replace the SMI.