54th IETF SMIng WG Meeting Minutes -- Final

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

54th IETF SMIng WG Meeting Minutes
 
Wednesday, July 17, 2002 from 1300-1500
David Durham chaired the session.
Special thanks to Glenn Waters for taking minutes.
Minutes Reported by David Durham.

David Durham reviewed the results of the sming interim meeting in Washington
DC June 6th-8th. Based on a poll of the room, consensus there remained in
favor of using hierarchical oid naming as in the smi-ds proposal to achieve
n-levels of nested structures, and the smi look and feel should be preserved
as much as possible. Also, SMIv2->SMIv3 mappings are considered a
requirement, not the reverse. Terminology was addressed at the interim, the
result was to preserve the smi terminology except where there are new
features (eg. Nesting) and where the terminology is clearly broken with
respect to the rest of the industry (eg. Use of the word "OBJECT"). Issues
with hierarchical indexing were discussed, as well as access constraints and
conformance. New functionality was also recommended such as the addition of
RPC like operations and clauses for expressing transactional semantics. The
conclusion of the interim was to merge the NMRG sming proposal and the
smi-ds proposals into one, smiv3. See the interim meeting minutes for more
details.  Questions were asked about snmp compatibility, which includes v1,
v3 and whatever EOS does. Ideally, EOS and SMIng should work closely to
allow optimized protocol ops for new language features. There was a question
if this affects instrumentation that would require AgentX to be reactivated.
The response was wait and see.
 

Andy Bierman described changes in the most recent smi-ds document. The term
leaf is being changed to attribute for clarity, but will likely be changed
again, since the word attribute is overloaded with another XML definition
(what about using the word "properties"?). The previously titled conformance
mib has been renamed to the Capabilities mib. MAX-ACCESS functionality has
been changed so that it can be defined within a typedef, but can also be
redefined in a variable where it overrides the typedef. Also, the MAX-ACCESS
can apply to the whole container, not just an attribute. Can only make the
access more constrained, eg. if the typedef says it is read-only can't make
it read-write in a variable definition. The Unique Scope clause was removed,
since it added more controversy than value. Likewise, the Nodes clause was
removed. Andy would still like uniqueness so that the definition of what
makes an instance unique can be taken out of the index clause. He also
changed the curly braces back to the way it was in SMIv2. 

Regarding Named (relative) vs. Unnamed (inline) definitions, Andy believes
we need to retain the ability to ad new data objects to existing types (eg.
Columns to existing table). He suggests using conformance section to
identify which nodes are used in a particular variable declaration.

Smi-ds still needs to support 'nil' choice in UNION typedefs. This is to
allow for variant that doesn't add any nodes to an aggregate object. Eg.
RMON control table that represented all possible RMON control tables....
Something for garbage collection doesn't apply to all RMON tables. Andy
would effectively like a way of defining a template. The discriminator would
still be there, you need to declare a null node so the discriminator can
point to nothing.

A question was asked about whether the capabilities mib as it is currently
defined was suitable for describing what nodes are actually supported by an
implementation so that adding new attributes or extending existing nodes
would not be a problem. Andy responded that the Capabilities mib should be
able to identify which nodes are used in a particular variable declaration.
Capabilities are expressed in terms of names on the wire, so this should
work.


Next Steve Waldbusser led a discussion around some additional features for
smiv3 the wg should consider:

Steve first described his CREATE-TRANSACTION Proposal: For read-create
tables, there's no specification of which variables must, may, or must not
be included in a create operation. This means agents must choose between
allowing any columns to be missing (greatest interoperability) but very
difficult to implement, or the agent can choose certain columns to be
mandatory and certain as optional. This lowers implementation cost but kills
interoperability: Requires the manager to learn through trial and error, and
presents issues of semantic correctness as well. Steve is suggesting a
syntax like: CREATE-TRANSACTION specifying what attributes are required for
the read-create request and CREATE-OPTIONAL for those elements that may be
used.

