Meeting Minutes for the SMIng WG at the 49th IETF...

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

Meeting minutes below. Please let me know of any errors or omissions by
Tuesday. 
Thanks & Happy New Year!
-Dave


Next Generation Structure of Management WG (sming) minutes from the 49th
IETF
Wednesday, December 13 at 1530-1730; Thursday, December 14 at 0900-1130

Chair: David Durham email: David.Durham@intel.com
WG Charter: http://www.ietf.org/html.charters/sming-charter.html
49th IETF SMIng WG Agenda: http://www.ietf.org/ietf/00dec/sming-agenda.txt
Special thanks to the minute recorders:  Aiko Pras, Priya Rajagopal, and
Amol Kulkarni

First day, 12/13/00 (Wednesday):

Chair read out the agenda.

-------------------
Bert Wijnen our Area Director spoke briefly:
-------------------
This is a WG, not a BOF. Mislabeled a BOF because approval came late.
Came out of issues raised during the NIM BOF at Pittsburgh.
A lot of people were concerned about the direction of SMI and SPPI.
There also have been lots of requests to fix problems with SMI.
NMRG meeting after IETF48 had discussions about the way forward.
This WG is to try to get SPPI and SMI to merge together.

----------------------
Purpose of WG:
----------------------
Provide an improved DDL (Data Definition Language) for the IETF
Encourage convergence of DDL and modeling for in the IETF.

----------------------
WG Charter
----------------------
reusable templates
protocol independent
define registrar framework for reusable components


Goals and milestones
--------------------
Requirements
SMING core language doc
Protocol mapping docs
Establish registrar framework

Docs
----
nmrg-sming-04
sming-inet-modules-01
sming-modules-01
sming-snmp-01
TBD-
Requirements document
COPS-PR mapping

Should we do XML mapping?

------------------
Aiko Pras:
------------------
Aiko presents background for SMIng. Reasoning behind SMIng, and analysis of
the alternatives.

History:
Developed by IRTF-NMRG:
- SNMP over TCP
- SNMP compression
- SNMP getSubTree
- XML DTD for SNMP MIBs
- SMIng

Why start SMIng?
* SMIv2 relies on 1988 version of ASN.1
* Tools for SMIv2 relatively complex & out-of-date
* Some obvious data types were missing - 64 bits
* Limited facilities to reuse definitions
* SMIv2 didn't allow for extensions
* New, possibly incompatible variants appeared
Hence, the challenge: create a common DDL independent of protocols.

Info model vs. data model: UML, PIB/MIB
Information model (at the level of the information, can use UML for a
graphical representation). Under that you can have various flavors of a data
models, ASCII text representations of data, and mappings of the data to the
format over the wire. 
Once we have a data model, we could map it to a 'transfer' protocol.
SMIng is to concentrate on the data model level, integrating the SPPI and
SMI.
Need specific 'mappings' to different protocols.

Contest for the name of SMIng "MIB". 

Currently there is a mapping for the SMIng to run over SNMP-BER or COPS-BER
encodings. 

-----------------
Andrea Westerinen 
-----------------
Presentation of the SMIng Requirements.

Need to understand goals:
* Merge SMI and SPPI and add new capabilities.
* Try to be the ASCII representation for IETF info models.

We could make this the information model of the IETF. Described what is an
information model. OO design concepts in the IETF? Wouldn't it be nice to
design first before coding protocols? Nouns vs. verbs, information model
describes the concepts. The MIBs and the PIBs are the data models that can
be integrated. They describe the protocol specific implementation of the
protocol.

Information model:
* Description of key concepts
* OO recommended
* Protocol independent

Data model:
* Implementation specific
* Could include protocol specific optimizations

eg: Diffserv
* Started with a conceptual model - plain English - informal model
* Information model would formalize the above
* MIB and PIB

Requirements:
naming of classes:
- instance naming kept out. instances named relative to their protocol/data
model
- defn of basic data types including ptrs and references
- textual representation - ascii
- graphical views helpful
- ability to combine and group classes

Class Information:
name, attribs, events.
Methods: 
- not in language today. 
- behavior and operations such as reset device and sync with 'foo'
- return values


Inheritance: Moving from the general (abstract) to the specific. 
- single inheritance
- organizes and gives semantics to concepts
- allows reuse to concepts
- need single root for all derived classes?

