[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Updated SMIng Meeting Minutes...
>>>>> Durham, David writes:
Dave> Any final comments before I submit these on Friday? -Dave
Below are some (mostly editorial) changes.
/js
--- sming-minutes.txt.orig Thu Apr 12 21:52:40 2001
+++ sming-minutes.txt Thu Apr 12 22:03:23 2001
@@ -22,8 +22,8 @@
assumed scope is that this work is to focus on merging the SMI/SPPI along
with repairs and fixes that are over due for the SMI. Any improvements that
are to become requirements need to be justified e.g. in terms of improving
-ease of use/operational problems, reduced size of code, or clarity. Also,
-the requirements are being identified as basic (part of the SMI/SPPI),
+ease of use/operational problems, reduced size of code, or improved clarity.
+Also, the requirements are being identified as basic (part of the SMI/SPPI),
necessary to fix, good to fix, or new.
Another assumption is that the mapping to a protocol can be separate from
@@ -44,7 +44,7 @@
the SMIv2 isn't going to disappear overnight.
There is the assumption that SMIng can extend, fix or even remove certain
-thigs that are already in the SMIv2/SPPI. These are exceptions that need to
+things that are already in the SMIv2/SPPI. These are exceptions that need to
be listed separately, however. E.g. It may be beneficial to stop use of
IMPLIED as defined in the SMIv2 because it is confusing. Likewise, the lack
of 64 bit integers in the SMIv2 should not prevent the SMIng from supporting
@@ -53,7 +53,7 @@
Instance identification may need to be generalized somewhat in SMIng simply
because COPS and SNMP identify instances of data differently. Moreover, SNMP
itself may change INDEX ordering across different tables. What SMIng can do
-is describe what attributes are suitable use within an INDEX, and leave it
+is describe what attributes are suitable for use within an INDEX, and leave it
up to the protocol mapping to actually determine how a particular table is
to be indexed.
@@ -78,11 +78,11 @@
are currently in the SMIv2/SPPI should also be exposed as required to be
removed. The Requirements team will review additional input from the mailing
list and then work to finalize a set of well-understood, and properly
-motivated requirements for the document to go to last called in may.
+motivated requirements for the document to go to last called in May.
An issue was raised around versioning and how to make versioning
intelligent. This issue then became whether or not there are bounds on the
-most basic types, as ANS has no bounds but MIB compliers don't allow
+most basic types, as ANS.1 has no bounds but MIB compliers don't allow
unbounded values. We should learn from past mistakes. Basically, we should
not be bound by current implementation issues at the highest level of
abstraction, the mappings should worry about it. Counters are an example, 32
@@ -99,7 +99,7 @@
advanced constraints are among those features that are not supported.
Motivation is also lacking for support of such features.
-2. David Harrington Next presents an itemized list of requirements. The
+2. David Harrington next presents an itemized list of requirements. The
requirements list was taken from the requirements document and put in a form
more convenient for the WG to address, requirement by requirement. The
feature list lists the proposed requirements by name, describes the status,
@@ -119,7 +119,7 @@
* Protocol Mapping (basic)
The protocol mapping requirement specifies that SMIng must be able
to map directly to the SNMP/COPS protocols. It doesn't *have* to map back to
-the existing SMIv2/SPPI inorder to do this. This doesn't mean that it can't,
+the existing SMIv2/SPPI in order to do this. This doesn't mean that it can't,
however, rather there should be a requirement that the SMIng can translate
back to the SMIv2/SPPI as well, so that existing tools will not be made
instantly obsolete. What the charter is describing is a long term goal of
@@ -130,15 +130,15 @@
should be able to evolve, and support features that are not part of the SMI
today.
* Instance naming (align)
- It was pointed out that Instance naming has different requirements
-at the protocol independent level vs the protocol mapping. There is some
-benefit to using the same data with different indexing, eg. Reordering
+ It was pointed out that instance naming has different requirements
+at the protocol independent level vs. the protocol mapping. There is some
+benefit to using the same data with different indexing, e.g. Reordering
tables.
* Base data types (basic)
These are Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits,
OctetString.
* Extended data types (align)
-Allow mechanism to allow base types to be defined as newe types which
+Allow mechanism to allow base types to be defined as new types which
provide additional semantics ; Counters, Gauges, Strings, etc. SMI uses
application types and textual conventions. SPPI uses derived types. This is
essentially the ability to derive TCs from TCs.
@@ -150,7 +150,7 @@
extensible.
* Accessibility (align)
Attribute definitions must indicate read/write/created/deleted and whether
-are accessible for notifications or are non-accessible Align PIC-ACCESS and
+are accessible for notifications or are non-accessible. Align PIB-ACCESS and
MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS
* Derived types (basic)
* Enumerations (basic)
@@ -179,7 +179,8 @@
Group definitions into subject categories. Concrete instances may only
exist in the scope of the given subject category or context
* Agent capabilities (basic)
-Provide mechanisms to describe implementation
+Provide mechanisms to describe implementation capabilities relative to
+compliance requirements.
* Remove implied (good to fix)
SMIng SNMP mapping should remove the IMPLIED indexing schema. IMPLIED is
confusing and most people don't understand it. It may be good to get rid of
@@ -197,9 +198,9 @@
groupings. Required to map same grouping of attributes into SNMP and COPS-PR
tables. Allows to group related attributes together. Ie. InetAddressType
and InetAddress typically go together. It was suggested to rename this to
-classes or attributes or structs as they do not involve methods (as the name
+classes of attributes or structs as they do not involve methods (as the name
class may imply)
-* Inhertiance (new)
+* Inheritance (new)
Provide mechanism to extend aforementioned attribute groupings (classes of
attributes).
* Abstract vs. concrete classes (new)
@@ -223,14 +224,14 @@
agent interact [Juergen Schoenwaelder] - alleviate confusion between where
the method is implemented (methods are on agent, whereas procedure runs on
manager side) - alter following attributes in following order in order to
-reach this goal? [Juergen Schoenwaelder] - correct [??] - now specifying how
+reach this goal? [Juergen Schoenwaelder] - now specifying how
to write manager.
* Arrays (new)
Allow definition of arrays of attributes. It was not clear how arrays are
mapped to fixed tables. Indexing and atomic access is also unresolved.
* Composition (new)
Provide support for composition of new compound types from more basic
-(potentially compound) types. E.g. Reuse a compound class of Inetaddress and
+(potentially compound) types. E.g. Reuse a compound class of InetAddress and
InetAddressType within a filter class that filters on a source and
destination address. This is different from a derived type in that previous
constructs are reused, just like structs in structs. A (x,y) point struct
@@ -254,7 +255,7 @@
need to be modified together (such as InetAddressType, InetAddress). These
constraints may be implied by classes of attributes implicitly assuming that
attributes grouped together logically are manipulated together. - assuming
-you are using a tool to do this, you could make sure that InetType and
+you are using a tool to do this, you could make sure that InetAddressType and
InetAddress end up in the same request, for example. Could be in the
specification and tool could make sure that ASN.1 could be written correctly
to ensure this. - can formally specify and tools can make check to do the
@@ -266,7 +267,7 @@
Provide mechanisms to explicitly specify associations? Discussion around why
this is needed to be explicitly specified in the language, as one can model
associations as a table with two pointers. There was also the question about
-how is associations are any different than the relations requirement. [David
+how associations are any different than the relations requirement. [David
Harrington] - relationships can be embedded directly in class, while
association tend to be separate classes. Fundamental language requirement
appears to be that pointers can be specified. Relations/pointers and
@@ -284,7 +285,8 @@
is different than AUGMENTS because [Juergen Schoenwaelder] - AUGMENTS means
every row in B has a row in A (1-to-1), EXTENDS is sparse augmentation
(1-to-[0,1]), EXPANDS means a row in B may have many rows in A (1-to-N).
-Could be used to emulate arrays by using creative indexing.
+Could be used to emulate arrays by using creative indexing. Already in
+MIBs but not formally defined.
* Machine readability (new)
Complete ABNF specification of grammar is desirable. SMIv2 has none. This
should be renamed to ABNF specification requirement.
@@ -307,7 +309,7 @@
Fundamentally, the proposed requirements will not become real requirements
unless their existence can be motivated by the WG. This process will also be
carried out on the mailing list. New proposed requirements that lack proper
-motivation will not be part of the final Requirements document. For new
+motivation will not be part of the final requirements document. For new
requirements, it would also be useful to specify how they may be
implemented, since requirements that cannot be implemented given the current
protocols are not valid for this WG. Not asking for the final proposal,
@@ -340,10 +342,10 @@
Forward translation, we MUST be able to convert all correct SMIv2 MIB
modules to one or more SMIng modules. This SHOULD be minimal amount of
effort, and initial pass SHOULD be assisted by automation. This will require
-intelligent decisions by the person(s) doing the conversion and there w ill
+intelligent decisions by the person(s) doing the conversion and there will
be many choices
Observation: it appears SMIng will result in many more direct dependencies
-than found in SMIv2. The tradeoff is fewer items defined and
+than found in SMIv2. The tradeoff is fewer items defined and
"elimination" of "cut-paste-and-adapt". This is a property of an OO design.
Requires much more initial analysis to get the base class definitions
"right", however.
@@ -352,11 +354,11 @@
originally in SMIv2 format back to SMIv2 MIB modules without loss of
information. Don't forget about compliances and capabilities.
-Standards Process Considerations, we don't want to recycle when update is to
+Standards Process Considerations, we don't want to recycle when update is
only to convert the format. This wasn't given enough attention with SMIv2.
Data type issues, we MUST solve issue of support for new data types in SMIng
-that don't exist in SMIv2. I.e. Ineger64, Unsigned64, Float32/64/128, Other
+that don't exist in SMIv2. I.e. Integer64, Unsigned64, Float32/64/128, Other
(Union).
Some were of the opinion that a reverse translation from SMIng to SMIv2