Emailing: SMIngMinutes060602.txt
"Harrington, David" <[email protected]> Fri, 6 Sep 2002 08:30:32 -0400
| Newsgroups | gmane.ietf.sming |
|---|---|
| Message-ID | <6D745637A7E0F94DA070743C55CDA9BA075E9C@NHROCMBX1.ets.enterasys.com> |
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_000_01C25594.1F1B62B4
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C25594.1F1B62B4"
------_=_NextPart_001_01C25594.1F1B62B4
Content-Type: text/plain
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>>
------_=_NextPart_001_01C25594.1F1B62B4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2655.35">
<TITLE>Emailing: SMIngMinutes060602.txt</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2>Hi,</FONT>
</P>
<P><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>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. ;-)</FONT></P>
<P><FONT SIZE=3D2>dbh</FONT>
</P>
<BR>
<P><FONT SIZE=3D2>SMIng June 6 2002</FONT>
</P>
<P><FONT SIZE=3D2>RP Randy Presuhn, </FONT>
<BR><FONT SIZE=3D2>DD Dave Durham, </FONT>
<BR><FONT SIZE=3D2>BW (Bert Wijnen), </FONT>
<BR><FONT SIZE=3D2>AB, </FONT>
<BR><FONT SIZE=3D2>SW waldbusser, </FONT>
<BR><FONT SIZE=3D2>GW waters, </FONT>
<BR><FONT SIZE=3D2>WH hardaker, </FONT>
<BR><FONT SIZE=3D2>RF Rob Frye, </FONT>
<BR><FONT SIZE=3D2>DH Dave Harrington</FONT>
<BR><FONT SIZE=3D2>JH Joel Halpern, </FONT>
<BR><FONT SIZE=3D2>CE Chris Elliot</FONT>
</P>
<P><FONT SIZE=3D2>Agenda bashing.</FONT>
</P>
<P><FONT SIZE=3D2>Presentation by Juergen - opinions on =
directions</FONT>
<BR><FONT SIZE=3D2>Do we want it to do just monitoring or also =
config.</FONT>
<BR> <FONT SIZE=3D2>We =
already want </FONT>
<BR> <FONT SIZE=3D2>For =
control, we need to do more than just manipulate data; may need =
actions</FONT>
<BR> <FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>AB: it is ok to work on the assumption we may enhance =
the protocol. </FONT>
<BR><FONT SIZE=3D2>Joel: Andy explicitly made the SMI-DS instancing =
compatible with SNMPv3.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>JS: some degree of change is ok, other change is not; =
we haven't identified where the boundary is yet.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>JS: Do we want to be able to compile v2->SMIng and =
SMIng->SMIv2?</FONT>
<BR><FONT SIZE=3D2>WH: not important to go from SMING to SMIv2. </FONT>
<BR><FONT SIZE=3D2>GW: want to carry info over SNMPv2/3; want compile =
SMIv2->SMIng, don't care about SMING->SMIv2</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Do we care about COPS/PR and SPPI?</FONT>
<BR><FONT SIZE=3D2>DD: It is not a constraint on this WG to support =
these.</FONT>
<BR><FONT SIZE=3D2>BW: The IESG has decided to publish the RAP and =
Diffserv PIBS as Informational at this time.</FONT>
<BR><FONT SIZE=3D2>AB: naming was made more difficult by SPPI =
compatibility</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>DD: SPPI folk can write document about how to make it =
work if they want.</FONT>
</P>
<P><FONT SIZE=3D2>Slide: SNMP does not work for config mgmt</FONT>
<BR><FONT SIZE=3D2>AB, DH, WH, RF, disagree.</FONT>
<BR><FONT SIZE=3D2>Slide: should not change things that work =
well:</FONT>
<BR><FONT SIZE=3D2>Instance naming: generic apps</FONT>
<BR> <FONT SIZE=3D2>RP: not =
an issue for our apps, or apps I've dealt with</FONT>
<BR> <FONT SIZE=3D2>SW: nor =
apps I know. This doesn't break apps</FONT>
<BR> <FONT SIZE=3D2>WH: Table =
retrieval may break. But we shouldn't use old tools to display new =
structures. </FONT>
<BR> <FONT SIZE=3D2>JS: If it =
has to be implemented in lots of new tools before I can see the data, =
this is not a workable solution.</FONT></P>
<P> <FONT SIZE=3D2>AB: mixing =
new structures in an existing table WILL be problematic; the mib =
shouldn't be designed this way.</FONT>
<BR> <FONT SIZE=3D2>WH: =
either way new tools need to be written</FONT>
<BR> <FONT SIZE=3D2>AB: WG =
consensus was to use n-level nesting; scalars and tables are not =
enough, so we need to do this.</FONT>
<BR> <FONT SIZE=3D2>RP: =
Diffserv PIB needed to use a clunky approach to handling role =
combinations.</FONT>
<BR><FONT SIZE=3D2>Instance naming: linear subtree</FONT>
<BR> =20
<BR><FONT SIZE=3D2>Slide: what to change</FONT>
<BR><FONT SIZE=3D2>JS: </FONT>
<BR><FONT SIZE=3D2>RP: It is valuable for the language to be able to =
specify methods. </FONT>
<BR><FONT SIZE=3D2>J: let's not fool ourselves into thinking giving =
them these tools will make snmp better for configuration.</FONT>
<BR><FONT SIZE=3D2>AB: </FONT>
<BR><FONT SIZE=3D2>RP: semantic level of a specific IDL. </FONT>
<BR><FONT SIZE=3D2>J: currently done in description clauses and text =
surrounding the mib. Can we </FONT>
<BR><FONT SIZE=3D2>AB: I am in favor of high-level semantics being =
specified in mibs, not just in description clauses; a recommended use =
case?</FONT></P>
<P><FONT SIZE=3D2>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 </FONT></P>
<P><FONT SIZE=3D2>GW: When it comes down to</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>DD: in telco world, there are lots and lots of =
methods.</FONT>
<BR><FONT SIZE=3D2>AB: We need to use constraints. </FONT>
<BR><FONT SIZE=3D2>SW: Maybe we could include script for how to apply a =
method.</FONT>
<BR><FONT SIZE=3D2>RP: How you map this depends on the protocol being =
used. How one does this depends on your use case and </FONT>
<BR><FONT SIZE=3D2>DH: Need to keep distinction between use case and =
elements of procedure/method.</FONT>
<BR><FONT SIZE=3D2>AB: machine parseable might be nice, but we're not =
engineering that now.</FONT>
</P>
<P><FONT SIZE=3D2>Slide: what to change:</FONT>
<BR><FONT SIZE=3D2>AB: do not want annotational to allow vendors to =
write more proprietary SNMP dialects. </FONT>
<BR><FONT SIZE=3D2>GW: do we want this to be usable by SPPI, for =
example, where some new feature is required to support their =
needs?</FONT>
<BR><FONT SIZE=3D2>DH: It should be difficult to do, and should only be =
done after careful consideration.</FONT>
<BR><FONT SIZE=3D2>RF: It should be able to put some useful data into =
non-machine-readable to capture the thinking behind an object.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Operators observed that mibs lag the cli, and the =
cost of mib implementation is too high.</FONT>
</P>
<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>terminology</FONT>
<BR><FONT SIZE=3D2>which terms should we not use because they are =
confusing?</FONT>
</P>
<P><FONT SIZE=3D2>Do we wish to continue using the SMI terminology? =
</FONT>
<BR><FONT SIZE=3D2>DH: we should try to align our terminology with =
common software development terminology.</FONT>
<BR><FONT SIZE=3D2>Consensus - shouldn't change if not broken, but =
confusing things should be changed.</FONT>
<BR><FONT SIZE=3D2>JS: How do we define broken?</FONT>
<BR><FONT SIZE=3D2>GW: How does this differ from the SMI syntax =
discussion?</FONT>
</P>
<P><FONT SIZE=3D2>DD: let's consider some deltas from SMI =
terminology:</FONT>
<BR><FONT SIZE=3D2>Attribute: a nameable element within an =
aggregate.</FONT>
<BR><FONT SIZE=3D2>Base Types: [base types are Integer, etc. - put in =
ABNF]</FONT>
<BR><FONT SIZE=3D2>Aggregate types: </FONT>
<BR><FONT SIZE=3D2>Derived Types: </FONT>
<BR><FONT SIZE=3D2>Arithmetic types: C ints, </FONT>
<BR><FONT SIZE=3D2><Pointer types>: from C</FONT>
<BR><FONT SIZE=3D2><Scalar types>: from C, arithmetic and pointer =
types; [anything that is not an aggregate]</FONT>
<BR><FONT SIZE=3D2><n-levels of nesting> can use structs to =
compose a structs; Complex data structs can be used to compose other =
data structs. [aggregate types]</FONT></P>
<P><FONT SIZE=3D2><hierarchical instcnce naming> </FONT>
<BR><FONT SIZE=3D2><indexing on the right></FONT>
<BR><FONT SIZE=3D2><intermediate type definitions></FONT>
<BR><FONT SIZE=3D2><scalars></FONT>
<BR><FONT SIZE=3D2><structures></FONT>
<BR><FONT SIZE=3D2><namespaces></FONT>
<BR><FONT SIZE=3D2><unions></FONT>
<BR><FONT SIZE=3D2><pointers></FONT>
<BR><FONT SIZE=3D2><types pointers></FONT>
<BR><FONT SIZE=3D2><constraints></FONT>
<BR><FONT SIZE=3D2><containment></FONT>
<BR><FONT SIZE=3D2><class></FONT>
<BR><FONT SIZE=3D2><attribute></FONT>
<BR><FONT SIZE=3D2><object></FONT>
</P>
<BR>
<BR>
<P><FONT SIZE=3D2>N levels of nesting: compare DS and NMRG =
approaches</FONT>
</P>
<P><FONT SIZE=3D2>In DS, description of naming is correct. .1 or .0 =
only occurs once, not at every nesting level.</FONT>
<BR><FONT SIZE=3D2>Complex data structure and all the sub-attributes =
are contained, can contain that in an arbitrary way. Can also have =
arrays in arrays.</FONT></P>
<P><FONT SIZE=3D2>We would like to be able to express data hierarchies =
for sequences, unions, arrays, etc.</FONT>
<BR><FONT SIZE=3D2>DD: Juergen, does NMRG support aggregates, and if =
not, why not? Are there problems with nesting? </FONT>
<BR><FONT SIZE=3D2>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? </FONT></P>
<P><FONT SIZE=3D2>AB: we're rehashing again. Currently every instance =
Is manually mapped, which negatively impacts reuse. </FONT>
<BR><FONT SIZE=3D2>JS: We have no problem with nesting.</FONT>
<BR><FONT SIZE=3D2>JS: I'm neutral on the hierarchical naming. We can =
research it further.</FONT>
<BR><FONT SIZE=3D2>DD: Does Frank thinks there is a problem with =
hierarchical naming?</FONT>
<BR><FONT SIZE=3D2>JS: Let's ask Frank.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>JS: Applications may have problems if table types are =
mixed.</FONT>
</P>
<P><FONT SIZE=3D2>Discussion of how unfriendly OIDs are.</FONT>
</P>
<P><FONT SIZE=3D2>Aggregates and hierarchical OIDs</FONT>
<BR><FONT SIZE=3D2>We want aggregates. We also want to be able to =
address individual attributes of an aggregate.</FONT>
<BR><FONT SIZE=3D2>At what point in the process are OIDs added to the =
definition?</FONT>
<BR><FONT SIZE=3D2>Distinguished naming of individual attributes of the =
attributes.</FONT>
<BR><FONT SIZE=3D2>RG supports naming them in the binding stage.</FONT>
<BR><FONT SIZE=3D2>Maintenance issues of adding things to the end. =
</FONT>
<BR><FONT SIZE=3D2>RP: Automatic assignment of OIDs to reflect the =
structure.</FONT>
<BR><FONT SIZE=3D2>To what extent is assignment done automatically, and =
to what degree under control of the writer? Automatic is problematic =
for insertions, deletions, etc.</FONT></P>
<P><FONT SIZE=3D2>AB: Typedefs don't get assignments, which makes it =
more reusable. Instances get assignments.</FONT>
<BR><FONT SIZE=3D2>JS: RG has a naming scope that is the aggregated =
type</FONT>
<BR><FONT SIZE=3D2>Consensus: we want to explicitly assign oids.</FONT>
<BR><FONT SIZE=3D2>AB</FONT>
<BR><FONT SIZE=3D2>JS: Under hierarchical naming, assigning it manually =
at the point of definition is better than mapping them later.</FONT>
<BR><FONT SIZE=3D2>AB: The use of a .1 suboid permits an SMIv2 table to =
be translated into a DS array, and the OIDs end up matching. </FONT>
</P>
<BR>
<P><FONT SIZE=3D2>Andy did a walkthrough of how hierarchical naming =
works with DS proposal. </FONT>
<BR><FONT SIZE=3D2>Some discussion of addressing attributes of an =
aggregate within a PDU.</FONT>
<BR><FONT SIZE=3D2>Plan to discuss optimized numbering in the =
morning.</FONT>
</P>
<P><FONT SIZE=3D2>Discussion of getnext issues.</FONT>
</P>
<P><FONT SIZE=3D2>Getnext across unions</FONT>
<BR><FONT SIZE=3D2>Randy Presuhn discussed an alternate approach to =
indexing and discriminators.</FONT>
<BR><FONT SIZE=3D2>Nested unions will be ugly.</FONT>
<BR><FONT SIZE=3D2>WH: if you do a GET against a discriminator, you =
need multiple round trips.</FONT>
<BR><FONT SIZE=3D2>RP: </FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Bert proposed having a separate branch for SMIv3 =
modules. This would permit better addressing dereferencing, without =
needing the .1 for SMIv2 compatibility.</FONT></P>
<BR>
<BR>
<P><FONT SIZE=3D2>Day Two</FONT>
</P>
<P><FONT SIZE=3D2>Discussions of indexing by AB and RP.</FONT>
<BR><FONT SIZE=3D2>Discussing of search capability requirements via =
indexing.</FONT>
<BR><FONT SIZE=3D2>Discussion of SQL interfaces and whether that level =
of searching is needed.</FONT>
<BR><FONT SIZE=3D2>JS: operators often use regular expressions in =
Perl</FONT>
<BR><FONT SIZE=3D2>Continued discussions in research aspects.</FONT>
</P>
<P><FONT SIZE=3D2>There are a number of problems we're facing.</FONT>
<BR><FONT SIZE=3D2>Vendors won't do multiple disruptive incremental =
modifications to SNMP without having a vision defined for the =
longer-term goals. </FONT></P>
<P><FONT SIZE=3D2>Wild-carding and templates are going into the Cisco =
modular CLI with regular expressions, etc.</FONT>
</P>
<P><FONT SIZE=3D2>SteveW presentation</FONT>
<BR><FONT SIZE=3D2>Retrieval of aggregates and non-aggregates; </FONT>
<BR><FONT SIZE=3D2>ambiguity in OID specifications in proposed</FONT>
<BR> <FONT SIZE=3D2>does =
2.1.13 mean 2.1, index13 or 2.1.13 with no index</FONT>
<BR><FONT SIZE=3D2>goals:</FONT>
<BR><FONT SIZE=3D2> need to clearly =
separate the base+hierarchy from the index portion.</FONT>
<BR><FONT SIZE=3D2> Lexi-sort groups in =
reasonably useful way</FONT>
<BR><FONT SIZE=3D2> Backwards =
compatibility</FONT>
<BR><FONT SIZE=3D2> </FONT>
<BR><FONT SIZE=3D2>Proposal:</FONT>
<BR> <FONT SIZE=3D2>Different =
types of encoding for SMIv3 and SMIv2</FONT>
<BR> <FONT SIZE=3D2>.1 tree =
(tableEntry) vs. .2 for aggregates</FONT>
<BR> <FONT =
SIZE=3D2><base>.<hierarchy>.0.<index></FONT>
<BR> <FONT SIZE=3D2>AB: does =
index need to be to the right if we use .2 tree?</FONT>
<BR><FONT SIZE=3D2>More radical proposals</FONT>
<BR> <FONT SIZE=3D2>Change =
from BER to XML for greater control</FONT>
<BR> =
<FONT SIZE=3D2>No special =
encoding format needed to separate v2 and v3 formats</FONT>
<BR> <FONT SIZE=3D2>Could =
encode index in ascii format</FONT>
<BR><FONT SIZE=3D2>Discussion of XML and how to use it </FONT>
<BR><FONT SIZE=3D2> Not desirable to use =
XML to encode SNMP OIDs</FONT>
<BR><FONT SIZE=3D2>Cisco has found that people would like XML transport =
for CLI show and syslog retrieval</FONT>
<BR><FONT SIZE=3D2>SW: difficult to translate XML into </FONT>
<BR><FONT SIZE=3D2>RP: different xml formats for different purposes. =
Screen scraping operators are looking for info structure, not a =
protocol-specifying structure.</FONT></P>
<P><FONT SIZE=3D2>AB: CLI uses lots of string storage, so string =
storage in agents is not a constraint</FONT>
<BR><FONT SIZE=3D2>DD: why couldn't you have a parallel hierarchy that =
maps names to OIDs?</FONT>
<BR> <FONT SIZE=3D2>WH: =
largest # of questions is how to load mibs not application X?</FONT>
<BR> =
<FONT SIZE=3D2>And how do I =
find vendor Y's mib?</FONT>
<BR><FONT SIZE=3D2>DD: Do we want support meta-data in SMIv3 to do =
self-describing data?</FONT>
<BR> <FONT SIZE=3D2>It would =
get rid of the need to have the mib loaded.</FONT>
<BR> <FONT SIZE=3D2>This =
would also address the operator's need for </FONT>
<BR> <FONT SIZE=3D2>Resource =
constrained devices might need nothing more than the base OID for =
index, with URL of where the data actually is.</FONT></P>
<P> <FONT SIZE=3D2>URL points =
to actual mib specification on vendor's web site.</FONT>
<BR><FONT SIZE=3D2>Augments should be done to table, not Entry</FONT>
</P>
<P><FONT SIZE=3D2>Transaction Support (See Steve's message)</FONT>
<BR><FONT SIZE=3D2>Mandatory, optional parameters in required order in =
one PDU</FONT>
<BR><FONT SIZE=3D2>Debate over whether order is important to =
specify.</FONT>
<BR><FONT SIZE=3D2>Ordering can actually make it harder for agents, and =
complicates compliance testing unnecessarily.</FONT>
<BR><FONT SIZE=3D2>Debate over whether DEFVAL already provides the =
capability, if DEFVAL is mandatory for optional objects.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Small discussion of PDU chaining; transaction =
dependencies. Etc.</FONT>
</P>
<P><FONT SIZE=3D2>Are methods, transactions, and elements of procedure =
the same thing?</FONT>
<BR><FONT SIZE=3D2>There are differences in atomicity, and </FONT>
<BR><FONT SIZE=3D2>Transactionality that does not cross object =
boundaries is fairly simple.</FONT>
<BR><FONT SIZE=3D2>Transactionality across object boundaries requires =
more</FONT>
<BR><FONT SIZE=3D2>SB: we should have mandatory elements of procedure =
per high-level object (aggregate)</FONT>
</P>
<P><FONT SIZE=3D2>Discussion of use cases, and adding meta-data fields =
for how to do common tasks.</FONT>
<BR><FONT SIZE=3D2>Not necessarily machine-readable.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Discussion about USM user creation and how to explain =
the steps.</FONT>
<BR><FONT SIZE=3D2>With reuse, describe how to do common things.</FONT>
</P>
<P><FONT SIZE=3D2>The current pointer mechanism doesn't let you point =
at an instance of an attribute.</FONT>
<BR><FONT SIZE=3D2>Our OID system doesn't point well. Coming up with =
</FONT>
<BR><FONT SIZE=3D2>OIDs are good for registration, but we need a new =
value type </FONT>
<BR><FONT SIZE=3D2>It is difficult to determine where the index is in =
an OID.</FONT>
<BR><FONT SIZE=3D2>One saving grace is that you don't have the question =
of a reference to an aggregate.</FONT>
<BR><FONT SIZE=3D2>If we need a different data type to represent the =
new stuff pointers, that will bubble up into the SMI.</FONT>
<BR><FONT SIZE=3D2>SMIv2 RowPointers don't let you point at a =
particular instance of an aggregate.</FONT>
<BR><FONT SIZE=3D2>RP: A separation of the index from the base appears =
to be necessary to avoid ambiguity.</FONT>
<BR><FONT SIZE=3D2>AB: using the zero separator between base and index =
solves this.</FONT>
</P>
<P><FONT SIZE=3D2>DH: Do we want to not use OIDs?</FONT>
<BR><FONT SIZE=3D2>WH: If we use a union, we can allow a name to be =
defined as an OID or as an equivalent type.</FONT>
<BR><FONT SIZE=3D2>AB: </FONT>
<BR><FONT SIZE=3D2>RP: With unions, we want a choice; not a C-style =
union.</FONT>
</P>
<P><FONT SIZE=3D2>DH: Do we want to not use OIDs</FONT>
<BR><FONT SIZE=3D2>RP: The OID tail is wagging the SNMP tail</FONT>
<BR><FONT SIZE=3D2>WH: Can we </FONT>
<BR><FONT SIZE=3D2>WH: I like OIDs for registering base trees because =
it is good for master/subagent etc.</FONT>
<BR> <FONT SIZE=3D2>Instance =
level registration </FONT>
<BR><FONT SIZE=3D2>RP: Changing to </FONT>
<BR><FONT SIZE=3D2>WH; The 128-suboid limit will byte us with =
aggregated reusable types</FONT>
<BR><FONT SIZE=3D2>AB: you cannot anticipate how existing types will =
get reused.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P> <FONT SIZE=3D2>Level 1 - =
no change at all</FONT>
<BR> <FONT SIZE=3D2>Level 2 - =
algorithmic proxy translation</FONT>
<BR> <FONT SIZE=3D2>Level 3 - =
adding PDU types, </FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>RP: Reference to aggregate is only useful with a new =
PDU format.</FONT>
</P>
<P><FONT SIZE=3D2>Do we need to deal with whether old PDUs can find =
reference leafs in new format where OID may exceed 128.</FONT>
<BR><FONT SIZE=3D2>RP: even limiting the strings to 16 chars, current =
mibs can exceed the limit. </FONT>
<BR><FONT SIZE=3D2>WH: VACM now cannot reference all objects, because =
some multi-string indexes can exceed.</FONT>
<BR><FONT SIZE=3D2>BW: especially when we start using IPv6 addresses as =
indexes</FONT>
</P>
<P><FONT SIZE=3D2>To Bert, are we allowed to move into considering not =
using OIDs?</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Discussion of new models to fit within the RFC2571 =
architecture, with v3xml messages, </FONT>
<BR><FONT SIZE=3D2>Extended discussion about constraints concerning the =
design, and how they are making it hard to meet the operators' =
requirements.</FONT></P>
<P><FONT SIZE=3D2>Discussion </FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>DD: the lack of a transaction model impacts all the =
way down to the instrumentation</FONT>
<BR><FONT SIZE=3D2>AB: mib design is also affected, with multiple small =
strings, etc. Lack of aggregate support in VACM.</FONT>
<BR><FONT SIZE=3D2>AB: sub-agents sharing columns in a table are =
problematic</FONT>
<BR><FONT SIZE=3D2>AB,RP: VACM has difficulty dealing with different =
policies for different aggregate concepts.</FONT>
</P>
<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Conformance</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>RP: CMIP used an OID per changed module. Once you =
change the typedef definition, the OID registration would =
change.</FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>AB: another crappy little rule: two module compliance =
statements - one for readonly, one for readwrite.</FONT>
<BR><FONT SIZE=3D2>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. </FONT></P>
<P><FONT SIZE=3D2>JS: The min-access clause means you can only count on =
the read-only; you can't count on it.</FONT>
<BR><FONT SIZE=3D2>WH: can we leave out "current" </FONT>
<BR><FONT SIZE=3D2>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.</FONT></P>
<BR>
<P><FONT SIZE=3D2>Detailed comparison of sming and smi-ds</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Do not use anonymous unions.</FONT>
</P>
<P><FONT SIZE=3D2><get PP.txt from Juergen to supplement the =
following.></FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>RP: You do not modify an existing struct that has =
been published for purposes of reuse.</FONT>
<BR><FONT SIZE=3D2>JH: Tables can be augmented; that resolves that =
issue.</FONT>
<BR><FONT SIZE=3D2>JS, JH, WH: it is undesirable to modify a struct =
typedef that is in use.</FONT>
</P>
<P><FONT SIZE=3D2>SMIv3 is the name of the output of this WG.</FONT>
</P>
<P><FONT SIZE=3D2>Change date format to YYYY-MM-DD HH:MM</FONT>
</P>
<P><FONT SIZE=3D2>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*</FONT></P>
<P><FONT SIZE=3D2>AB: Likes new types, consistency in capitalization. =
</FONT>
<BR><FONT SIZE=3D2>OK</FONT>
</P>
<P><FONT SIZE=3D2>base types should not be IMPORTed. Derived types must =
be imported.</FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT SIZE=3D2>Use 0x prefix to denote hex strings - no =
consensus</FONT>
</P>
<P><FONT SIZE=3D2>Pointer as a base type rather than OBJECT IDENTIFIER, =
to keep the language more independent of the mapping language. =
Deferred? </FONT></P>
<P><FONT SIZE=3D2>Dotted notations: no conclusion on the =
different types of representations.</FONT>
</P>
<P><FONT SIZE=3D2>Float types: In the objectives document. </FONT>
</P>
<P><FONT SIZE=3D2>Enumeration vs INTEGER - consensus</FONT>
</P>
<P><FONT SIZE=3D2>Display formats in mib definitions; don't =
change</FONT>
</P>
<P><FONT SIZE=3D2>Comment delimiters - rough consensus "//" - take to =
list</FONT>
</P>
<P><FONT SIZE=3D2>CAPITALIZE KEYWORDS - (not base types) - =
consensus.</FONT>
</P>
<P><FONT SIZE=3D2>Consistent syntactic structure - "int x" rather than =
"x int" - consensus</FONT>
</P>
<P><FONT SIZE=3D2>Drop Last-updated clause - consensus. Revision =
clauses are mandatory.</FONT>
</P>
<P><FONT SIZE=3D2>No semicolon on IMPORTS clauses - consensus. IMPORT =
on each import clause (one per file with imports).</FONT>
</P>
<P><FONT SIZE=3D2>Keep SYNTAX clause</FONT>
</P>
<P><FONT SIZE=3D2>Use STRUCT, not class.</FONT>
</P>
<P><FONT SIZE=3D2>Can notifications be defined within the scope of an =
aggregate? </FONT>
<BR><FONT SIZE=3D2>AB: Notifications are not data definitions. </FONT>
<BR><FONT SIZE=3D2>Discussion of notifications </FONT>
</P>
<P><FONT SIZE=3D2>Discussion of variable declaration syntax. </FONT>
<BR><FONT SIZE=3D2>Consensus - ARRAY preferred over TABLE. </FONT>
<BR><FONT SIZE=3D2>Consensus - INDEX clauses might not always be bound =
to the aggregate type to allow index swapping.</FONT>
<BR><FONT SIZE=3D2>Consensus - INDEX clauses are only allowed in =
ARRAYS.</FONT>
<BR><FONT SIZE=3D2>Consesnsus - VAR <aggr-type> notation. Needs =
some further discussion.</FONT>
</P>
<P><FONT SIZE=3D2>SMIv2 limits the first two sub-OIDs. Expand to permit =
other legal ASN.1 leading OIDs.</FONT>
</P>
<P><FONT SIZE=3D2>Do not distinguish between OBJECT-GROUPS and NOTIFICAT=
ION-GROUPs.</FONT>
<BR><FONT SIZE=3D2>RP, DH: We really need to work on making this =
easier. </FONT>
<BR><FONT SIZE=3D2>AB: I would like to be able to tell what changed =
between version N and N+1.</FONT>
<BR><FONT SIZE=3D2>AB: Module compliances are difficult to keep =
properly maintained.</FONT>
<BR><FONT SIZE=3D2>Go to list for proposals.</FONT>
</P>
<P><FONT SIZE=3D2>EXTENDS/EXPANDS - not sure what we're doing with =
these yet. SPARSE-AUGMENTS.</FONT>
</P>
<P><FONT SIZE=3D2>MODULE - this module (in compliance) is superfluous. =
Consensus - eliminate for "this module" (MODULE needed when =
compliance statement is done outside the module.)</FONT></P>
<BR>
<P><FONT SIZE=3D2>Documents:</FONT>
<BR><FONT SIZE=3D2>1. SMIv3 Language Definition (Andy, JS, =
Frank)</FONT>
<BR><FONT SIZE=3D2>2. SMIv3 MIB Modules (core types) (JS)</FONT>
<BR><FONT SIZE=3D2>3. SMIv3 Guidelines (AB)</FONT>
<BR><FONT SIZE=3D2>4. Transition from SMIv2 (AB, Chris Elliot)</FONT>
<BR><FONT SIZE=3D2>5. Capabilities MIB (AB)</FONT>
<BR><FONT SIZE=3D2>6. INET Modules </FONT>
</P>
<P><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> =
<<SMIngMinutes060602.txt>> </FONT>=20
</BODY>
</HTML>
------_=_NextPart_001_01C25594.1F1B62B4--
------_=_NextPart_000_01C25594.1F1B62B4
Content-Type: text/plain;
name="SMIngMinutes060602.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="SMIngMinutes060602.txt"
SMIng June 6 2002
RP Randy Presuhn,=20
DD Dave Durham,=20
BW (Bert Wijnen),=20
AB,=20
SW waldbusser,=20
GW waters,=20
WH hardaker,=20
RF Rob Frye,=20
DH Dave Harrington
JH Joel Halpern, =20
CE Chris Elliot
Agenda bashing.
Presentation by Juergen =96 opinions on directions
Do we want it to do just monitoring or also config.
We already want=20
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=92t 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.=20
AB: it is ok to work on the assumption we may enhance the protocol.=20
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=92t =
identified where the boundary is yet.
AB: I think that we create new functionality with new formats, but we =
can=92t 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.=20
GW: want to carry info over SNMPv2/3; want compile SMIv2->SMIng, =
don=92t care about SMING->SMIv2
Joel: where both sides have equivalent semantics, auto translation is =
desirable. Where they don=92t map, it isn=92t important. We shouldn=92t =
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=92ve dealt with
SW: nor apps I know. This doesn=92t break apps
WH: Table retrieval may break. But we shouldn=92t use old tools to =
display new structures.=20
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=92t 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
=09
Slide: what to change
JS:=20
RP: It is valuable for the language to be able to specify methods.=20
J: let=92s not fool ourselves into thinking giving them these tools =
will make snmp better for configuration.
AB:=20
RP: semantic level of a specific IDL.=20
J: currently done in description clauses and text surrounding the mib. =
Can we=20
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 =93METHOD: Create New User: <recipe for doing =
certain types of things>=94 In the object clause. Suggesting=20
GW: When it comes down to
WH: There are common things that are 99% of the usage of the object. We =
don=92t 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.=20
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=20
DH: Need to keep distinction between use case and elements of =
procedure/method.
AB: machine parseable might be nice, but we=92re not engineering that =
now.
Slide: what to change:
AB: do not want annotational to allow vendors to write more proprietary =
SNMP dialects.=20
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=92t 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=92t 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?=20
DH: we should try to align our terminology with common software =
development terminology.
Consensus =96 shouldn=92t 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=92s consider some deltas from SMI terminology:
Attribute: a nameable element within an aggregate.
Base Types: [base types are Integer, etc. =96 put in ABNF]
Aggregate types:=20
Derived Types:=20
Arithmetic types: C ints,=20
<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>=20
<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?=20
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?=20
AB: we=92re rehashing again. Currently every instance Is manually =
mapped, which negatively impacts reuse.=20
JS: We have no problem with nesting.
JS: I=92m neutral on the hierarchical naming. We can research it =
further.
DD: Does Frank thinks there is a problem with hierarchical naming?
JS: Let=92s ask Frank.
AB: Frank=92s previous comment was =96 existing tools won=92t 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.=20
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=92t 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.=20
Andy did a walkthrough of how hierarchical naming works with DS =
proposal.=20
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:=20
JS: this tries to address a problem, but doesn=92t 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=92s 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=92re facing.
Vendors won=92t do multiple disruptive incremental modifications to =
SNMP without having a vision defined for the longer-term goals.=20
Wild-carding and templates are going into Cisco modular CLI with =
regular expressions, etc.
SteveW presentation
Retrieval of aggregates and non-aggregates;=20
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
=20
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=20
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=20
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=92t 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=92s 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=92s need for=20
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=92s web site.
Augments should be done to table, not Entry
Transaction Support (See Steve=92s 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=20
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=92t let you point at an instance of =
an attribute.
Our OID system doesn=92t point well. Coming up with=20
OIDs are good for registration, but we need a new value type=20
It is difficult to determine where the index is in an OID.
One saving grace is that you don=92t 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=92t 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:=20
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=20
WH: I like OIDs for registering base trees because it is good for =
master/subagent etc.
Instance level registration=20
RP: Changing to=20
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 =96 no change at all
Level 2 =96 algorithmic proxy translation
Level 3 =96 adding PDU types,=20
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.=20
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=92re 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=92t we try to develop a new thing =
from scratch.
Discussion of new models to fit within the RFC2571 architecture, with =
v3xml messages,=20
Extended discussion about constraints concerning the design, and how =
they are making it hard to meet the operators=92 requirements.
Discussion=20
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=92t change when the =
object changes because the existing usage isn=92t impacted by the =
internal change of the object data.
WH: =85ability 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 =96 =
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.=20
JS: The min-access clause means you can only count on the read-only; =
you can=92t count on it.
WH: can we leave out =93current=94=20
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.=20
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 =96 no consensus
Pointer as a base type rather than OBJECT IDENTIFIER, to keep the =
language more independent of the mapping language. Deferred?=20
Dotted notations: no conclusion on the different types of =
representations.
Float types: In the objectives document.=20
Enumeration vs INTEGER =96 consensus
Display formats in mib definitions; don=92t change
Comment delimiters =96 rough consensus =93//=94 =96 take to list
CAPITALIZE KEYWORDS =96 (not base types) =96 consensus.
Consistent syntactic structure =96 =93int x=94 rather than =93x int=94 =
=96 consensus
Drop Last-updated clause =96 consensus. Revision clauses are mandatory.
No semicolon on IMPORTS clauses =96 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?=20
AB: Notifications are not data definitions.=20
Discussion of notifications=20
Discussion of variable declaration syntax.=20
Consensus - ARRAY preferred over TABLE.=20
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 =96 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.=20
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 =96 not sure what we=92re doing with these yet. =
SPARSE-AUGMENTS.
MODULE =96 this module (in compliance) is superfluous. Consensus =96 =
eliminate for =93this module=94 (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=20
------_=_NextPart_000_01C25594.1F1B62B4--