Associations: Relations are a strength of OO... Associations can be modeled
as classes.
- relationships between class instances
- could be a class with two (or more) pointers / reference attributes
- multiplicity (1-1, 1-many etc) not in language today.

Constraints:
- attribute bounds and enumerations
- usage 
- read/write, optional vs. required
-semantic constraints ... constraints for creating/deleting.


Requirements missing in SMIng proposal
- should SMIng describe info models?
- support for associations
- support of methods


Questions: Should SMIng be an information model? Support for associations
including cardinality? 

--------------------
Juergen Schoenwaelder
--------------------
SMIng Overview:

Doc overview
Core language:
- type system
- class system
- identities
- model structure
- syntax and language extensibility
- versioning and extension rules

Core data definitions
Internet data definitions
Protocol mappings

SMIng Module:
- related SMIng definitions are contained in  a module
- names globally unique
- implicit import of definitions in a module, explicit import from other
modules
- doesn't allow forward references except in certain cases where there is no
other choice.

Data types: 
- new types can be derived from existing types
- optional display formats and unit definitions

SMIng class system:
- encapsulate attributes and events
- attribute type can be base, derived type or class
- classes can be derived - single inheritance
- classes can have associated events
- classes have naming scope for attributes and events

SMIng identities:
- provide mechanism to identify constants w/o a central authority
- names are scoped by module names
- pointer base type can point identities.

Syntax: 
- programmer friendly syntax. There is the look and feel similar to Java,
C++. Consistent structure of statements (easy to memorize). 
- language extensibility.
- improved compactness in normal cases
- easy to implement and efficient to parse
- no forward references as far as possible

Versioning: 
- declaration of new statements, unknown statements skipped.
- once published, definitions can't be changed
- definition status -current, deprecated, obsolete
- updated current definitions may not depend on deprecated or obsolete
definitions.
- module versions are identified by the time-stamp of the last revision. 
- extension rules allow changes between revisions.

Core Internet data definitions:
- there are a set of historic type definitions.
- port #, proto #, etc.
- fundamental class definitions
- n/w end pt
- transport end pt
- inet subnet
- filter definitions

Data Defns
-use Opaque to ship data types existing in the protocol.

Large set of fundamental data types.  Other data definitions and types. IP
filter definitions. Base type mapping. Interger64 maps to opaque. Naming:
Instance naming node statement to build the OID tree and to assign OIDs to
identities. Scalar and table statements to assign OIDs to class attributes.
Notification statement to assign OIDs to events. Flattens out any contained
class's attributes into a single flat table. Attributes of classes are
mapped to scalars in a group. 

Conformance defns:
- single group statements

-------------------
Questions:
-------------------

Why do the document and the ABNF restrict the reference clause to 7-bit
ASCII. We are not the only ones that use these tools.

Rob Price: What about the Integer 64 mapping issues... Why not put these
aside until they are resolved? 

??? Could not explain why pointers are used. Pointers are a type. They point
to an identity or an attribute?  What is the scope of pointers.
- OID. purpose of SMIng is data modeling not info modeling. We should not
shy away from complex associations

??? Are there reverse mapping tools? Tools for mapping from MIBs and PIBs
and regenerate them into SMIng. That would be a really good thing!

Bob Moore: If you have a SMIng module, and you are going down the COPS path,
are you mapping it to a MIB or BER... Keith: Does SNMP MIBs go away? Yes, in
the end game MIB/PIB go away. 
??? MIB modules are used for more. Is it one of the goals to map a SMIng
module into the SMI? 

??? Shouldn't SMIng compilers be required to compile SMIv2 documents. Won't
implementations choose the simplest? David: SMIv1 MIBs are still supported
today; it all depends on what the customer wants.

??? Docs give attributions to inet technologies incorporated.

Randy: GDMO shows how to make relationships more granular i.e. a CIM
association... Keith, perhaps pointer is the wrong name. There are
distinguished name and relative distinguished name. Pointer is a way to
realize an association in the information model. Juergen says should not try
to do arbitrary associations. 

Andy B: Some OIDs are pointers some OIDs are not. 

Andrea: If we want the relations to be more. Andrea will be willing to try
and do more.

Andy B: Why int32 in an info model what is the difference since it is also
an int32 in the data model. Color and BW TV example (forward & backward
mapping). There will be a lot of problems with the mappings. If there is a
class contained in there and there are variable lengths in the INDEX, you
can't get at the individual attributes. Juergen: Not really true, OID
namespace is flattened out so there are still OIDs for each an every
attribute contained or not. Steve: Foo.inet address there are individual
elements. Interface number are also in the same data structure. 

