This list of issues should be regarded as a kind of brainstorming checkpoint. Single issues do not represent final design decisions as long as they are not accepted. Feel free to send further issues and ideas to <strauss@ibr.cs.tu-bs.de> .

From: strauss@ibr.cs.tu-bs.de
Status: accepted

SMIv2 gets the information of a MODULE-IDENTITY clause registered in the registration tree, although this macro declares meta information on a certain module in general and is not related to management information. Hence this information should get no OID and should not get registered.

On the other hand, the use of OIDs in general is not restricted to information on managed objects. It may denote information of arbitrary kind. Hence, it make sense to give modules unambiguous OIDs to allow statements of supported MIB modules, for example. Is this the reason why MODULE-IDENTITYs are registered in SIMv2?

Conclusion: In SMIv2 there are two elements that identify a module: the name and the MODULE-IDENTITYs OID. At least for compatibility reasons this cannot be changed, but one can think about a better notation. The OID and other information that is contained in the MODULE-IDENTITY macro should be bound to the module as a whole, not to a special macro with further restrictions (must appear exactly once; must be the first definition) inside the module.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

Is the OID of a NOTIFICATON-TYPE needed on protocol level? If not, it should not be registered, just as issue #1 mentions.

Conclusion: It is needed. The OID identifies the notification.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

Is the OID of a MODULE-COMPLIANCE statement needed on protocol level? If not, it should not be registered, just as issue #1 mentions.

Conclusion: It is needed. We cannot assume that the OID is not used to identify MODULE-COMPLIANCEs.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

The AGENT-CAPABILITIES clause is useful to define the capabilities of a single agent implementation. By early 1999 the only use of this macro seems to be for internal documentation. It is doubtful, whether these statements should be registered in the registration tree.

Conclusion: It isneeded. E.g. it is used in the sysORTable, although it might not be good decision to express agent capabilities in static MIB modules. It would be more useful to be able to ask an agent about it's capabilities, getting real answers, not just OIDs that most managers don't know to handle.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

ASN.1 allows use of descriptors in a module before they are defined. This is also allowed in SMI MIB modules, although it is not needed and reduces the possible parser efficiency and increases the costs of implementation. Forward references should be disallowed in SMIng.

Conclusion: Mainly, this is true. The exceptions to the rule are

• index clauses which enumerate (subsequent) columns of a row, that are used for indexing, and
• create clauses which enumerate (subsequent) column of a row, that are needed for row creation.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

The purpose of these macros is to group sets of definitions. There seems to be no need to use different macros for grouping object types and notification types. Furthermore, it might be useful to declare groups that contain both kinds of definitions, although this would break backward compatibility.

Discussion: The macro names OBJECT-GROUP and NOTIFICATION-GROUP clearly identify the contents of such groups. Another construct, say `GROUP', would not imply that its members are limited to object types and notification types. Furthermore, the backward compatibility problem would lead to dirty names of split groups in SMIv2 that contain object types and notification types in SMIng.

Conclusion: We might use a single construct for grouping but with only one of two statements inside this construct to enumerate either object types or notification types.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

Referring ASN.1 as a base syntax language for SMI is problematic in multiple aspects: The referred version of ASN.1 from 1987 together with an addendum from 1988 is no longer available from the ISO standards documents catalogue.

Furthermore, the fact that the SMI is an `adapted subset' of ASN.1 - that means, some rules are missing, some are changed and others are added - is no win at all. ASN.1 tools cannot be used to parse SMI. The definition and specification of SMIng should be self-contained and independent from ASN.1.

Additional note: Some people may suggest to use XML as a base syntax. We should think about the situation ten years ago, where it seemed to be good choice to rely on ASN.1 as a base syntax... Since a language like SMI or SMIng shall have an intentionally long life cycle it should not rely on other specifications and be as self-contained as possible. Hence, we should not rely on XML which is not even an IETF RFC, not to mention an IETF standard.

Conclusion: The SMIng specification will be self-contained or based on specification techniques commonly known to the IETF, like the ABNF specification (RFC 2234).

From: strauss@ibr.cs.tu-bs.de
Status: accepted

