Draft minutes from the May SMIng Interim:

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

I would like the thank all those who attended the SMIng interim. The draft
minutes are below, please let me know if anything is missing or
misrepresented by the end-of-the week.
Thanks again,
-Dave 


Notes from SMIng Interim Meeting 
Held in Seattle, WA on May 18 & 19, 2001 at the Mayflower Park Hotel. 

The Agenda:

May 18th from 9:00am until 6:00pm:
* Status (1 hour)
* Review the final language requirements (2 hours)
*** syntax discussions ***
* Review SMIng compliance w/ requirements (2 hours)
* Review list of open issues in the SMIng language document (3 hours)

May 19th from 9:00am until 6:00pm:
* Review the list of open issues in the SMIng core modules (2 hours)
* Review SNMP mapping draft and its open issues (2 hours)
* Review COPS-PR mapping and its open issues (1 hour)
* Discuss SMIng->SMIv2 Translation (2 hours)
* Wrap up & other open issues (1 hour)


Meeting Attendees:

David Perkins
David Harrington
Wes Hardaker
Bert Wijnen
Andy Bierman
Juergen Schoenwaelder
Frank Strauss
Harsha Hegde
Jamie Jason
Jeff Case
David Durham

Status:
 
Document milestones are currently on track. The Requirements document was
just resubmitted before this interim based on the output from the final
requirements process.

General discussion around requirements and goals of the WG:

Procedure related: There was an issue on how many documents would be
required once SMIng was in place. Will there need to be MIBs and PIBs
generated as well as the SMIng? Will every working group have to create a
mapping document? Answers were that it is still too early to know, and no
decisions can possibly be made at this point in time. Bert expressed the
goal is that everyone will write SMIng documents, eventually, just like with
the SMIv1 to SMIv2 transition. In the meantime, mappings to SMIv2 will be
likely. If SMIv2 can be generated automatically from the SMIng, this may not
be a problem. As the SMIng is still under development by the WG, what the
total number of documents will be required cannot be known at this time. 

David Perkins is of the view that the MIBs and PIBs do not need separate
mapping documents since they are close enough already. It was also pointed
out that there are more MIBs than PIBs, so perhaps the COPS-PR mapping
should be more accommodating to the requirements of SNMP. The feeling of the
room was that keeping the number of required documents to a minimum is a
good idea, and that merging the COPS-PR and SNMP table mappings should be
done if at all possible.

David Harrington asked if it is the goal to replace MIBs and PIBs with
single specification that translates to the protocol encodings, or to have a
single language to translate into MIBs and PIBs. There was agreement that
the goal is to map SMIng directly to the protocol encodings, with MIB
translations available for backward compatibility in the near term.

AB: Question whether attribute classes imply that all attributes in class
means they are to go together. Does this have implications for the protocol?
What would an agent do if it receives the address type w/o the inetaddress?
Should all read+write attributes in a structure to be considered together as
an atomic set? Andy liked methods because they may help formalize the
correct behavior and thus simplify agent implementations. Dave Durham thinks
that everything that can be set in a basic data structure (class) should be
considered atomic to keep things simple. Don't have to change the protocol,
there just needs to be an understanding between the agent & manager. Bert:
this may be possible today, only it is expressed exclusively in the
description clause. Conclusion, there is noting in the class definitions
that have implications for the protocol, but proper groupings of attributes
will be valuable to describe the appropriate attribute combinations and
therefore proper/simplified protocol behavior and potentially simpler agent
implementations. 

Andy reemphasized the point that today all development requires CLI, which
is very simple to implement. Just to compete, MIBs need to be as simple as
possible. If the MIB development cost remains so much more than CLI
development costs, progress will not be made. 

Syntax issues were raised: DP: Other mechanisms can be used other than ASN.1
macros. Goal should be to make MIBs more readable and writable. But ASN is
the language that the SMI document is written using. Andy: There is still
the issue of the new vs. the old. Really want new clauses that allow for the
machine to specify formally many of the things that can currently only be
communicated by the description clause. 

David Perkins would rather have a different BNF than ABNF. Eg. He would
rather describe the SMIng in YACC... But, David Perkins can live with ABNF.
Others were satisfied with ABNF.

Discussion of the individual requirements:

Reqs 1-3 (Textual representation, human readability, machine readability)
are motherhood and apple pie, there were no issues.