Andrea: Int32 are not different in the info model/data model. It is really
making some additions and clarifications, not chaining basic data types. 

David Perkins. Polymorphism is not mentioned? Andrea: Specifically for
events, this is a good requirement to add. Polymorphism will also be
important when dealing with methods.

MIB to PIB transformations are very important and should be a requirement.
Andrea, it may not be 1:1 mapping. If the mapping is unreasonable it is not
good to do. Juergen: Does not see a need to map each way. There may not be a
reasonable way to get the mapping backwards from SMIv2 module to SMIng
module. Information is lost.

Andy B: What I meant by my comment is there should still be a basic mapping,
but it should still be as best as possible. 

Steve Multon: Jeff Case wishes he could, but did not make it. I do not want
to close the door on taking a smaller step to merge the SPPI & SMI. OO may
be too much. In response Juergen says that there are those that want SMIng
to do even more.

David Perkins. Thinks this is a good start. Appreciates the work. We need to
move forward with this technology. Back to a question: Bags, there are two
types, sets and sequences. Also needs discriminated unions. Andrea: Hadn't
thought of everything, -Did include sequences. Andrea is interested in
considering more. These things were not purposely omitted.

??? Methods in language level may not be enough. Then we'll need methods at
the protocol level too. SNMPv4?
-(Jeurgen) At this time they do not exist, but there are four options:
 1. No methods.
 2. Methods in Data Definition language for SMIng.
 3. Methods in DDL for SMIng and mechanisms to map operations in SMIv2.
 4. Methods in DDL, and convince the SNMP WG to support it.

??? Specifying security requirements for objects in the language.  This
should be considered. Juergen: Haven't thought about at this time, but the
language is extensible. 

Randy? Possible solution to add to the examples. Log notifications with
opaque types in their varbinds. Given a MIB with log notifications that
contain opaque types. How does it happen in SMIng?


David Perkins. How will we track versions between different standards?
Missing slides: if these move forward with this work then what next?
Different WG will write different constructs. There will be independent
mappings for different protocols from different modules. Need to have some
process for how to use these definitions. Juergen: Definitions don't change
and don't go away. Hasn't thought much about this but doesn't think it is a
significant problem.  Keith: Trying to understand, maybe split the
documents.

??? Question on how to model a class with a bunch of attributes. Juergen:
Not modeled in a protocol specific manner. It is just a mapping, assign the
OIDs per attribute.

??? Is SMIng constrained by SNMP in ordering of names?

Shai: Named classes and so on are named differently in the SMI and may get
different numbers as a result when the SMIng definition changes. Juergen:
This is taking into consideration in the protocol mapping. Prevents the next
generation from having a value in-between. Constraining the protocol
mapping, not SMIng. 


----------------------------------------------------------------------------
---------


Day two 12/14/00 (Thursday)

----------------------------------
Keith presents some examples:
----------------------------------

While presenting the examples, many questions were raised...


Keith: SMIng starts the same as SMIv2 module statement block. Comments are
two backslashes. Typedef statements define types. There is no status
statement because absent means status current. Typedef has a size, format,
description, and reference. 
Question on if there was a size whether or not it will parse correctly.
Keith: No.
Enumerations can also go in typedefs. 
Classes: One is the Interface. Attributes, access, units, and description
per attribute per class. 
Bob: Where is MAX-ACCESS? Keith, now it is simply Access, has the same
meaning.
Glen: Where is the INDEX. Keith: we will see in a moment. 
???: Is there multiple inheritance. Keith: No (not for the classes
themselves anyway).
Harrie: Is it necessary to define before you use so that there is not a
forward reference. What if it is not possible to have a forward reference?
Ans: Not possible with OIDs.
Randy: Case in point, reverse index tables and are only lookup tables.
Mostly no forward references.
SNMP statement: Language extension. Extension snmp: oidStatements,
nodeStatements, scalarStatements, tableStatement, notificationStatement,
groupStatement, compliance Statement. 
Andy: Why insist on no forward references.
Forward references are possibly not needed anymore (they were in a previous
version). Some people felt that allowing forward references would not be
difficult to implement. 