Glen asked if existing mechanisms can be used to do this without inventing
some new clause which no one understands. Andy clarified that Steve wants a
value to override. David reminded Steve that in the rowstatus TC, the
description clause must specify which columns must exist to support a row.
In service rows, vs. not in service rows, etc. DEFVAL would seem to cover
what is required, but DEFVAL cannot handle some of the cases such as when
there is a column missing in the row; likewise, putting something in a
description clause is insufficient since the information cannot be change
controlled. Also, Steve wants both sides of the transaction to know what to
support. DavidP suggests that "transaction" is probably the wrong word. Wes
thinks this is a small part of a much larger problem of what is required and
what is not... When using mibs this is also confusing. What about the
possibility of forcing usage scenarios, currently this is in the description
text, but would prefer some kind of method syntax, elements of procedure,
etc. Wes thinks this is really what is needed, generally understanding the
relationships between tables, etc. so that we can accurately specify how to
use these mib objects. Wes would like to be able to document all of those
needs, even if it is not directly machine parsable. Steve aggress that there
are other constraints that are important and other elements of procedure,
Steve recognizes that this transaction clause may be overtaken by a more
comprehensive proposal (but where's this comprehensive proposal?). 

Randy suggests using some other word such as CREATE-REQUIRES though Steve
points out that this is a clause that is already reused. Agent capabilities
macro already has this. Steve agrees that TRANSACTION is a bad word, but he
is looking for something like a RPC behavior. There also was some
disagreement about the semantics of the clause: Andy thinks that it means
the agent MAY reject it if it receives something that doesn't obey the
clause.  Meanwhile Randy thinks it means that the agent MUST reject it.
Steve clarified his proposal is that the agent MAY reject it.

Andy also believes that eos should support sub transactions within a
transaction via new PDUs. This makes undo easier and simplifies the state
machine.  

DavidP wants to know if you can specify other objects in other tables in
this new clause. The answer is no, you cannot. Also, what about augments?
That makes things even trickier. What if they are index columns? This is
fine, all things that share the same index column can be specified. Changing
the semantics for augments will break existing implantations. It was
suggested that this discussion is moved to the mailing list. 

Another point was that if this mechanism is RPC like, then why not change
the syntax to look more like a function call? The issue here is that there
is no return code, like there is in a RPC mechanism... But it may be
possible to use a readable attribute to specify the equivalent of a return
code. Again, follow up this discussion on the mailing list. 

Next Steve discussed the idea of prefix/index separation. What is currently
in the smi-ds draft works fine for non-aggregate operations (eg. Gets/sets
one attribute at a time). The problem is what happens when one creates new
protocol operations that can retrieve aggregates? One can get the entire
table, a structured attribute within a table, etc. The problem is we need to
have a clear definition of where the object hierarchy ends and the index
part begins with an object identifier. Requirements and goals: It is not
acceptable if any 2 variables could be encoded into the same OID, want
lexinext sort to come out the same way. Proposal: Keep unaggregated v2/v3
access the same. Note that ifEntry part currently must equal 1. What if we
define a .2 tree as full of aggregates using this algorithm in .1 tree. Andy
thinks it is the applications choice whether to use this or not. Don't have
to preserve  lexinext ordering because you are getting the entire
sub-aggregate. 

Wes's proposal is to break out the index part into a separate PDU, because
eos proposal won't care where the index begins. Thus, change the PDU format
so that the index is separate from object hierarchy: then no explicit
encoding format is needed to separate them. Some of this is covered in
draft-hardaker-oops-xx.txt.

Steve brought up a third item, the concept of REFERENCEs. New syntax:
o	REFERENCE {objectName} [MustExist]
o	Ie. REFERENCE {ifindex} MustExist
Reference makes clear what an object is pointing to. It makes clear whether
or not the agent allows entries that reference entries that don't exist. 

Randy: Referential integrity is hard, maybe better to bite the bullet and
accept you may have broken links. Steve says the intent is to protect the
agent developer from having to perform unnatural acts. It may be okay to
have broken links but there should be a way to document those cases where
broken links are outlawed.\ The old way was to describe everything in the
description clause. So the use for indexes would be to have the REFERENCE
clause... Each one gets its own local descriptor. Andy had the issue of how
many index clauses, and how deep. Index clause descriptions are getting
quite unwieldy. Wes wanted to know if this would be mandatory, or should we
continue the old way. Maybe this is a good little but needs more thought;
how many level deep does this go; what about loops, etc. There were
questions asking if this would this be mandatory? The response was don't
know, once you have this capability cannot specify a column that doesn't
exist in a table. We need to have more discussion on the list.


Charter Discussion - David Durham
Do we want to modify the charter to reflect what we are actually doing;
i.e.: don't force SPPI mapping support. AD comment: wants input from SPPI
people. There was the comment would like to have the goal achieved of having
one document that can be used by SNMP and COPS-PR. Another suggested that we
should try to put in the effort now so that we do not diverge the two
protocols and that what we do can be mapped to COPS-PR. The AD commented
that the chair should compose some clarifying text and put this to the list
for more input. Also, with the language extensibility text in the charter,
there are many people against such extensibility. The AD commented that the
charter is not there to tell WG that, if after reasonable debate, we still
have to do something just because it is on the charter.