DP: Req #4 (Naming) is not clear about which namespace. It should be
descriptor namespace and it should be hierarchical in nature. 

DP: Req #5 (Namespace Control) Should follow what is done w/ JAVA.
System.cisco.com... So it is possible to do this without a central naming
authority other than assigning the cisco name. Juergen: Agrees he doesn't
want to create a new naming authority. 

Consensus that #6 (Modules), and #68 (Module Namespace) are related, remove
first part (naming) as is covered by 5.

#7 (Protocol Independence) is in conflict with charter (only two protocols).
It should be reworded to say should or may support other protocols. This was
intending to convey that the protocol and SMI are distinct. MIB is distinct
from the protocol, but the SMI brings them together. DP: Reject number 7 and
keep it  to the Charter. Conclusion: Drop the requirement or make it say
should as far as SMIng supporting other protocols. 

#8 (Protocol Mapping) see notes above. WG will do the right thing. When push
comes to shove, the number of installed implementations wins, thus, today
SNMP will remain the primary focus. Conclusion: We should not hold up WG
progress on other issues to meat this requirement.

#9 (Translation) Fix should and SHOULD. Question about whether LDAP/other
mappings should even be mentioned.  Conclusion: remove the LDAP text, should
simply express need to map back to existing tools. Should say SMIv2 format,
not MIBs. Question on how much should be able to map, only to a degree, new
stuff may not map. Looking at the mapped document may not be as clear as
looking at a true SMIv2 document. DP: Thinks mapping to SMIv2 requirement
should be a MUST, others agree with SHOULD. This is a question of whether or
not all old MIBs must move to the new language. Bert: A SMIv2 MIB that uses
IMPLIED keyword, wants to move to full standard, then it can, as a SMIv2
MIB. It will not have to be translated to SMIng. New work will be SMIng.

#10 (Incomplete Translations) AB: This is a NOP. Would like to drop it, it
is not valuable for the WG to do. Or just take the SMIng document and make
it a comment in the SMIv2 mapping when translations cannot be done.
Conclusion: not a requirement for the current WG.

#11: (Instance Naming) This is expensive because it requires separate
mappings, one for COPS, one for SNMP. The only issue is in the use of
pointers and indexing that assumes there is a either one or a set of
attributes used for indexing. There was questions whether index pointers are
really a problem or not. If it really is a problem, the question is whether
or not the Instance Naming restrictions in SPPI should stay... why not
change the SPPI naming scheme to map SNMPs.  Conclusion is that this
requirement need not imply separate mappings as MIBs and PIBs are
sufficiently close that one specification covering both is possible.

#12: (Base Data Types) SMI and SPPI are already aligned w/ previous work.
Will this be carried over into SMIng? Conclusion is that SPPI & SMI already
have defined these. DP should have oids... Andy would rather keep oids as a
native data type since both COPS-PR and SNMP support them, so why
overcomplicate things to support hypothetical future mappings not even
mentioned by the Charter? Consensus is to add oid data type.
 
#13: (Extended Data Types) This includes derived types from derived types.
Dependency issues. Cutting and pasting is not much better, putting name of
updated TC in comment. So this seems to be a good thing to do. Conclusion:
Can only restrict constraints further in derived types.

#14: (Instance Pointers) If we had real rows instead of conceptual rows, the
issues go away. Row pointer can point to a particular row, and instance
pointer can point to any attribute in the row. Conclusion was we believe
there is a need for both identifying attributes in a row as well as the rows
themselves. 

#15:  (Row Pointers) Does a row pointer derive from an instance pointer?
Conclusion: Yes.

#16: (Base Type Set) Conclusion is that this is a fixed set of fixed size.
Issue is that no one can come and add a new base type, unless the SMI itself
changes.

#17: (Accessibility) Yes.

#18: (Derived Types) Yes. Can be more tricky for compilers. Will require
that parent type definitions are imported so they can be understood and
checked via the compiler.

#19: (Enumerations) Don't have centrally controlled namespace for
enumerations. Centrally controlled namespace is confusing here. Conclusion:
This should just say that all enumerated values must be part of the
enumeration definition.

#20: (Events) Generic name for notifications? (Jeff will take issue with
this terminology later, the event is the thing that happens, the
notification is the announcement of the event). Issue if the instances need
to be from the same class. Can data be from different tables and the same
rows? The answer is to determine if there are any standards-track MIBs that
do this multi-table notification today, if yes then we will need to support
it, otherwise no (the working assumption is no). Also, AgentX has problems
by not having bi-directional communication, and WG should consider how this
may affect the notifications.