There was discussion concerning whether the abnf part should be visible
within the SMIng, or if it should be hidden within the parser:
Randy: Pulling in BNF at processing time is much more difficult than forward
references. Juergen: do not have to process it (the ABNF). 
David P. Agrees with Randy. Would implement this as a parser. Keith: If the
parser comes across an unknown statement, it can ignore the statement. 
Randy: What that leaves us with is a compiler with the means of just adding
some goop into the parser for when it comes across these statements. There
is no advantage in having them as part of the language. If you do not
process the ABNF then there is no way to ensure it is followed. Keith:
Carries it along with the language. 
Juergen: Did not have an ABNF statement before. Now it is a documentation
issue, separated from the description. More formal. 
Randy: Concerned that the modules with ABNF, people will expect that it be
processed.  Implementation cost vs. benefit issue in implementing it. Randy
still was of the opinion that people could "abuse" the ABNF statement in
modules by putting any kind of ABNF statement there, so it should not be
there.
Juergen: Example is XML where it is used all the time. Randy: Why are they
there? Keith: Documentation reasons. 
David & Andy: Parsing does not provide anything. Randy: why not use XSL? 
Andy: Not clear if it is harmful or not to have these extensions.

Keith Continues... Scalars: Scalar group. Group name i.e. IP. Specifies the
OID. Specifies object attributes. Object name for the particular attribute
of a given class. Specifying that the MIB attribute must be specified for IP
forwarding (in this example).  
Not everyone was convinced that partial implementation of a class (or
partial inheritance; i.e. have multiple implements, but all the attributes
within that class need not be used) is a good idea. It allows, however,
different parts (documents) to move at different speeds along the standards
track:
David P. Table statement can have multiple implements (of classes). How do
you specify an attribute of this class? Randy: Partial implementation of an
imbedded class. 
Keith it is per attribute: Embedded in a class, potentially in another
embedded class. When you import a class you implicitly import all the
attributes within a class. 
Randy: Partial implementation of a class seems odd. There may be a semantic
for the class that implies all the attributes are to be used. Maybe this
comes from the CMIP world. CMIP allows partial inheritance as a partial
implementation of a class. 
Then there was a discussion on partial implementation of embedded classes
that are subclassed. Ans was to specifically mention the individual
attributes of the sub class and to import that class specifically. 

Some people liked the possibility to associate oids to the objects within
the implements part of the snmp statement. Not everyone thinks the term
"implements" is well chosen, since it may be confusing for people from the
CORBA / JAVA world:
??? When implementing the class. This is an instantiation of a class. Scalar
is an instantiation of a class. Implements is usually used with regard to
interfaces in RMI and CORBA. 
Randy: the point is that with regard to JAVA/CORBA there is a terminology
problem. Keith: Would instantiates be better. Juergen: it is more of a
mapping. Bob: this is the mapping part. Randy: Looks like the GDMO "derived
from." Same thing as the multiple inheritance in CMIP.