To get a clear view of `problems' with the current SMIv2, it is important to distinguish at least two classes: Those problems that are just based on missing clarification in SMIv2 specifications and those problems that are real topics for the SMI design. All or at least most of the problems of the first kind should get clarification with the release of the SMIv2 full standard RFC documents, edited and submitted by the SMI-DT.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

It's important to preserve compatibility in different aspects:

On the SMI language level some degree of compatibility between SMIv2 and SMIng is needed to be able to compile SMIv2 MIBs to SMIng and vice versa.

• Identifiers should be unchanged. Shall hyphens be allowed? Mapping to underscores?
• Case sensitivity must be preserved. But: Problems with mapping to programming languages that don't support case sensitivity.
• Format of DISPLAY-HINTS and ExtUTCTime strings should be preserved or clearly mappable.
• The capabilities of subtyping (SIZE, enum, ranges) must be preserved.
• ...

On the protocol level no differences must be visible to keep compatibility. This was already the reason, why some SMIv2 types are indistinguishable on the wire (like Gauge32 and Unsigned32). They had to be compatible with the set of SMIv1 types. The only exception is Counter64. The only possible change would be not to differ between `real' ASN.1-defined types with the same syntax on the wire and something like appropriate textual conventions.

Conclusions: Most identifiers will be preserved. Restrictions on hyphens (underscores in SMIng) cannot be other than in SMIv2: they shall not be used instead for modules converted from SMIv1 (or SMIv2 which was converted from SMIv1).

OctetString and integer range subtyping might be denoted in brackets (no SIZE keyword). Enumerations might be denoted by an Enum keyword, followed by an item list in brackets. Implicit values for enum items will not be possible to enforce clearly visible item-value assignments. See also issue 46 for further ideas on subtyping.

The encoding of the base types existing in SMIv2 must not be changed. Nevertheless, newly introduced SMIng base types like floating point values (type names?), Integer64 and Unsigned64 should introduce new encodings to allow applications to decode them appropriately. Anyhow, this is not subject to the SMIng design.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

One could think about a strict separation of object and notification definitions of management information, module compliance statements and agent capabilities statements into different modules. Conclusion: There should be no unnecessary dependencies between modules. Every object type and notification type has to be a member of an appropriate group. Hence, there is a strong relationship between object and notification type definitions and compliance statements.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

Some texts in DESCRIPTIONs and comments contain information dependent on the knowledge of the SMI in a way that they refer to SMI macros, types or other definitions, which might look different in SMIng. Surely, this would not break compatibility but it reduces value to the reader. The degree of this problem relies on the degree of difference between SMI and SMIng.

Addition note: Surely, this problem does also exists for the conversion from SMIng to SMIv2. TODO: search standard MIBs for those situations.

Conclusion: Major terminology should be unchanged. Nevertheless, some long terms are exchanged by short ones and some terms are replaced by words which might better express its meaning, e.g. NOTIFICATION-TYPE is replaced by event.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