#21: (Creation\Deletion) Andy: Creation and deletion are really just very
common methods. It is not clear how this is can actually be done in the
SMIng. Is RFC 2079 where the TCs are defined such that the protocol will
only allow creation/deletion via row status? Since the SMI has discussion
about creating and deleting rows, that needs to be carried into SMIng. Maybe
the answer is just to keep row status... Also, it seems the concept of
deletion is new, because the access clause does not say whether something
can or cannot be deleted. Should there be a read/create and delete?
Conclusion is that creation implies deletion as well, just as write implies
read. 

#22: (Range and Size Constraints) Consensus: Range constraints are good.

#23: (Constraints on Pointers) Typed pointers appear to be a useful thing.
Should add a memo to 23 that this may be able to be achieved by using a
generalized constraint clause... Isn't it just another value constraint, eg,
limit prefix of the oid's (row or instance pointer's) value to only be of
tableX, or tableY? Conclusion is we want them, but would like to implement
them as an additional value constraint if possible.  

# 24: (Uniqueness) Is there a reason to have multiple unique clauses?  Can
there be two unique things in the same class. This is a standard thing found
in database definitions. Consensus seems to be it is a good requirement, but
should add the ability to have multiple unique things (Social Security # and
Driver's license ID for example).

#25: (Tables), yes.

#26: (Table Existence Constraints) This is already done using comments,
often cut and paste table... Note that pointers don't imply existence
relationships. Augments for example implies that base table must exist for
the augmenting table to exist. Expands should have a similar interpretation
for 1:n relationships. Conclusion: This is a useful requirement.

#27: (Extension Rules) Derived from the SMI about how to extend things.
Extends is only one part of modify. 

#28: (Categories) IANA allocates subject categories/client-types. This
should be specific to the COPS mapping. This definition is at the module
level. DP would like to get rid of the mapping modules and instead have one
definition full of clauses that map to both COPS-PR and SNMP, clauses that
don't apply to a particular mapping simply do not apply. This may
overcomplicate things since SNMP won't have much use of it. Also, there is
the potential rat-hole of how to decide what the right category is.
Conclusion: This is a COPS specific feature not applicable to SNMP.

#29: (Agent Capabilities) Should be REMOVE Agent/Implementation
capabilities. The question is whether or not agent capabilities should be
removed or fixed. This should be a separate capabilities table in a MIB. 
 
#30: (Remove Implied Keyword) Change to deprecate the IMPLIED keyword.
Reasoning is potentially wrong.

#31: (No Redundancy) Andy would "love" to remove SEQUENCE.  General
consensus that we should remove table, entry, foo lowercase crap, etc. while
we're at it.

#32:  (Discriminated Unions) Yes. But Jeff would like to go even further and
allow for real unions. He thinks the protocol can support unions because it
doesn't care what data type goes with which oid, just the SMI cares, so fix
the SMI.

#33: (Classes) DP says this is a SEQUENCE? The value Andy sees this as
something that can support a set of attributes with methods that can bring
things closer to the inherent simplicity and value of CLI. The structure
provides some indication that these things are meaningful together. Juergen
calls it an attribute grouping. Call it a structure. Would like to add
semantics that managers can only send the whole compound type together.
Conclusion: This is a good thing to get into the SMI today, because it
describes what we want to encode into the protocol as well, so the structure
is not lost in the translation. May not have to even change the protocol,
just the attitude about how the protocol works, agents should not have to
accept a random list of var-binds just because SNMP can send them.

#34: (Single Inheritance) Could get inheritance simply via containment. But
there is no benefit in having to list all the items over and over again.
Inheritance also implies more meaning. Wes believes single inheritance w/
multiple levels is a good thing. Consensus was yes for the requirement, but
with some issues (should specify the end effect is similar to containment,
but provided additional meaning).

#35: (Abstract Classes) What does abstract mean from a data point of view.
What value is there in not instantiating a row? There is confusion around
what value abstract provides. Consensus was to remove this as a requirement.

#36: (Relationships) The umbrella concept that there may be a more general
way to describe relationships. Having the more formal description may help
parsing, having one field to express all relationship constraints may make
it easier on readers, etc. Consensus was that this too general to be a
useful requirement and it is redundant with all the itemized relationship
requirements already listed (pointers, inheritance, containment, etc.).
Remove the requirement.

#37: (Methods) Can we do methods without changing the protocol? Provide a
set of values, hit the go button, and read the result. This is a very
complicated procedure. Everyone agrees that Methods are useful, one end of
spectrum is a documentation tool for existing SNMP capabilities, on the
other hand, others see it as a protocol update, moving forward, to natively
support methods. Also, methods that return data are not possible in current
MIBs. Conclusion: Propose to wait and see if this is practical to implement
as a syntax that is useful and can map to the protocol. Remove as a
requirement at this time, describe it as a SHOULD.

#38: (Procedures) Set something, get something, set again, etc. Document the
strange steps to make the agent complete the task at hand. It is best this
be done in the description clause. Conclusion: remove as a requirement.

#39: (Arrays) Confusion around what this proposed requirement is trying to
convey. High-level issue is to describe a list of parameters to described as
if an attribute within a table/class. What is an array other than a table in
a table in the general case? There is a difference between a fixed length
array a variable sized array, but fixed is just a constraint on the more
general variable sized concept. Seems that variable arrays are doable using
the Expands relationship (index parent + index of contained array table,
lifetime of child table is controlled by parent table). Consensus is to keep
arrays, as long as they conceptually map to variable sized tables in tables.
Clarify text to say this (SEQUENCE OF, not SEQUENCE).

#40: (Composition) Seems redundant with classes/structures, we already
assumed we could contain structures in structures given you have groupings
of attributes. Really a reuse concept, specifies that the constructs can be
reused. Conclusion: Clarify text to say this.

#41: (Existence constraints) if create something in foo_bar table, something
in foo table must already exist. Is this a subset of #26 and Expands?
Dependency if another row must exist or a value be specified before another
row can be created. Likewise, when a row goes away, it may cause other rows
to be deleted as well. Sometimes there is fate sharing, sometimes not... Or
existence relationships. Conclusion: the better thing to do is avoid
explicit fate sharing and cover this with the description clause.
Inheritance, containment, arrays (Expands), already implicitly provide
existence constraints, simply add such text to their requirements.

#42: (Ordering Constraints) Not clear what this means. Why not in the
description clause? Conclusion: Remove.

#41 & 42 have no effect due to the agent to implementation dichotomy. Thus,
no value beyond the description clause. Conclusion: Remove.

#43: (Attribute Transaction Constraints) Is this just a crutch in case we
don't have methods? Isn't this RFC 2580: agent caps creation requires
clause. It would be much simpler to write agents if everything was enforce
transactional semantics, but special clauses to do this seems too much.
Should either use methods, or assume all attributes in a class/structure are
to be considered atomic. Conclusion: Remove.

#44: (Attribute Value Constraints) This seems to be infinitely complex to
express formally. May be worth doing if can cover 80% of the cases and it is
simple to express the constraint. Conclusion: Suggest we limit this to
discriminated unions/enumerated types. 

#45: (Associations) We want nothing to do with arrows and boxes and lines oh
my. Conclusion: Remove.

#46: (Association Cardinalities) Ditto.

#47: (Method Constraints) If we don't have methods, we don't need
constraints on methods.

#48: (Table Relationships) What does expands have to with reorders? Reorders
might be okay, BUT, these should be two requirements. What is the difference
between this new expands keyword vs. just including the base table's index
in the expanding table's index? Conclusion: Expands provides a mechanism to
implement contained arrays (#39) with the array's lifetime being dependent
on the lifetime of the parent table. Conclusion: Should separate the Expands
requirement from the Reorders requirement, everyone liked Reorders.

#49: (Float Data Types) Floating point data types: DP wants float and
discriminated unions as base types. Requiring support of floating point
numbers remains a highly contentious issue. Andy: What are the operational
needs for floating point types. Wes: Question whether or not SNMP will be
limited to network device support, or should it grow to support applications
and services. Juergen believes floats should be included. Jeff: What is the
difference between having a native float vs. a float structure with two
integer numbers, one being the mantissa and the other the exponent?

#50: (Compliance and Conformance) Yes. There may be a new grammar to express
compliance with objects written in the new grammar. Complexity of the MIBs
come from adding every feature imaginable. CLI and PIBs may be better in
that their requirements/compliance is simpler. MIN-ACCESS is just a cop-out.


#51: (Categories of Modules) Keep generic things in generic modules. Not
clear how this can be done with the language. Maybe analogy with header
files. Lots of process issues associated with doing this. Maybe there should
be a better way to create TCs that can be created by all. Conclusion: not a
requirement. 

#52: (Language Extensibility) Some mechanism that allows clauses to be
skipped over. Question whether on not SMIng currently provides this
capability. DP would like to add new clauses in separate documents just via
the extension clause. Conclusion: Language extensibility is a requirement.

#53: (Length of Identifiers) Should we get rid of identifiers should be
limited to 32 characters? Not clear what this provides. It will be fine to
keep it as is. Not a requirement.

#54: (Error Tolerant Compilers?) Seems in conflict with #52. It is not clear
what the requirement is here so remove it.

#55: (Core Language Keywords vs. Defined Identifiers) Don't include bits,
but include counter32... don't import any language key words, base types,
etc. Nothing that's part of the language. So this should be changed to say
not to import stuff. Intention is what is in the language that doesn't have
to be imported. Conclusion: Not a Requirement. 

#56: (i18n) English is the language of the IETF. It is not a requirement the
language must allow for internationalization.

#57: (Special Characters in Texts) Take the entire set of ANSI C escape
characters? Have in descriptions and references what we have today, then
fine, anything that needs to be done to support it in the ABNF, then fine.
Maybe extend with the double quote? This mainly is a concern for embedding
ABNF, not the double quote specifically. Conclusion: Should allow for some
escape characters.

#58: (Modules to Files) This is just an implementation detail. Conveys two
separate things, the back half and the front half.  Does not belong here.
Currently have RFCs with more than one information module. Just put in a
BCP, not part of the language definition. We want to make it easier to write
MIB documents, we don't want more annoying little rules that make it more
difficult.
 
#59: (Comments) If we go with a C-like language, then change the comment,
otherwise what's the point. This is not the problem, and not a requirement. 

#60: (Simple Grammar) Motherhood and apple pie. Does this really need to be
said? It is also not as obvious as it may seem. There may be other reasons
for choosing a longer ABNF. Shorter is not always better. Conclusion: Not a
requirement.

#61: (Place of Module Information) Remove the module identity clause? Put
the contents into the Module wrapper? This doesn't seem broken in the
current SMI. Issue also for assigning the root. There is no value in
changing this. If anything, it could be clarified as to how one assigns an
oid for this module identity. Still we will have to do it he old way when
mapping to MIBs and PIBs. Not a requirement.

#62: (Fully Qualified Identifiers) Isn't this already supported, isn't a
MUST? May be an issue with class syntax, dotted notation for class names,
etc.

#63:  (Readable Revision Date Representation) No reason to make more
complicated rules. Don't redo the date string. If we change the syntax
completely, then change this, otherwise don't bother.

#64: (Make Status Information Optional) Not important. Insignificant change.
Andy does not see how this will make things better, just more rules. 

#65: (Units and Default Values of Defined Types) Yes, should be in.

#66: (Arbitrary Unambiguous Identities) Obvious. Issue is whether or not it
is registered in the core language using oids?
 
#67: (Remove OIDs from the Core Language) Issue with aligning protocol
specific and independent naming. Both COPS & SNMP use oids, so why not just
align them (assuming we fix indexing). Clearly classes (structures) and TCs
should not contain oids... As is true today. Distinguish between pointers
and registration values. Wait and see how difficult mappings are. What is
the harm of having oids? Answer: The problem is we can't reuse classes if
oid is assigned at that level. Consensus: Reusable things need not have oid
assignments, question is whether everything needs to be reusable.

#68: (Module Namespace) What problems is this solving? Name clashes. Still
have to work with old names. Is this a language issue, ie. BCP? Too many
rules is not a good thing. Conclusion: Remove.

#69: (Problem with Protocol Dependent Constraints) Andy says this won't
work. Find the least common denominator and stick w/ it. Can be used to
prove deficiencies in the protocol mappings. Consensus seems to be work with
the least common denominator... Compilers should be able to check for this.
This is a serious limitation when people start using strings in index
clauses. Maybe this restriction could be relaxed by the new SMI. Conclusion:
No requirement here.

#70: (Problem with Phrasing Descriptions) Row=instance, table=class. Not
COPS-PR/SNMP problem, SPPI vs SMI vs SMIng problem. Depends on how much one
values the installed base, seems that one would want to keep installed base
happy as well. Andy uncomfortable with making everything as protocol neutral
and independent as possible. DH & AB Rather have clarity. Aren't MIBs
already protocol independent? No requirement here.

#71: (Problem with Mapping Protocol Specific Attributes) Fix the protocol
independent definitions to reference (eg. Tables) and half of these problems
will go away. Find a new word, not row, entry, rather a collection. Juergen,
rather just have a table concept, since that is what it is called in the
SPPI & SMI. Compliance clauses also already exist in the SMI & SPPI. We
should try where possible to make the protocol independent part as protocol
independent as possible. No requirement here.

#72: (Hyphens in Identifiers) Blame Jeff. One solution is to free ourselves
from ASN.1 and relax the "_" restriction. Keep the no "-" rule it as is
because no one is complaining it is broken. Jeff wishes that all identifiers
don't allow hyphens, and that this rule applies to all identifiers,
including module identifiers, etc. Conclusion: Allow "_".

#73: (Set of Spec Documents) All agreed on independence from ASN.1.

#74: (Allow refinement of all definitions in conformance statements) Jeff
agrees that this error must not be repeated in SMIng. 

#75: (Referencing a Group of Instances of a Class) Questions around what
value this has. DH would like to see how this gets specified in general.
Already, some types of relationships are knowable to tools if they are part
of the INDEX clause, but these aren't. The requirement is fine, the issue is
how to map this cleanly and more generally. Effectively a constraint clause
that can be parsed by a compiler, that just specifies the table and column
that contains a value used for grouping. 

Below are the notes for the second day after the requirements
discussion.

Open issues: SMIng language document: 

* Investigate if COPS-PR/SMNP mappings can be merged with the SNMP mappings
into a single table statement.
* Investigate relaxing the indexing restrictions in the SPPI... Only
necessary if pointers are clearly a problem in a merged mappings context.
* Consider adding more information within a table leaving classes to be
defined for only a subset of obviously reusable data. Thus, max-access, some
descriptions, and even some of the attributes themselves can be defined
exclusively in the table statement, not requiring a class for everything. 
* Add variable sized array semantics into the core SMIng language, so arrays
can be contained by classes/structures. Define appropriate mapping (probably
via expands).
* Add constraints for pointers (or improve value constraints to cover
row/instance pointer prefixes). 

- Change access back to max-access? Probably as this reduces confusion.

- Change readwrite back to read-write? Probably as this reduces confusion.

- Access statements do probably not belong in classes but into table
  definitions.

- Discussion about oid assignments. Can we do automatic assignment?
  Wes says that you can't do automatic assignments without a
  hierarchical name space. Automatic flattening into hierarchy (not
  possible to map back to SMIv2), user-defined flattening (allows
  flattening and SMIv2 mapping), create multiple tables (not always
  efficient).

- Importance of being able to map back to SMIv2? Jeff wants to map to
  SMIv2. There needs to be protocol support to have tuples in a row
  but this is not going to happen tonight. Be able to map what we have
  today and have parallel work on the protocol side.

- Jeff argues that SMIng is large disruptive change and that we need
  to standardize SMIv2 generated output from SMIng. This is different
  from the SMIv1 to SMIv2 transition. Bert says that we have to make
  that decision when things become mature. Production ready means draft
  standard status in the IETF.

- Dave Durham says if the language has real merit, then we can expect
  that WGs will pick it up anyway. We just have to get the features
  right.

- Andy remarks that the SMI is in the critical path of all MIBs and
  not a good place to find and fix bugs.

- Jeff argues that we need to have a disruptive change in order to 
  really get more features. We must mitigate the risk so that we can
  include more disruptive=valuable changes.

- Jeff expects the output in SMIv2 to be more chatty. SMIng should
  allow to specify index reordering which map to verbose SMIv2
  modules. This also means that SMIng input should be more concise.

- Wes says there is really no complex example. Juergen says that a
  student is working on the diffserv module. People feel that diffserv
  is too complex. But simple MIBs such as RFC 1213 are probably too
  simple since they are not build with reuse inside.

- SNA MIBs would have benefited from reuse. But who understands SNA?
  Jeff says that they changed in every revision. Andy is probably
  interested in reformulating RMON in SMIng.

- Jeff says that he would not even do compliance/conformance until we
  have some experience with the language. He believes that the current
  version is too large a risk. Juergen says that this is not a final
  version - things will change.

- Jeff says that we need to get experience in order to mature the
  technology.

- Technical issue 1: Can tables be lifted so that they end up in the
  protocol independent part? Can we allow to define table columns
  which are not classes?

- Technical issue 2: Can we make COPS-PR adapt to complex indexing
  structures? Does it cause a problem if we loose mapping to SPPI?

- Andy starts arguing about the lack of "methods" in SNMP land to
  compete with a CLI. Dave Perkins says that parameters are actually
  transitory objects what are only valid during the method call.

- Dave Durham asks whether Andy can write up a piece of syntax that
  explains what he is looking for? Andy explains that we need a PDU
  which needs input parameters, output parameters and is simple.

- Why does the set operation not return actual values? Jeff explains:
  If the outputs are not equal as the inputs: Encourages people to
  define transactions that are broken. Problem is that the get after
  the set is not repeatable. The information in the response packet
  might be lost, regardless of the transport, which is bad.

- In RMON (RMON polka) the secondary tables get created automatically
  when you create entries in the primary table. Syntactic sugar which
  allows you to do controlled behavior. In COPS-PR, there is a timer
  which eventually cleans up after the connection to the manager has
  been lost. Andy wants a control for a complete table, such as:

  {
    OwnerString,
    RowStatus, 
    {
      SomeData[],
    }
  }

  Setting the RowStatus to destroy should remove all SomeData values.
  Now we don't need rowstatus+ownerstring repeated over and over 
  again in each and every one of SomeData's row entries. 
  This example demonstrates the value of having composite structures
  in the language, as well as the value of allowing variable size
  arrays to be contained (not currently supported in the SMIng). 
  There was general agreement that the above structure provided
  real value, both for human understanding and formally representing
  semantic relationships... Thanks to Jeff for this example solution.
   
- Wes says this is all about fragmentation - SNMP usually does not hide
  fragmentation from the application.

- Jeff and Dave Perkins talk about commitment groups or transaction
  groups.

- Juergen says that the smCodeTable in the DISMAN-SCRIPT-MIB is a
  table which collects fragments until the control entry in the
  smScriptTable is being enabled.

- Back to issues. Listed below are the results of a Q&A regarding the
  open issues in the SMIng-01 language document:

1. REFERENCE clause does not matter. Keep them in since it is in both
   SMIv2 and SPPI.

2. Where is a reference to the official event/notification
   terminology? Jeff is uncomfortable with alarm and alert. After some
   discussion, Jeff seems to not disagree - that is good.

3. Wes says that perl unpack works much better than this mechanism.
   How to print out, how to parse it, how to encode it internally.
   Keep it? Fix it? Seems like yes.

4. Only allow discriminated or arbitrary unions? Allow unions if we
   believe that people need this for management. Must this be mapped
   to SMIv2 sparse tables? Does RFC 1905 allow to ship different types
   - it seems so. Worth considering fixing.

5. Typedef in classes - no support.

6. Default status - the answer is that status clauses should not be
   optional. Requires the usual rules how to revise SMIng modules.

7. OK.

8. Discussion on annotations. After some time, we managed to get the
   idea around. Andy says it does not look that dangerous as it first
   looked like. Dave Perkins says we do not need to standardize this.
   Jeff says a vendor can do it anyway - independent whether a vendor
   can do this or not. Need to see more compelling examples why this
   is actually needed. Jeff says it is more than skip over it. Lets
   see if vendors do something like this (collect information).

9. No glossary in the requirements.

10. Out of scope. Belongs into a BCP.

11. Extension rules - can we simplify them since we always break them.

12. Addressed previously during requirements discussion.

13. Addressed previously during requirements discussion.

14. Juergen clarified the purpose of the extension statement. It
    basically registered an extension so that you can unambiguously
    identify which extension statement someone is using.

15. Discussion about the marvelous DIAMETER M bit. Agreement to not
    have this.

16. Extension context statement: Where can you use a given extension.
    Dave thinks that it makes some sense.

17. Static? Jeff thinks it is generally not a good idea. Bert is not
    so sure this is bad.

18. Already done.

19. More formal restrictions: Dave Harrington asks why counters do not
    start at zero? Jeff answers that hardware start and agent start is
    not the same and it seemed simpler to do the delta at the manager
    rather than the agent. Dave Perkins says that people confuse
    default values with initial values.