54th IETF SMIng WG Meeting Minutes -- Draft

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

Please read and comment on the draft minutes below. Please provide feedback
by Friday, August 2.

Thanks,
-Dave

54th IETF SMIng WG Meeting Minutes
 
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. The wg consensus remains 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 (if you
disagree with any of these, please make your opinion known on the mailing
list). 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 lead a discussion around what 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.
Which is 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 (SNMPv4?) 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.
Todo: rowPointer vs. index component, allow the object to be a
not-accessible index (Way to get a local descriptor for inclusion in index,
while not creating a copy of an object). 

Randy: Referential integrity is hard, maybe better to bite the bullet and
accept you may have broken links. Steve, says the intent is to not allow the
agent developer to do unnatural acts. It may be okay to have broken links,
but there should be a mechanism to discourage broken links. 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. Likewise with language extensibility there are many people
against it. 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.