There was discussion about implicit ordering of attributes. Randy felt that
it was dangerous. This could happen when the OIDs of attributes change. So
an explicit OID should be specified when "implementing" the class as a
table. But the answer was that if numbering were done, then language would
be hindered even if it were only the SNMP portion of language that was
numbered. Another input was that implicit numbering was harmful if
reversioning had to be accommodated and multiple implements were used
(because the different classes would move independently):
???: what if there is an extension to an existing class after it is
instantiated. There is a problem when there are multiple implements in that
the different implements can change (revise) at different rates. Shai: this
is my question from the last meeting. Randy: There is another option... Why
not also provide the OID identifier (or just suffix) in this context? So why
not simply explicitly provide the OID for all the mapped attributes? Andy:
Implicit ordering is always dangerous, so always explicitly specify the
OIDs. Keith: it is annoying to add something in the middle and add the OID
statements. 
Jeff: For those who (don't?) write SNMP MIBs it is difficult to see how hard
it is to write a MIB. Need something any engineer can use to write a MIB.
The more explicit the harder it is to use, the more implicit stuff is
easier, but it has a significant reversioning problem... Thinks we really
need to make this explicit. 
Andy: There is another problem. There is no requirement that they (columnar
OIDs) even have to be in order and without holes!
Randy: Attributes in CMIP land, attributes have their own OIDs, attributes
always have their same OIDs. Lots of things in the SNMP mapping will be
driven by the way SNMP does things.
Also in answer to a question, it was mentioned that there could be multiple
implements of the same class as long as class was extended (inherited).

Table statement: Implements and oid, index, etc. Indexing alternatives:
index {ifIndex} augument ifTable; extends ifTable (sparse); expands ifTable
{ATM VclVpi, ATM VclVci}. Reorders ifStackTable {ifStackLower,
ifStackHigher}.
Andy: is it always true you want the derived classes to change their
indexing. Keith: Current rule is being maintained that you can't change
indexing without deprecating the whole table. Andy: this should only apply
to stable MIBs, not MIBs that are still in development. 

Dan: Can you define a table with different indexing? Randy: Index Iftype,
then as long as there is a forward reference... Dan: Scope as in the entity
MIBs. That's what the reorders is for. Wants another statement that is both
expands and reorders. 

Steve: Reorders... There will be another table. Do you need to implement a
new set of implements. Has an interest in this, because would not like to
duplicate this all over and over again. Complexity of the MIBs. Steve would
like to go further. 
Jeff: Problem is that you need to be backwards compatible with SNMP.
David P.: Points out that there is a savings because there is no duplicate
description and therefore far less redundancy for that reason alone. Also,
there are other indexing mechanisms. 
Glen: Avoiding redundancy is a very good thing!
Andy: Problem with expands when using implied in the table being expanded.  

There was a request to have in the table indexing something combining
expands and reorders. Another thing is to have different indexes, without
having to define different descriptions (in fact this is a request for
stronger reusability).

Conformance groups. Etc.

There was a proposal to get rid of "implied":
David: Can implied be removed? Kind of stuck with opaque, kind of stuck with
implied for compatibility reasons. But can it be deprecated... We agreed
that using it should be avoided as far as possible. 

---------------------------------
Juergen presents some more complex examples:
---------------------------------

Provided an example based on RMON2, with lots of reuse. 

Discussion on naming of objects within a table. Do we need "complete" names,
like for example "addressMapControlStatus" instead of simply "status"
(within the addressMapControlTable)? The current choice is based on
backwards compatibility. It is important that the bits over the wire remain
the same. Since names are not visible on the wire, some people liked to
change them:

Andy: The descriptors are flattened out, so the contained classes are given
OIDs at the same level as other attributes implemented in the table. 
Randy: Seems that the suffix, given a consistent naming scheme, don't need
to repeat. Juergen: Old MIBs did not follow a consistent naming scheme, so
it is hard to imply them all from the class and attribute names. Keith: But
if you do that, you will need to map them backwards.
Andy: Power of this is that RMON tools provide 20x as much code as needed.
This is great because redundancy is not a problem here (with SMIng?). Randy:
Agrees improved abstraction is a good thing, but could go even further. 
Juergen believes that scoping should be done by simply writing additional
modules. 

There were some differences in opinion on whether or not we could (should?)
make SMIng look closer to SMIv2. Shai Herzog wanted to work on a proposal:
Shai: What is the upwards side of the backwards compatibility: Juergen: take
SMI MIBs and reformulate them in SMIng. 
Randy: Do we need to do round trip identifiers of the round trip from the
wire and back to the new definitions?
Juergen: For the migration phase, it would be useful. ASCII not binary. 
Andy: How to do the transition to COPS-PR if attributes are dependent on row
status, which is not needed in COPS-PR. The protocol independence is an
issue here. 
Shai: Backwards compatibility file to ensure that the history. The next
generation output should be constrained by previous generation input. Make
the transitional thing optional so we can take it away. 
Jeff: Have the SMIng language had a programmatic way for that language to
map to SNMP. Create a way to bring in the existing SNMP MIB. This would be
the preferred way to do the transition. 
Scott/Randy: If there were methods, would so many of the SNMP
inconsistencies go away. Methods to more abstractly deal with operations in
SNMP.

----------------------------------
Moving on to the requirements discussion led by Andrea:
----------------------------------

Should SMIng be an information model language? This question is an
interesting question if you agree to the charter. Not everyone was happy
with the current charter. However, the charter wanted to define something
that is feasible, and the past discussion on NIM did not reach concrete
results. That's why the scope of the charter is narrow. Also we need a
solution now for current problems, like SPPI and SMIv2, improvements to the
SMI, etc.

Do we need methods? There was a feeling that methods in an SNMP world could
be implemented as a series of operations on traditional SMIv2 small objects.
However, these small objects could, for example, be located in different
tables. Some people really wanted methods to be in (Andrea).
Or is there a need for method signatures? What are they? 

Protocol dependent versus independent. Many people liked that idea, but some
people had a concern that they had to do work on mappings they are not
interested in. This is not a requirement, however. If you just want to
monitor certain objects, you don't have to bother with a COPS mapping.

Discussion about whether Andrea's list was a list of requirements or list of
issues to investigate. The comment was made that the language is extensible,
and new "requirements" (for example an association class) can be added
later. Comparison with GDMO and CIM. A concern was raised that modules
should still be easy to read by humans.

Also, there was a request to have more examples, particularly the more
complex ones. 


Discussion follows...

Andrea: Can add some features to make SMIng into an information model
language. 
Where data modeling begins and information modeling ends is blurry.  An info
model is a blank check. So "investigate the feasibility" to add
associations, support for methods, sequence of, semantic constraints,
ability to distinguish classes as abstract/very general vs.
concrete/instantiable. 
Bert: Focus is important. The SMIng WG is to do a data modeling language.
SNMP protocol improvements go elsewhere. This WG needs to focus on what is
feasible today. 

Keith: Methods... want to specify the semantics of operations. Can do this
in SNMP today.
Randy: Configure trap destination (high level operation). How many
request/response exchanges. How many transactions does it take to make a
trap destination set operation? 
Shai and Andrea agree.
Randy: High-level create. 
Andy: Problem with the charter. Suppose I intend to write a MIB using SMIng,
and then map it back to a COPS PIB, may require you to remove attributes &
rewrite those classes... or we should be start over again. 
Randy: It means might have things that make sense for SNMP and not for
COPS-PR, and if you think carefully then you might end up with something
that might work with both.
Andy: There is a need to simplify SNMP, why not just focus on that.
The answer was that SMIng encompasses protocol independent and protocol
dependent utility classes. There is much to be gained in sharing data
definitions across protocols wherever possible. Furthermore, this is already
blatantly obvious in the DiffServ MIB/PIB and the IPSec MIB/PIB. There is
>90% overlap in their definitions. This is the reason why the charter
included the text to integrate the SMI & SPPI. Nevertheless, the charter
also speaks to significant upgrades to the SMI that will be very beneficial
to SNMP regardless.

Randy: why not just use UML or an existing language that is out there. There
are indirect mappings from MIBs to IDL. 
Randy: Why not just use GDMO
Answer: The mapping of GDMO for generating MIBs from UML was "ugly", so
dismissed suggestion.

Bob mentioned that non specialists should be able to use SMIng. Randy
mentioned that although SMIv2 and SPPI had the semantics for features like
associations, no constructs are present. It seemed like the inherent
complexity of the SMIng might make it harder to use. It was suggested that
portions of the language NOT required should not be used. SMIng should not
make it harder to construct MIBs/PIBs. Discussion was supposed to be taken
to mailing list.
Dave D. Some of these extensions can be modeled, and do not have to be
primitives in the language. 

David H. Question on method signatures. We've talked about Methods, what
about method signatures, there is a distinction. Added SSIs (not APIs). ASIs
are APIs, which are method signatures. His question was on how methods were
mapped to protocol operations in SNMP. This question was modified to allow
SMIng to have support for "METHOD SIGNATURES". Also Andrea mentioned that
the method conveyed semantics and DID not specify internal interfaces (only
conveyed in/out parameters). She mentioned that it goes into the protocol
specific utility classes. Randy mentioned that setting of attributes to
achieve a particular functionality was an example of a method. David D.
mentioned that methods/operations could also be indirectly "modeled" using
the language, with only a few additions to the language primitives (eg.
in-out labeled attributes/parameters within a "method class"... Then control
the operation itself using a rowstatus-like "go-button" attribute). 

Andrea: We can learn from CIM. 
Further Bert decided that we would use only what's available currently
(well-understood and feasible) and incorporate other new requirements after
first specification.

David P. Does one slide. There is a one-letter issue. Between SMIng and
smicng there is a one-letter difference. Would like to change the name.
Bert: It is too late to change the name of the WG.  


-------------------------
CONCLUSION
-------------------------
Is there a need for an interim meeting? Ans: Yes (approximately 15 people
raised their hands for an interim meeting). If such meeting would be
organized, specific proposals for solutions should be on the table in time.
Such meeting could probably be held in February.