Hi,
I took minutes during the June 6 2002 interim meeting, where a lot of the topics were discussed that are now being raised for consensus last call.
I never sent my notes to Dave Durham. Dave wrote the minutes from notes taken by two others and himself, so I expect the minutes are accurate, and my notes should correspond with the official minutes.
I thought it might be useful to the WG to see some of the discussions that occurred, as I recorded them. These notes are RAW, as will be very evident from the incomplete sentences, etc., and they are my notes at the time which may not properly represent anybody's specific views correctly. Nor are they necessarily notes of the complete conversation.
I am only publishing these because they might offer some insight into the rationale of some decisions, and help limit the reopening of cans of worms. ;-)
dbh
SMIng June 6 2002
RP Randy Presuhn,
DD Dave Durham,
BW (Bert Wijnen),
AB,
SW waldbusser,
GW waters,
WH hardaker,
RF Rob Frye,
DH Dave Harrington
JH Joel Halpern,
CE Chris Elliot
Agenda bashing.
Presentation by Juergen - opinions on directions
Do we want it to do just monitoring or also config.
We already want
For control, we need to do more than just manipulate data; may need actions
Randyp: script mib can do arbitrarily complex things, and return results only in a string. It would be good to have a mechanism for returning other data (possibly even a MIB it presents as it works). The SMIv2 doesn't let you describe this.
Do we want to retain compatibility with SMIv2? If we assume we are going to change the protocol to include methods, we need to know this. The language is not independent of the SMI.
AB: it is ok to work on the assumption we may enhance the protocol.
Joel: Andy explicitly made the SMI-DS instancing compatible with SNMPv3.
AB: If we allow new ops, like create-transaction, we can use new data formats that support those, but we want to keep existing ops compatible. OID pointers also needed to be compatible with existing mib OIDs.
JS: some degree of change is ok, other change is not; we haven't identified where the boundary is yet.
AB: I think that we create new functionality with new formats, but we can't add the new functionality in places where it would break existing applications.
JS: Do we want to be able to compile v2->SMIng and SMIng->SMIv2?
WH: not important to go from SMING to SMIv2.
GW: want to carry info over SNMPv2/3; want compile SMIv2->SMIng, don't care about SMING->SMIv2
Joel: where both sides have equivalent semantics, auto translation is desirable. Where they don't map, it isn't important. We shouldn't be constrained by the translations, except that it is desirable to be able to auto-translate for the common subset.
Do we care about COPS/PR and SPPI?
DD: It is not a constraint on this WG to support these.
BW: The IESG has decided to publish the RAP and Diffserv PIBS as Informational at this time.
AB: naming was made more difficult by SPPI compatibility
JS: we made nmrg proposal protocol-independent; SPPI added challenges, but it can be done. It would require lots of discipline to use it correctly, and most would get it wrong, so it would be good to not use it.
DD: SPPI folk can write document about how to make it work if they want.
Slide: SNMP does not work for config mgmt
AB, DH, WH, RF, disagree.
Slide: should not change things that work well:
Instance naming: generic apps
RP: not an issue for our apps, or apps I've dealt with
SW: nor apps I know. This doesn't break apps
WH: Table retrieval may break. But we shouldn't use old tools to display new structures.
JS: If it has to be implemented in lots of new tools before I can see the data, this is not a workable solution.
AB: mixing new structures in an existing table WILL be problematic; the mib shouldn't be designed this way.
WH: either way new tools need to be written
AB: WG consensus was to use n-level nesting; scalars and tables are not enough, so we need to do this.
RP: Diffserv PIB needed to use a clunky approach to handling role combinations.
Instance naming: linear subtree
Slide: what to change
JS:
RP: It is valuable for the language to be able to specify methods.
J: let's not fool ourselves into thinking giving them these tools will make snmp better for configuration.
AB:
RP: semantic level of a specific IDL.
J: currently done in description clauses and text surrounding the mib. Can we
AB: I am in favor of high-level semantics being specified in mibs, not just in description clauses; a recommended use case?
RP: In USM, we discuss lots of ways to create a usm entry, etc. It would be good to have a "METHOD: Create New User: <recipe for doing certain types of things>" In the object clause. Suggesting
GW: When it comes down to
WH: There are common things that are 99% of the usage of the object. We don't need to specify every usage, only the expected common usages.
DD: in telco world, there are lots and lots of methods.
AB: We need to use constraints.
SW: Maybe we could include script for how to apply a method.
RP: How you map this depends on the protocol being used. How one does this depends on your use case and
DH: Need to keep distinction between use case and elements of procedure/method.
AB: machine parseable might be nice, but we're not engineering that now.
Slide: what to change:
AB: do not want annotational to allow vendors to write more proprietary SNMP dialects.
GW: do we want this to be usable by SPPI, for example, where some new feature is required to support their needs?
DH: It should be difficult to do, and should only be done after careful consideration.
RF: It should be able to put some useful data into non-machine-readable to capture the thinking behind an object.
AB: The handbook should be stable. We don't want to require that each mib reader must have a vendor-specific handbook to decode a mib document.
RP: There are lots of vendor-specific stuff people might want to add to mibs, such as code generation stuff. We added stuff in-line in mibs, but changed to using a separate revision control, in a different file, so we don't need this built into the SMI.
Operators observed that mibs lag the cli, and the cost of mib implementation is too high.
--
terminology
which terms should we not use because they are confusing?
Do we wish to continue using the SMI terminology?
DH: we should try to align our terminology with common software development terminology.
Consensus - shouldn't change if not broken, but confusing things should be changed.
JS: How do we define broken?
GW: How does this differ from the SMI syntax discussion?
DD: let's consider some deltas from SMI terminology:
Attribute: a nameable element within an aggregate.
Base Types: [base types are Integer, etc. - put in ABNF]
Aggregate types:
Derived Types:
Arithmetic types: C ints,
<Pointer types>: from C
<Scalar types>: from C, arithmetic and pointer types; [anything that is not an aggregate]
<n-levels of nesting> can use structs to compose a structs; Complex data structs can be used to compose other data structs. [aggregate types]
<hierarchical instcnce naming>
<indexing on the right>
<intermediate type definitions>
<scalars>
<structures>
<namespaces>
<unions>
<pointers>
<types pointers>
<constraints>
<containment>
<class>
<attribute>
<object>
N levels of nesting: compare DS and NMRG approaches
In DS, description of naming is correct. .1 or .0 only occurs once, not at every nesting level.
Complex data structure and all the sub-attributes are contained, can contain that in an arbitrary way. Can also have arrays in arrays.
We would like to be able to express data hierarchies for sequences, unions, arrays, etc.
DD: Juergen, does NMRG support aggregates, and if not, why not? Are there problems with nesting?
JS: It would be more complex; the way to simplify is to use flat tables. But tables contain pointers to other tables, so they really are complex containment. What are the benefits of an arbitrarily complex aggregate type?
AB: we're rehashing again. Currently every instance Is manually mapped, which negatively impacts reuse.
JS: We have no problem with nesting.
JS: I'm neutral on the hierarchical naming. We can research it further.
DD: Does Frank thinks there is a problem with hierarchical naming?
JS: Let's ask Frank.
AB: Frank's previous comment was - existing tools won't know how to display this; these tools will break. the tools will need to be modified.
JS: Applications may have problems if table types are mixed.
Discussion of how unfriendly OIDs are.
Aggregates and hierarchical OIDs
We want aggregates. We also want to be able to address individual attributes of an aggregate.
At what point in the process are OIDs added to the definition?
Distinguished naming of individual attributes of the attributes.
RG supports naming them in the binding stage.
Maintenance issues of adding things to the end.
RP: Automatic assignment of OIDs to reflect the structure.
To what extent is assignment done automatically, and to what degree under control of the writer? Automatic is problematic for insertions, deletions, etc.
AB: Typedefs don't get assignments, which makes it more reusable. Instances get assignments.
JS: RG has a naming scope that is the aggregated type
Consensus: we want to explicitly assign oids.
AB
JS: Under hierarchical naming, assigning it manually at the point of definition is better than mapping them later.
AB: The use of a .1 suboid permits an SMIv2 table to be translated into a DS array, and the OIDs end up matching.
Andy did a walkthrough of how hierarchical naming works with DS proposal.
Some discussion of addressing attributes of an aggregate within a PDU.
Plan to discuss optimized numbering in the morning.
Discussion of getnext issues.
Getnext across unions
Randy Presuhn discussed an alternate approach to indexing and discriminators.
Nested unions will be ugly.
WH: if you do a GET against a discriminator, you need multiple round trips.
RP:
JS: this tries to address a problem, but doesn't solve it completely, so it might be better to simply accept that unions will be slower rather than adding this complexity.
JH: a combination of array-indexed and non-array-indexed elements within an OID makes it near impossible to determine what is being referenced. Andy's proposal seems to be able to be dereferenced more easily.
Bert proposed having a separate branch for SMIv3 modules. This would permit better addressing dereferencing, without needing the .1 for SMIv2 compatibility.
Day Two
Discussions of indexing by AB and RP.
Discussing of search capability requirements via indexing.
Discussion of SQL interfaces and whether that level of searching is needed.
JS: operators often use regular expressions in Perl
Continued discussions in research aspects.
There are a number of problems we're facing.
Vendors won't do multiple disruptive incremental modifications to SNMP without having a vision defined for the longer-term goals.
Wild-carding and templates are going into the Cisco modular CLI with regular expressions, etc.
SteveW presentation
Retrieval of aggregates and non-aggregates;
ambiguity in OID specifications in proposed
does 2.1.13 mean 2.1, index13 or 2.1.13 with no index
goals:
need to clearly separate the base+hierarchy from the index portion.
Lexi-sort groups in reasonably useful way
Backwards compatibility
Proposal:
Different types of encoding for SMIv3 and SMIv2
.1 tree (tableEntry) vs. .2 for aggregates
<base>.<hierarchy>.0.<index>
AB: does index need to be to the right if we use .2 tree?
More radical proposals
Change from BER to XML for greater control
No special encoding format needed to separate v2 and v3 formats
Could encode index in ascii format
Discussion of XML and how to use it
Not desirable to use XML to encode SNMP OIDs
Cisco has found that people would like XML transport for CLI show and syslog retrieval
SW: difficult to translate XML into
RP: different xml formats for different purposes. Screen scraping operators are looking for info structure, not a protocol-specifying structure.
AB: CLI uses lots of string storage, so string storage in agents is not a constraint
DD: why couldn't you have a parallel hierarchy that maps names to OIDs?
WH: largest # of questions is how to load mibs not application X?
And how do I find vendor Y's mib?
DD: Do we want support meta-data in SMIv3 to do self-describing data?
It would get rid of the need to have the mib loaded.
This would also address the operator's need for
Resource constrained devices might need nothing more than the base OID for index, with URL of where the data actually is.
URL points to actual mib specification on vendor's web site.
Augments should be done to table, not Entry
Transaction Support (See Steve's message)
Mandatory, optional parameters in required order in one PDU
Debate over whether order is important to specify.
Ordering can actually make it harder for agents, and complicates compliance testing unnecessarily.
Debate over whether DEFVAL already provides the capability, if DEFVAL is mandatory for optional objects.
Continued debate over ordering. Order within a PDU is not generally important. The problem is when varbinds for a row are in multiple PDUs, and partial state must be maintained. This is especially aggravated by rollbacks on unsuccessful SETs, and SETs where the rest of the row never arrives, and the partial data must be garbage-collected.
Small discussion of PDU chaining; transaction dependencies. Etc.
Are methods, transactions, and elements of procedure the same thing?
There are differences in atomicity, and
Transactionality that does not cross object boundaries is fairly simple.
Transactionality across object boundaries requires more
SB: we should have mandatory elements of procedure per high-level object (aggregate)
Discussion of use cases, and adding meta-data fields for how to do common tasks.
Not necessarily machine-readable.
If machine readable, that amounts to scripting. If we do a half-hearted example, then implementers will implement using our script, and the bad implementation will end up being propagated widely.
Discussion about USM user creation and how to explain the steps.
With reuse, describe how to do common things.
The current pointer mechanism doesn't let you point at an instance of an attribute.
Our OID system doesn't point well. Coming up with
OIDs are good for registration, but we need a new value type
It is difficult to determine where the index is in an OID.
One saving grace is that you don't have the question of a reference to an aggregate.
If we need a different data type to represent the new stuff pointers, that will bubble up into the SMI.
SMIv2 RowPointers don't let you point at a particular instance of an aggregate.
RP: A separation of the index from the base appears to be necessary to avoid ambiguity.
AB: using the zero separator between base and index solves this.
DH: Do we want to not use OIDs?
WH: If we use a union, we can allow a name to be defined as an OID or as an equivalent type.
AB:
RP: With unions, we want a choice; not a C-style union.
DH: Do we want to not use OIDs
RP: The OID tail is wagging the SNMP tail
WH: Can we
WH: I like OIDs for registering base trees because it is good for master/subagent etc.
Instance level registration
RP: Changing to
WH; The 128-suboid limit will byte us with aggregated reusable types
AB: you cannot anticipate how existing types will get reused.
RP: When we look at what it takes to talk to one of these systems, if you can out an algorithmic proxy between manager and agent to take our designs and spew out well-formed SNMPv3 on the other end.
Level 1 - no change at all
Level 2 - algorithmic proxy translation
Level 3 - adding PDU types,
AB: They made compromises when making color TV, so signal could be used on B&W TVs. It will never produce color on a B&W TV. To get the new features, you need to do new work.
RP: do we want to allow existing mibs to allow refer to things in new mibs. If so then we need to update the mibs. We could point it leaf nodes in new mibs, but not to aggregates.
RP: Reference to aggregate is only useful with a new PDU format.
Do we need to deal with whether old PDUs can find reference leafs in new format where OID may exceed 128.
RP: even limiting the strings to 16 chars, current mibs can exceed the limit.
WH: VACM now cannot reference all objects, because some multi-string indexes can exceed.
BW: especially when we start using IPv6 addresses as indexes
To Bert, are we allowed to move into considering not using OIDs?
BW: we are trying to solve the problem of monitoring, and trying to determine whether SNMP can be useful for configuration. SMI potentially needs serious changes to SNMP. If we're going to go to the point of having to rewrite the protocol, and we still have no guarantee that operators will use it, then why don't we try to develop a new thing from scratch.
Discussion of new models to fit within the RFC2571 architecture, with v3xml messages,
Extended discussion about constraints concerning the design, and how they are making it hard to meet the operators' requirements.
Discussion
Gestalt of the architecture is ok, BUT there are a lot of details in RFC2571 that are highly constraining, such as using OIDs for VACM interface.
DD: the lack of a transaction model impacts all the way down to the instrumentation
AB: mib design is also affected, with multiple small strings, etc. Lack of aggregate support in VACM.
AB: sub-agents sharing columns in a table are problematic
AB,RP: VACM has difficulty dealing with different policies for different aggregate concepts.
--
Conformance
Conformance currently only handles conformance to object definitions. There is no way to specify conformance for elements of procedure, no conformance for types, and so on. Now we list all the fields; if in a typedef, we add a field, the conformance cannot automatically be assumed; there needs to be conformance versioning, so people can specify which conformance version that met.
RP: CMIP used an OID per changed module. Once you change the typedef definition, the OID registration would change.
AB: variable definitions and typedefs are relative to a definition. If you always process this thing as being a handle, and pass it around as an aggregate. Conformance to the aggregate doesn't change when the object changes because the existing usage isn't impacted by the internal change of the object data.
WH: ...ability to incorporate another object, flattened, into your current object. If you have an object with a,b,and c, and you want to define a new object with a,b,c, and d, the abc can be brought into the new object.
AB: if we have the rule that if you change a typedef then you can cut and paste it , but you need to change the name of the container.
AB: another crappy little rule: two module compliance statements - one for readonly, one for readwrite.
AB: we need to think of ways to decrease the ambiguity about what the agent actually does. A conformance allows different min-access; how can we find out which configuration is actually supported.
JS: The min-access clause means you can only count on the read-only; you can't count on it.
WH: can we leave out "current"
AB: CLI beats SNMP because the release notes describe what is or is not supported by a command. With SNMP, what an agent actually does is not detailed.
Detailed comparison of sming and smi-ds
Should all variable definitions be based on typedefs? i.e., except for base types, variables must always use out-of-line typedefs. Anonymous structs are not allowed; always name your structs so they can be reused later.
Do not use anonymous unions.
<get PP.txt from Juergen to supplement the following.>
AB: We currently allow extra columns to a table without requiring deprecating a table to change it to a new table. Requiring all structs to be named precludes that possibility.
RP: You do not modify an existing struct that has been published for purposes of reuse.
JH: Tables can be augmented; that resolves that issue.
JS, JH, WH: it is undesirable to modify a struct typedef that is in use.
SMIv3 is the name of the output of this WG.
Change date format to YYYY-MM-DD HH:MM
SMIng base types are not identical to the set of tagged types used in the SNMP protocol. SMING uses Integer32, Unisgned32, Integer64, Unisgned64, OctetString, ObjectIdentifier, Bits, Enumeration, Float*
AB: Likes new types, consistency in capitalization.
OK
base types should not be IMPORTed. Derived types must be imported.
SIZE (1..20) when talking about the number of octets (not characters). Do not want to use RANGE (1..20), just (1..20). Not consistent, biut not worth changing.
Use 0x prefix to denote hex strings - no consensus
Pointer as a base type rather than OBJECT IDENTIFIER, to keep the language more independent of the mapping language. Deferred?
Dotted notations: no conclusion on the different types of representations.
Float types: In the objectives document.
Enumeration vs INTEGER - consensus
Display formats in mib definitions; don't change
Comment delimiters - rough consensus "//" - take to list
CAPITALIZE KEYWORDS - (not base types) - consensus.
Consistent syntactic structure - "int x" rather than "x int" - consensus
Drop Last-updated clause - consensus. Revision clauses are mandatory.
No semicolon on IMPORTS clauses - consensus. IMPORT on each import clause (one per file with imports).
Keep SYNTAX clause
Use STRUCT, not class.
Can notifications be defined within the scope of an aggregate?
AB: Notifications are not data definitions.
Discussion of notifications
Discussion of variable declaration syntax.
Consensus - ARRAY preferred over TABLE.
Consensus - INDEX clauses might not always be bound to the aggregate type to allow index swapping.
Consensus - INDEX clauses are only allowed in ARRAYS.
Consesnsus - VAR <aggr-type> notation. Needs some further discussion.
SMIv2 limits the first two sub-OIDs. Expand to permit other legal ASN.1 leading OIDs.
Do not distinguish between OBJECT-GROUPS and NOTIFICATION-GROUPs.
RP, DH: We really need to work on making this easier.
AB: I would like to be able to tell what changed between version N and N+1.
AB: Module compliances are difficult to keep properly maintained.
Go to list for proposals.
EXTENDS/EXPANDS - not sure what we're doing with these yet. SPARSE-AUGMENTS.
MODULE - this module (in compliance) is superfluous. Consensus - eliminate for "this module" (MODULE needed when compliance statement is done outside the module.)
Documents:
1. SMIv3 Language Definition (Andy, JS, Frank)
2. SMIv3 MIB Modules (core types) (JS)
3. SMIv3 Guidelines (AB)
4. Transition from SMIv2 (AB, Chris Elliot)
5. Capabilities MIB (AB)
6. INET Modules
<<SMIngMinutes060602.txt>>
SMIng June 6 2002
RP Randy Presuhn,
DD Dave Durham,
BW (Bert Wijnen),
AB,
SW waldbusser,
GW waters,
WH hardaker,
RF Rob Frye,
DH Dave Harrington
JH Joel Halpern,
CE Chris Elliot
Agenda bashing.
Presentation by Juergen – opinions on directions
Do we want it to do just monitoring or also config.
We already want
For control, we need to do more than just manipulate data; may need actions
Randyp: script mib can do arbitrarily complex things, and return results only in a string. It would be good to have a mechanism for returning other data (possibly even a MIB it presents as it works). The SMIv2 doesn’t let you describe this.
Do we want to retain compatibility with SMIv2? If we assume we are going to change the protocol to include methods, we need to know this. The language is not independent of the SMI.
AB: it is ok to work on the assumption we may enhance the protocol.
Joel: Andy explicitly made the SMI-DS instancing compatible with SNMPv3.
AB: If we allow new ops, like create-transaction, we can use new data formats that support those, but we want to keep existing ops compatible. OID pointers also needed to be compatible with existing mib OIDs.
JS: some degree of change is ok, other change is not; we haven’t identified where the boundary is yet.
AB: I think that we create new functionality with new formats, but we can’t add the new functionality in places where it would break existing applications.
JS: Do we want to be able to compile v2->SMIng and SMIng->SMIv2?
WH: not important to go from SMING to SMIv2.
GW: want to carry info over SNMPv2/3; want compile SMIv2->SMIng, don’t care about SMING->SMIv2
Joel: where both sides have equivalent semantics, auto translation is desirable. Where they don’t map, it isn’t important. We shouldn’t be constrained by the translations, except that it is desirable to be able to auto-translate for the common subset.
Do we care about COPS/PR and SPPI?
DD: It is not a constraint on this WG to support these.
BW: The IESG has decided to publish the RAP and Diffserv PIBS as Informational at this time.
AB: naming was made more difficult by SPPI compatibility
JS: we made nmrg proposal protocol-independent; SPPI added challenges, but it can be done. It would require lots of discipline to use it correctly, and most would get it wrong, so it would be good to not use it.
DD: SPPI folk can write document about how to make it work if they want.
Slide: SNMP does not work for config mgmt
AB, DH, WH, RF, disagree.
Slide: should not change things that work well:
Instance naming: generic apps
RP: not an issue for our apps, or apps I’ve dealt with
SW: nor apps I know. This doesn’t break apps
WH: Table retrieval may break. But we shouldn’t use old tools to display new structures.
JS: If it has to be implemented in lots of new tools before I can see the data, this is not a workable solution.
AB: mixing new structures in an existing table WILL be problematic; the mib shouldn’t be designed this way.
WH: either way new tools need to be written
AB: WG consensus was to use n-level nesting; scalars and tables are not enough, so we need to do this.
RP: Diffserv PIB needed to use a clunky approach to handling role combinations.
Instance naming: linear subtree
Slide: what to change
JS:
RP: It is valuable for the language to be able to specify methods.
J: let’s not fool ourselves into thinking giving them these tools will make snmp better for configuration.
AB:
RP: semantic level of a specific IDL.
J: currently done in description clauses and text surrounding the mib. Can we
AB: I am in favor of high-level semantics being specified in mibs, not just in description clauses; a recommended use case?
RP: In USM, we discuss lots of ways to create a usm entry, etc. It would be good to have a “METHOD: Create New User: <recipe for doing certain types of things>” In the object clause. Suggesting
GW: When it comes down to
WH: There are common things that are 99% of the usage of the object. We don’t need to specify every usage, only the expected common usages.
DD: in telco world, there are lots and lots of methods.
AB: We need to use constraints.
SW: Maybe we could include script for how to apply a method.
RP: How you map this depends on the protocol being used. How one does this depends on your use case and
DH: Need to keep distinction between use case and elements of procedure/method.
AB: machine parseable might be nice, but we’re not engineering that now.
Slide: what to change:
AB: do not want annotational to allow vendors to write more proprietary SNMP dialects.
GW: do we want this to be usable by SPPI, for example, where some new feature is required to support their needs?
DH: It should be difficult to do, and should only be done after careful consideration.
RF: It should be able to put some useful data into non-machine-readable to capture the thinking behind an object.
AB: The handbook should be stable. We don’t want to require that each mib reader must have a vendor-specific handbook to decode a mib document.
RP: There are lots of vendor-specific stuff people might want to add to mibs, such as code generation stuff. We added stuff in-line in mibs, but changed to using a separate revision control, in a different file, so we don’t need this built into the SMI.
Operators observed that mibs lag the cli, and the cost of mib implementation is too high.
--
terminology
which terms should we not use because they are confusing?
Do we wish to continue using the SMI terminology?
DH: we should try to align our terminology with common software development terminology.
Consensus – shouldn’t change if not broken, but confusing things should be changed.
JS: How do we define broken?
GW: How does this differ from the SMI syntax discussion?
DD: let’s consider some deltas from SMI terminology:
Attribute: a nameable element within an aggregate.
Base Types: [base types are Integer, etc. – put in ABNF]
Aggregate types:
Derived Types:
Arithmetic types: C ints,
<Pointer types>: from C
<Scalar types>: from C, arithmetic and pointer types; [anything that is not an aggregate]
<n-levels of nesting> can use structs to compose a structs; Complex data structs can be used to compose other data structs. [aggregate types]
<hierarchical instcnce naming>
<indexing on the right>
<intermediate type definitions>
<scalars>
<structures>
<namespaces>
<unions>
<pointers>
<types pointers>
<constraints>
<containment>
<class>
<attribute>
<object>
N levels of nesting: compare DS and NMRG approaches
In DS, description of naming is correct. .1 or .0 only occurs once, not at every nesting level.
Complex data structure and all the sub-attributes are contained, can contain that in an arbitrary way. Can also have arrays in arrays.
We would like to be able to express data hierarchies for sequences, unions, arrays, etc.
DD: Juergen, does NMRG support aggregates, and if not, why not? Are there problems with nesting?
JS: It would be more complex; the way to simplify is to use flat tables. But tables contain pointers to other tables, so they really are complex containment. What are the benefits of an arbitrarily complex aggregate type?
AB: we’re rehashing again. Currently every instance Is manually mapped, which negatively impacts reuse.
JS: We have no problem with nesting.
JS: I’m neutral on the hierarchical naming. We can research it further.
DD: Does Frank thinks there is a problem with hierarchical naming?
JS: Let’s ask Frank.
AB: Frank’s previous comment was – existing tools won’t know how to display this; these tools will break. the tools will need to be modified.
JS: Applications may have problems if table types are mixed.
Discussion of how unfriendly OIDs are.
Aggregates and hierarchical OIDs
We want aggregates. We also want to be able to address individual attributes of an aggregate.
At what point in the process are OIDs added to the definition?
Distinguished naming of individual attributes of the attributes.
RG supports naming them in the binding stage.
Maintenance issues of adding things to the end.
RP: Automatic assignment of OIDs to reflect the structure.
To what extent is assignment done automatically, and to what degree under control of the writer? Automatic is problematic for insertions, deletions, etc.
AB: Typedefs don’t get assignments, which makes it more reusable. Instances get assignments.
JS: RG has a naming scope that is the aggregated type
Consensus: we want to explicitly assign oids.
AB
JS: Under hierarchical naming, assigning it manually at the point of definition is better than mapping them later.
AB: The use of a .1 suboid permits an SMIv2 table to be translated into a DS array, and the OIDs end up matching.
Andy did a walkthrough of how hierarchical naming works with DS proposal.
Some discussion of addressing attributes of an aggregate within a PDU.
Plan to discuss optimized numbering in the morning.
Discussion of getnext issues.
Getnext across unions
Randy Presuhn discussed an alternate approach to indexing and discriminators.
Nested unions will be ugly.
WH: if you do a GET against a discriminator, you need multiple round trips.
RP:
JS: this tries to address a problem, but doesn’t solve it completely, so it might be better to simply accept that unions will be slower rather than adding this complexity.
JH: a combination of array-indexed and non-array-indexed elements within an OID makes it near impossible to determine what is being referenced. Andy’s proposal seems to be able to be dereferenced more easily.
Bert proposed having a separate branch for SMIv3 modules. This would permit better addressing dereferencing, without needing the .1 for SMIv2 compatibility.
Day Two
Discussions of indexing by AB and RP.
Discussing of search capability requirements via indexing.
Discussion of SQL interfaces and whether that level of searching is needed.
JS: operators often use regular expressions in Perl
Continued discussions in research aspects.
There are a number of problems we’re facing.
Vendors won’t do multiple disruptive incremental modifications to SNMP without having a vision defined for the longer-term goals.
Wild-carding and templates are going into Cisco modular CLI with regular expressions, etc.
SteveW presentation
Retrieval of aggregates and non-aggregates;
ambiguity in OID specifications in proposed
does 2.1.13 mean 2.1, index13 or 2.1.13 with no index
goals:
need to clearly separate the base+hierarchy from the index portion.
Lexi-sort groups in reasonably useful way
Backwards compatibility
Proposal:
Different types of encoding for SMIv3 and SMIv2
.1 tree (tableEntry) vs. .2 for aggregates
<base>.<hierarchy>.0.<index>
AB: does index need to be to the right if we use .2 tree?
More radical proposals
Change from BER to XML for greater control
No special encoding format needed to separate v2 and v3 formats
Could encode index in ascii format
Discussion of XML and how to use it
Not desirable to use XML to encode SNMP OIDs
Cisco has found that people would like XML transport for CLI show and syslog retrieval
SW: difficult to translate XML into
RP: different xml formats for different purposes. Screen scraping operators are looking for info structure, not a protocol-specifying structure.
AB: CLI uses lots of string storage, so string storage in agents is not a constraint
DD: why couldn’t you have a parallel hierarchy that maps names to OIDs?
WH: largest # of questions is how to load mibs not application X?
And how do I find vendor Y’s mib?
DD: Do we want support meta-data in SMIv3 to do self-describing data?
It would get rid of the need to have the mib loaded.
This would also address the operator’s need for
Resource constrained devices might need nothing more than the base OID for index, with URL of where the data actually is.
URL points to actual mib specification on vendor’s web site.
Augments should be done to table, not Entry
Transaction Support (See Steve’s message)
Mandatory, optional parameters in required order in one PDU
Debate over whether order is important to specify.
Ordering can actually make it harder for agents, and complicates compliance testing unnecessarily.
Debate over whether DEFVAL already provides the capability, if DEFVAL is mandatory for optional objects.
Continued debate over ordering. Order within a PDU is not generally important. The problem is when varbinds for a row are in multiple PDUs, and partial state must be maintained. This is especially aggravated by rollbacks on unsuccessful SETs, and SETs where the rest of the row never arrives, and the partial data must be garbage-collected.
Small discussion of PDU chaining; transaction dependencies. Etc.
Are methods, transactions, and elements of procedure the same thing?
There are differences in atomicity, and
Transactionality that does not cross object boundaries is fairly simple.
Transactionality across object boundaries requires more
SB: we should have mandatory elements of procedure per high-level object (aggregate)
Discussion of use cases, and adding meta-data fields for how to do common tasks.
Not necessarily machine-readable.
If machine readable, that amounts to scripting. If we do a half-hearted example, then implementers will implement using our script, and the bad implementation will end up being propagated widely.
Discussion about USM user creation and how to explain the steps.
With reuse, describe how to do common things.
The current pointer mechanism doesn’t let you point at an instance of an attribute.
Our OID system doesn’t point well. Coming up with
OIDs are good for registration, but we need a new value type
It is difficult to determine where the index is in an OID.
One saving grace is that you don’t have the question of a reference to an aggregate.
If we need a different data type to represent the new stuff pointers, that will bubble up into the SMI.
SMIv2 RowPointers don’t let you point at a particular instance of an aggregate.
RP: A separation of the index from the base appears to be necessary to avoid ambiguity.
AB: using the zero separator between base and index solves this.
DH: Do we want to not use OIDs?
WH: If we use a union, we can allow a name to be defined as an OID or as an equivalent type.
AB:
RP: With unions, we want a choice; not a C-style union.
DH: Do we want to not use OIDs
RP: The OID tail is wagging the SNMP tail
WH: Can we
WH: I like OIDs for registering base trees because it is good for master/subagent etc.
Instance level registration
RP: Changing to
WH; The 128-suboid limit will byte us with aggregated reusable types
AB: you cannot anticipate how existing types will get reused.
RP: When we look at what it takes to talk to one of these systems, if you can out an algorithmic proxy between manager and agent to take our designs and spew out well-formed SNMPv3 on the other end.
Level 1 – no change at all
Level 2 – algorithmic proxy translation
Level 3 – adding PDU types,
AB: They made compromises when making color TV, so signal could be used on B&W TVs. It will never produce color on a B&W TV. To get the new features, you need to do new work.
RP: do we want to allow existing mibs to allow refer to things in new mibs. If so then we need to update the mibs. We could point it leaf nodes in new mibs, but not to aggregates.
RP: Reference to aggregate is only useful with a new PDU format.
Do we need to deal with whether old PDUs can find reference leafs in new format where OID may exceed 128.
RP: even limiting the strings to 16 chars, current mibs can exceed the limit.
WH: VACM now cannot reference all objects, because some multi-string indexes can exceed.
BW: especially when we start using IPv6 addresses as indexes
To Bert, are we allowed to move into considering not using OIDs?
BW: we are trying to solve the problem of monitoring, and trying to determine whether SNMP can be useful for configuration. SMI potentially needs serious changes to SNMP. If we’re going to go to the point of having to rewrite the protocol, and we still have no guarantee that operators will use it, then why don’t we try to develop a new thing from scratch.
Discussion of new models to fit within the RFC2571 architecture, with v3xml messages,
Extended discussion about constraints concerning the design, and how they are making it hard to meet the operators’ requirements.
Discussion
Gestalt of the architecture is ok, BUT there are a lot of details in RFC2571 that are highly constraining, such as using OIDs for VACM interface.
DD: the lack of a transaction model impacts all the way down to the instrumentation
AB: mib design is also affected, with multiple small strings, etc. Lack of aggregate support in VACM.
AB: sub-agents sharing columns in a table are problematic
AB,RP: VACM has difficulty dealing with different policies for different aggregate concepts.
--
Conformance
Conformance currently only handles conformance to object definitions. There is no way to specify conformance for elements of procedure, no conformance for types, and so on. Now we list all the fields; if in a typedef, we add a field, the conformance cannot automatically be assumed; there needs to be conformance versioning, so people can specify which conformance version that met.
RP: CMIP used an OID per changed module. Once you change the typedef definition, the OID registration would change.
AB: variable definitions and typedefs are relative to a definition. If you always process this thing as being a handle, and pass it around as an aggregate. Conformance to the aggregate doesn’t change when the object changes because the existing usage isn’t impacted by the internal change of the object data.
WH: …ability to incorporate another object, flattened, into your current object. If you have an object with a,b,and c, and you want to define a new object with a,b,c, and d, the abc can be brought into the new object.
AB: if we have the rule that if you change a typedef then you can cut and paste it , but you need to change the name of the container.
AB: another crappy little rule: two module compliance statements – one for readonly, one for readwrite.
AB: we need to think of ways to decrease the ambiguity about what the agent actually does. A conformance allows different min-access; how can we find out which configuration is actually supported.
JS: The min-access clause means you can only count on the read-only; you can’t count on it.
WH: can we leave out “current”
AB: CLI beats SNMP because the release notes describe what is or is not supported by a command. With SNMP, what an agent actually does is not detailed.
Detailed comparison of sming and smi-ds
Should all variable definitions be based on typedefs? i.e., except for base types, variables must always use out-of-line typedefs. Anonymous structs are not allowed; always name your structs so they can be reused later.
Do not use anonymous unions.
<get PP.txt from Juergen to supplement the following.>
AB: We currently allow extra columns to a table without requiring deprecating a table to change it to a new table. Requiring all structs to be named precludes that possibility.
RP: You do not modify an existing struct that has been published for purposes of reuse.
JH: Tables can be augmented; that resolves that issue.
JS, JH, WH: it is undesirable to modify a struct typedef that is in use.
SMIv3 is the name of the output of this WG.
Change date format to YYYY-MM-DD HH:MM
SMIng base types are not identical to the set of tagged types used in the SNMP protocol. SMING uses Integer32, Unisgned32, Integer64, Unisgned64, OctetString, ObjectIdentifier, Bits, Enumeration, Float*
AB: Likes new types, consistency in capitalization.
OK
base types should not be IMPORTed. Derived types must be imported.
SIZE (1..20) when talking about the number of octets (not characters). Do not want to use RANGE (1..20), just (1..20). Not consistent, biut not worth changing.
Use 0x prefix to denote hex strings – no consensus
Pointer as a base type rather than OBJECT IDENTIFIER, to keep the language more independent of the mapping language. Deferred?
Dotted notations: no conclusion on the different types of representations.
Float types: In the objectives document.
Enumeration vs INTEGER – consensus
Display formats in mib definitions; don’t change
Comment delimiters – rough consensus “//” – take to list
CAPITALIZE KEYWORDS – (not base types) – consensus.
Consistent syntactic structure – “int x” rather than “x int” – consensus
Drop Last-updated clause – consensus. Revision clauses are mandatory.
No semicolon on IMPORTS clauses – consensus. IMPORT on each import clause (one per file with imports).
Keep SYNTAX clause
Use STRUCT, not class.
Can notifications be defined within the scope of an aggregate?
AB: Notifications are not data definitions.
Discussion of notifications
Discussion of variable declaration syntax.
Consensus - ARRAY preferred over TABLE.
Consensus - INDEX clauses might not always be bound to the aggregate type to allow index swapping.
Consensus - INDEX clauses are only allowed in ARRAYS.
Consesnsus – VAR <aggr-type> notation. Needs some further discussion.
SMIv2 limits the first two sub-OIDs. Expand to permit other legal ASN.1 leading OIDs.
Do not distinguish between OBJECT-GROUPS and NOTIFICATION-GROUPs.
RP, DH: We really need to work on making this easier.
AB: I would like to be able to tell what changed between version N and N+1.
AB: Module compliances are difficult to keep properly maintained.
Go to list for proposals.
EXTENDS/EXPANDS – not sure what we’re doing with these yet. SPARSE-AUGMENTS.
MODULE – this module (in compliance) is superfluous. Consensus – eliminate for “this module” (MODULE needed when compliance statement is done outside the module.)
Documents:
1. SMIv3 Language Definition (Andy, JS, Frank)
2. SMIv3 MIB Modules (core types) (JS)
3. SMIv3 Guidelines (AB)
4. Transition from SMIv2 (AB, Chris Elliot)
5. Capabilities MIB (AB)
6. INET Modules