It might be useful to have a parsable syntax to define different kinds of relationships between tables, not just one-to-one relation as expressed by the AUGMENTS construct (see http://www.snmpinfo.com/tables.pdf). Those relationships include sparse dependency, table expansion and table reordering.

From: strauss@ibr.cs.tu-bs.de
Status: discussed

Counters need a companion object that indicates discontinuities. In SMIv2 this relationship is identified informally in the counter object type's DESCRIPTION clause. There should be a way to express this relationship sensible to an SMIng compiler (see http://www.snmpinfo.com/CounterTest/).

Conclusion: It could be even useful to have a flexible granularity for discontinuity indicators, e.g. table rows or tables.

Note: This is not just needed for counter objects. Another case: TDomain/TAddress pairs.

Note also: There are different possibilities to express relation:

• A new relation construct can name two to more related object types.
• Each object type can name each related object type. This would have the advantage of simply identifying each object's relations, but it would require forward references (see issue 5).
• Relations can only be expressed in one direction. E.g. a counter object type definition can state its discontinuity indicating object but that discontinuity object type definition cannot state the object types it serves. Note: Even this method could require forward references.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

There are no UNITS in TEXTUAL-CONVENTIONs. Why?

Conclusion: The TCs equivalent construct in SMIng should have an element to declare a units string. This will be applied to all object types that make use of this type and have no own units string which would overwrite the type's units string.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

One could think about the concept of modules as it is derived from ASN.1 and present in the SMI. Other information models like OMG IDL use a simple way of file inclusion (preprocessor-include) and have no possibility to include certain elements from other modules. Possible conflicts are avoided by namespaces. Could this concept be meaningfully adapted to SMIng? How could problems be avoided when those modules are not statically read in one go, but dynamically loaded on demand.

Conclusion: The static inclusion of whole files differs too much from the explicit import statements in SMI and could lead to name conflicts. Furthermore, the enforced import statements ensure an overview of imported modules and make descriptors shorter, since they need not be written fully qualified as long as they don't clash with local names.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

Companion of issue 7: Macros used in the SMIv2 can't be compiled as ASN.1.

SMIng will be defined from scratch, not dependent on any other language.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng should be defined in BNF in order to make it easier to implement MIB parsers with compiler generators.

Note: We'll use ABNF (RFC 2234) for the basic SMIng grammar specification. This has the advantage of a well known specification method and a precise specification down to lexical rules defining whitespace, comments, linebreak. During implementation this will be mapped to a lex/yacc specification which will also be made available.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng should use a terminology which is closer to programmers.

Additional note: Some terms commonly used in SMI jargon are not well known to programmers in general (TEXTUAL-CONVENTION == type definition ?). Other words are not used commonly, see issue 32.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng should avoid duplications and redundancy. Examples from SMI:

• SEQUENCEs and separate columnar object type definitions declare the syntax redundantly.
• not-accessible status of INDEX elements could be expressed implicitly.
• Enumerations should not be explicitly defined as INTEGER types.

Note on the second point: In certain cases, INDEX rows must be readable (in a table with just one column which is used as index).

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng should introduce human readable fully qualified names (module & identifier). Although in SMI `module.identifier' is valid, it is not widely used.

The dot as a namespace operator could lead to problems since it is also commonly used as glue between sub-identifiers. IDL uses `::'. How about that?

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

Must make it possible to convert automatically from SMIv2 to SMIng and back.

Information from SMIv2 modules that is no longer needed in SMIng should be put into comments. Similarly, if there will be constructs in SMIng that cannot be translated to SMIv2, they should be denoted as SMIv2 comments.

Additional note: Some SMIng constructs will introduce problems when converting to SMIv2 (e.g. new float and 64-bit types).

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng specifications should be efficient to process (e.g. load at runtime).

Note: This will be achieved by forbidding forward references and designing a concise LR(1)-grammar. Splitting of modules into definitions and conformance statements would speed up reading when the application is just interested in object-type definitions. On the other hand, in these situations the applications might skip conformance statements silently which would not slow down parsing notably and it would keep things together, see issue 10.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng should allow to shorten MIB definitions by defining appropriate defaults.

Examples:

• A default status should be `current'.
• A default max-access should be dependent on the kind of object: table object type (those of syntax SEQUENCE OF) and INDEX columns of conceptual tables are always implicitly `not-accessible'. Other object types might default to `read-only' but could be overwritten by an appropriate SMIng construct on a per sub-tree or per module level.
• Other elements like descriptions or some elements in the SMIv2 MODULE-IDENTITY macro might be optional in SMIng and default to empty strings when converted to SMIv2.

Conclusion: Implicit defaults are ok. They are clearly defined and will become well known. Allowing declarations of defaults on different levels would make it difficult to read and understand sections of a module.

Instead of defaults for a max-access construct, a shorter attribute for object type definitions could be applied, like `readonly' in IDL. But this would make the syntax of attributes inconsistent. All attributes of an object type (and other constructs) should be denoted in the appropriate construct block by keyword-value pairs.

Making too many elements, like descriptions, optional would probably lead to badly documented modules. It would not be a good idea.

From: schoenw@ibr.cs.tu-bs.de
Status: rejected

Clearly separate data type definitions from object type definitions.

Do inlined data type definitions really make sense? Would a simpler SMIng which disallows inlined data type definitions not also enforce better reuse of data types?

Conclusion: This seems to be a good idea. Note: When converting modules from SMIv2 those new type definitions should be local to the module, not exported. A static keyword might be appropriate and programmer friendly.

Note also: When inlined SMIv2 types are split, how should we handle the DESCRIPTION clause? Usually the SMIv2 object type's description contains the meaning of enumeration values, for example. The new SMIng type definition could just contain a generic description with a pointer to the object-type's description.

Note: A type that is used just once could be expressed more easily inlined.

Yet another note: How shall split types from inline defined types be named? Simply using a capital first letter works as long as there are no conflicts with SYNTAX and WRITE-SYNTAX refinements in MODULE-COMPLIANCE statements.

Final conclusion: Too many limitions. We'll still allow inlined type definitions.

From: schoenw@ibr.cs.tu-bs.de
Status: rejected

Companion of other object relationship issues: SMIng should be able to express relationships between object types (e.g. discontinuity indicators for counter objects, TDomain/TAddress pairs).

See issue 13.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng modules should not require any (imported) SMI language constructs.

SMIng shall be defined by a document and a grammar, not by modules that SMIng modules import from.

From: schoenw@ibr.cs.tu-bs.de
Status: discussed

SMIng should make sure that there are no implicit dependencies between MIB modules.

Additional note: This would enable to get an overview of all needed modules by reading a modules imports section. It would be easier to get an overview of module dependencies. On the other hand, it might be useful to refine types, for example.

No decision yet.

From: schoenw@ibr.cs.tu-bs.de
Status: accepted

SMIng should provide a complete set of base data types.

How can they be implemented on the SMI level (on the protocol level they must not introduce new type tags)? Do we need floating point types?

Conclusion: Yes. SMIng should introduce a complete set of base types, including floating point types and all base types that are commonly known by now. We should avoid the problems known from SMI, which introduced a Counter64 type with SMIv2 and still misses other 64 bit types, which are actually modeled by inappropriate techniques like TCs of syntax Counter64.

Minor question: Do we need two floating point types (like float and double) or just one? The type properties should be those of the IEEE floating point type(s) with a length of (4 bytes and) 8 bytes. Do we need Boolean? (Yes.) Do we need Char? (No.) Do we need boolean sub-types? ;-)

From: strauss@ibr.cs.tu-bs.de
Status: rejected

Would it make sense to design SMIng so that any defined object type and notification type is implicitly contained in at least one object group or notification group? This is a requirement in SMIv2. Would this conflict with issue 10?

Conclusion: No. The nesting of block structures is already needed for other purposes like tables. Furthermore, it would not have a possibility to represent multiple group memberships cleanly.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

The lexical specifications should allow an easy way to comment-out paragraphs, even if they contain sequences that denote comment boundaries. Think about nested comments and a `comment until newline' construct like `//' in C++ or `dnl' in M4.

A hyphen as used in ASN.1 and SMI seems to be no proper comment character, since it may be used in identifiers and in comments that represent ASCII graphics, underlines or separation lines.

Conclusion: We should have a `comment until newline' construct. But probably, we do not need a block comment construct. Proper comment characters could be `//' following C++ or `#' according to shell scripts or configuration files.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

The SMIv2 notification type specifies a mandatory set of varbinds to be included in notifications. Further optional varbinds may be present but there is no way to describe them in SMIv2. SMIng should be capable to denote common optional variables. (Note: This does not represent a limitation to the mentioned variables).

If SMIng will be designed to have a capability to denote conditions in other cases (when will a certain notification be sent? when will a table row allow state changes? ...), the conditions of optional varbinds in notifications should also be denoted.

Conclusion: In general, optional varbinds are no good idea. When a trap sink is about to take some action in response to a notification it has to know about all needed information. In this situation, it will have to get the needed information that is not present in the notification. Hence, optional variables in a notification could just be used for writing simple logfiles.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

When first reading some RFCs, books and other articles on SMIv1 and SMIv2, I was quite confused about the proper usage of terms like `descriptor', `label', `identifier', `name', `object identifier' and others, and under which circumstances those elements might be expressed in which form.

SMIng should clearly define those terms, denote cases where they are ambiguously used in the past and try to use the smallest subset in a strict manner.

From: strauss@ibr.cs.tu-bs.de
Status: discussed

In some cases definitions shall only be visible inside the local module and not be implicitly exported. SMIng should support a way to express non-exported definitions like static definitions in C.

From: schoenw@ibr.cs.tu-bs.de
Status: discussed

In SMIv1/v2 from time to time people expressed a need or wish to denote special properties of object types, notification types or other constructs. Other things defined in SMIv2 are not used by any standard MIB module but must not lead to errors when read by a parser. Good examples are notification severities (issue 36) and agent capabilities.

This information might be expressed by optional extensible constructs of SMIng. This would rely on the old IETF practice to be as strict as possible in what we produce as output and to be as tolerant as possible in what we take as input. This means that a parser that does not support an extension silently skips information that complies to this extension.

This would allow agent capabilities to be expressed as additional information of object type declarations or even as new constructs that are totally skipped if not supported. Notification severity might be expressed as additional elements in notification type definitions.

Note: we must pay attention on the level of lexical analysis to what we read as language keyword tokens and what we read as identifiers. If we support an extension of language keywords, this decision must depend on a lexer state, not just stateless on the read word.

Probably, we could achieve to define all new capabilities of SMIng to be implemented as extensions.

From: strauss@ibr.cs.tu-bs.de
Status: discussed

SMIng should enforce to write down statements and definitions of certain kind in a certain order

• imports
• module properties
• types (textual conventions)
• object types
• notification types
• groups
• modules compliances

Would this make sense, when some of those items are expressed by another construct (mainly as object type) with annotations (see issue 34).

From: strauss@ibr.cs.tu-bs.de
Status: discussed

It could be useful to have a possibility to express the severity of a notification. Probably this could be done by an annotation, see issue 34.

From: strauss@ibr.cs.tu-bs.de
Status: discussed

A consistent simple structure of all language constructs enables a smaller grammar and parser and is easier to learn.

First scheme for a base grammar: Statements are separated by a semicolon. Each statements starts with a keyword. Extensibility is enabled by new keywords. Statements of unknown keywords are skipped until the next semicolon. Statements may have zero or more arguments. An argument is an identifier, a constant number or text, a list enclosed in brackets, or a block enclosed by braces.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

It would be nice to have an Emacs mode for editing SMIng module files.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

The MODULE-IDENTITY's LAST-UPDATED and REVISION clauses take time-stamps (ExtUTCTime). In SMIv2 the format consists of 10 or 12 digits without any formatting characters which makes it less readable. It would be nice to represent those time-stamps in the ISO 8601:1988 standard format for date and time. see ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/ISO8601.ps.Z.

See also issue 48.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

In SMIv2 strings like DESCRIPTIONs are enclosed in quotes and may contain line breaks. In most MIB modules lines are indented by whitespace without any rules how this whitespace should be handles in strings. Most parsers use some heuristics to get what seems to be appropriate. Anyway, some cases like the SNMPv2-TC.RowStatus DESCRIPTION contain differently indented lines and are even more difficult to handle.

SMIng should support a clear notation of multi line strings without losing readability. A suggested way is to enclose each single line in quotes. As long as no semicolon follows, another string follows enclosed in quotes and is appended to the whole string separated by a newline character.

Note: Dropping the verbatim rendering of texts and leaving the rendering and insertion of newlines to the application would break compatibility and readability of many ASCII graphics and tables in existing modules. Anyway, optional annotations may declare descriptions to be encoded in other formats like HTML.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

All SMIng keywords are written lower case without hyphens or blanks. All types (even base types) are written with mixed case and the first letter being upper case. This is an exception to the first rule, but is easier for the MIB author.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

Hexadecimal strings (default values of object-type definitions) should be denoted in a way known to most programmers: by a leading `0x' followed by the hexadecimal digits.

Binary strings are hardly used in current SMIv2 MIB modules. A binary notation should be dropped in SMIng. This would enforce authors of future SMIng modules to use the appropriate base type when defining values where single bits represent single flags, which is the BITS type. When converting modules from SMIv2, binary values can be represented as hexadecimal values in SMIng.

From: strauss@ibr.cs.tu-bs.de
Status: discussed

In principle, the encoding of index columns is not a matter of SMI notation. One exception is the SMI keyword IMPLIED. To be compatible with SMI and SNMP, SMIng must be able to express what this SMI keyword expresses.

Are there other SMI constructs concerning encoding that should not be a matter of a plain information model language?

From: strauss@ibr.cs.tu-bs.de
Status: discussed

Typically, in a module object identifiers are written in the form `parent.subid', e.g. interfaces.1. Since SMIng will unify the notation of attributes (see issue 37), the object identifier will be written inside the block of all attributes of an object type. There, one possibility would be to write something like oid interfaces.1. Another way would be to separate the parent and sub-identifier elements, like parent interfaces and subid 1. This would reduce duplications (see issue 19), since many object types have the same parent which could be given just once or even implicitly in many cases.

When converting SMIv2 modules, we have to handle cases, where object identifiers are written with more than one sub-identifier (e.g. NOTIFICATION-TYPEs in MAU-MIB and SNMP-REPEATER-MIB.

State of discussion: Full OID notation is required. The relative notation can be optional or mandatory in cases where the MIB author chooses to use nested definitions. See issue 45.

From: strauss@ibr.cs.tu-bs.de
Status: discussed

According to issue 44, we could enforce or suggest to order and nest definitions in the same structure that is given by the object identifier tree of the defined objects. This would enable to drop the parent specification of object identifiers in most cases.

On the other hand, people might want to place definitions in another order for some good reason. Another problem: This would introduce more dependencies between definitions and would make it a bit more difficult to read and understand sections of a module. Nesting is usually underlined by indentation, which may lead to widely indented sections of a module.

State of discussion: It could be left as an option to the MIB author.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

Subtyping might be regarded as optional in some poorly equipped environments. To use SMIng notations in a straight fashion, it would be better to use keywords for subtyping, that are unknown in systems that don't support that kind of subtyping. Examples:

type    Integer32;
range   { 1..10 | 20 };

type    OctetString;
size	{ 1..255 };

type	Enumeration;
enum    { up(1), down(2), testing(3) };

Conclusion: The notation of subtyping as an optional suffix in the type construct is more compact. Furthermore, subtyping must not be regarded as optional.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

The SMIv2 MODULE-COMPLIANCE construct states propositions on a set of groups. The groups may be defined in multiple modules, but there seems to be no reason to separate those modules in the compliance statement. SMIng should remove this separation.

If the author wants to denote the locations of groups, the fully qualified notation can be used more significantly.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

If the descending order and presence of all revision statements is required, then the LAST-UPDATED clause is redundant. It should be removed from SMIng for more consistency.

From: strauss@ibr.cs.tu-bs.de
Status: discussed

SMIng introduces floating point base types. We should pay attention to some details. The ANSI/IEEE Standard 754-1985 defines single, double and quadruple precision floating point numbers (or even more?), including some special values: NaN (not a number), signed zero, and signed infinity. Do we need these specials? Do we need all three, just two or just a single kind of floating point types?

See RFC 1832, section 3.6 - 3.8 and http://www.shopthenet.net/publiclibrary/CIE/RFC/1832/32.htm for some more information.

Question: How could floating point sub-typing look like?

From: strauss@ibr.cs.tu-bs.de
Status: accepted

The information whether a table allows to create new rows, belongs to the table not to single columns (like read-create status in SMIv2).

There should be a possibility to denote the minimum set of columns required for row creation.

From: strauss@ibr.cs.tu-bs.de
Status: rejected

The definition of a table row and its sequence type (usually, xxxEntry and XxxEntry) contains hardly any useful information. It could be defined implicitly in SMIng.

The description will be lost. The index information will be part of the table construct. The sequence type's contents will be expressed by other column constructs. The references of other tables' AUGMENTS constructs have to refer the table instead of the row in SMIng.

Conclusion: No. It would be irritating not to have a row type. They could be necessary for language mappings which act on rows.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

In SMIv2 the MODULE-COMPLIANCE statement contains MODULE sections, in which descriptors DON'T have to be imported. This irregularity should be removed in SMIng.

From: strauss@ibr.cs.tu-bs.de
Status: accepted

There should be clear statements on what are SMIng language keywords and what are identifiers. To keep SMIng free from name collisions in converted SMIv2 modules (e.g. there could be an OBJECT-TYPE definition named `module'), the SMIng lexer should be stateful, indicating whether it expects a keyword, an identifier or other language items.

From: strauss@ibr.cs.tu-bs.de
Status: submitted

Should descriptions be required for *all* definitions, even for node's? This would make language more consistent. BTW, why are nodes like `internet' not documented in the MIB files?