Current Meeting Report
Slides
2.4.9 Next Generation Structure of Management Information (sming)
NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.
Last Modifield: 05/30/2002
Chair(s):
David Durham <David.Durham@intel.com>
Operations and Management Area Director(s):
Randy Bush <randy@psg.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
Bert Wijnen <bwijnen@lucent.com>
Mailing Lists:
General Discussion: sming@ops.ietf.org
To Subscribe: sming-request@ops.ietf.org
In Body: (un)subscribe
Archive: http://ops.ietf.org/lists/sming/
Description of Working Group:
This working group shall develop a standards-track specification for
the next generation data definition language for specifying network
management data. As a starting point, the WG will use the SMIng
language developed in the IRTF Network Management Research Group.
SMIng represents a superset of the SMIv2 (Structure of Management
Information v2) and the SPPI (Structure of Policy Provisioning
Information). The objective is to replace both the SMIv2 and the
SPPI with a single, merged language as the data definition language
for the monitoring, configuration, and provisioning of network
devices.
The language developed will enable the modeling of network
management information in a manner that provides the benefits of
object-oriented design. To achieve this, the language must allow
the design of highly reusable syntactic/semantic components
(templates) that can be reused by multiple IETF working groups for
convenience, consistency, and to maximize interoperability in device
management. A registration mechanism will also be described for
reusable components defined using the language so that their
existence and purpose may be archived.
The language will provide for the definition of a transport-independent
model so as to allow a variety of implementation-specific technologies
to be derived from a single definition. To demonstrate this, the
working group will define two technology specific transport mappings:
one for SNMP, and one for COPS.
The language will also provide:
- syntax optimized for parseability, human readability, and
non-redundancy
- conventions for representing inheritance and containment of
defined data
- enhanced attribute-level and association-level constraints
- a maximal amount of machine-parseable syntax so that
programmatic tools can aid in modeling and implementation
- a language extension capability
This working group will also define typical usage scenarios for
the language and highlight its features. Finally, it will
develop a framework by which reusable components specified
using this language can be registered and made readily
available for continued reuse and improvement.
The working group will not define models for specific
technologies, except as required for illustrative examples.
Specific models are to be developed by the subject matter
experts using the SMIng in the appropriate technology
specific WGs.
Goals and Milestones:
Done | | IRTF documents complete & submitted to IETF |
Done | | Submit Revised I-Ds including requirements I-D |
Done | | Meet at 50th IETF |
Done | | Submit revised I-D for requirements document |
Done | | WG Last Call on requirements document as Informational RFC |
Done | | Submit revised I-D for Data Definition Language and Usage
document |
Done | | Meet at 51st IETF |
SEP 01 | | WG Last Call on Data Definition Language (syntax) documents
as PS |
SEP 01 | | WG Last Call on Usage document as Informational RFC |
OCT 01 | | Revised I-D for Mapping documents for SNMP and COPS |
NOV 01 | | WG Last Call on Mapping documents for SNMP and COPS as PS |
NOV 01 | | Registrar framework defined for reusable components as an
I-D |
DEC 01 | | Meet at 52nd IETF |
FEB 02 | | Last call on Registrar Framework document as Informational
RFC |
MAR 02 | | Meet at 53rd IETF |
MAR 02 | | Working Group closes |
Internet-Drafts:
- draft-ietf-sming-snmp-02.txt
- draft-ietf-sming-modules-02.txt
- draft-ietf-sming-02.txt
- draft-ietf-sming-inet-modules-02.txt
- draft-ietf-sming-copspr-01.txt
- draft-ietf-sming-compl-00.txt
- draft-ietf-sming-ds-00.txt
- draft-ietf-sming-caps-mib-00.txt
Request For Comments:
RFC | Status | Title |
RFC3216 | I | SMIng Requirements |
Current Meeting Report
Sming interim meeting in Washington DC June 6-8 2002
Minutes reported by David Durham.
Special thanks to those who recorded the minutes: Juergen Schoenwaelder &
Steve Waldbusser.
Attendees:
Joel Halpern
Andy Bierman
Bert Wijnen
Randy Presuhn
David Harrington
Steve Waldbusser
Juergen Schoenwaelder
Chris Elliott
Glenn Waters
David Durham
Wes Hardaker
Rob Fry
June 6, 2002:
* Status and Update:
o Where are the sming documents? They had expired (this is fixed).
o Jeff withdrew smiv3 proposal, supports smi-ds.
o Andreas is not pursing asn1 proposal.
o Latest smi-ds version 00 on web page (actually third revision from Andy)
o Consensus recap from last IETF meeting:
* N-levels of nesting: Yes
* Hierarchical instance naming: Yes
* Continue using SMI syntax as much as possible: Yes (for the time being)
Juergen presented for discussion questions related to high-level goals in an
attempt to better understand consensus. Clearly we desire a more powerful
language so that 1. Human readers can understand data models more easily and 2.
Human writers can express their models in a better way. But do we want to
support more than the current SNMP technology? The consensus was that more is
fine, but the primary target is SNMP technology, for both monitoring and
configuration. So retaining compatibility with current SNMP technology is
desired. Attendees wanted the ability to convert from SMIv2 to SMIng (a
requirement), and converting SMIng to SMIv2 only where possible (not a
requirement). The other question concerned the SPPI. As this topic has been
addressed in the past, the chair repeated that this working group will not be
constrained or concerned with backward compatibility with SPPI. COPS-PR
supporters are responsible for writing a translation if they desire it.
Juergen went on to explain why Frank and himself had reservations to the SMI-DS
approach. People want to improve the SNMP technology for both monitoring too.
SNMP technology is even worse for configuration management. Frank/Juergen
believe that we should not change the things that are working well enough.
Specifically, they believe changing instance naming will break many
applications. The other attendees did not agree. No one who had applications
thought that they would be adversely affected by the SMI-DS naming scheme. MIB
walks will still work, and the advice was not to use old tools to view new
structures anyway. Ideally there shouldn't be any changes that result the wire
protocol, but adding new base types is clearly an exception. Juergen ended by
suggesting that it was the lack of high-level operations that was the main
problem, and using an RPC mechanism would be a good thing. Andy agrees that
having clear elements of procedure/use cases for those things people typically
do would be beneficial. Overall, people wanted to improve readability and
clarify the syntax of the language. Two clear non-requirements was the idea of
making it easier on the tool writers (who are a minority) as well as providing
annotations to the language. It was felt the latter would be best handled by
separate documents, not inline with the standards (overall, making it hard to
add new a syntax clause was considered a feature and not a bug).
Finally, Juergen strongly believes that the language should be familiar to the
majority of people out there. There is no language out there that has the
concept of a leaf. Randy agrees that what we do in the smi is different than
what most cs students are familiar with since we use different terminology. Andy
doesn't believe that SYNTAX or MAX-ACCESS is the problem, it is the lack of data
modeling and data structure. Clearly, however, OBJECT in the smi is not what
people think it is.
* Terminology:
o Continue to use SMI terminology? Don't change what isn't broken, if it is, at
least take pains to explain why when changing terminology.
o Define delta's from existing SMI terminology for use this week:
* SMIv3 will be the output of this working group.
* Base Types = {Integer, OctetString...}
* Derived Types = Refined Types: TCs. Smi-ds does not have a mechanism to extend
existing structs in the OO sense. Sming has a mechanism to derive complex types
from other complex types.
* Scalar Types = Leaf nodes. Anything that is not an aggregate. Can even be a
pointer.
* Attribute=property=subelement(in XML)=node(smi-ds): The namable elements.
Lot's of discussion, consensus toward the word attribute (aggregates can also be
attributes).
* Structure: Defines a set of attributes.
* Class: Essentially a structure with methods. Neither smi-ds or sming have
classes containing methods.
* Object: ? Will not use this term moving forward, too much baggage.
* N-levels of nesting (tables in tables, arrays in arrays...)=Aggregate types:
Complex data types can be comprised of other complex data types, including
arrays.
* Hierarchical Instance Naming: using oids to name hierarchical instance data.
* Unions: Choice.
* Index: Instance identifier.
* Row pointer:
* Instance pointer
* Typed Pointers=Constrained Pointers:
* Intermediate Type Definitions
* Name Spaces: Constrained/Scoped universe of identifier names.
* Constraints: Clause that constrains the values an attribute may take.
* Reusable (abstract) Definitions = type definitions
* Leaf Nodes : node which does not contain other nodes. Attribute which does not
contain any other aggregate type. Consensus was to change term to something more
understandable.
* Aggregated Data Object: This term refers to any data object which provides
some sort of containment for other data objects, which is any variable construct
other than LEAF (e.g., ARRAY, UNION, or STRUCT).
* Data Object: This term refers to any SMI Data Structure variable declaration,
at any level of containment.
* MIB Object: This term generically refers to a SMIv2 OBJECT-TYPE macro
definition. It may also refer to an SMI Data Structure definition.
* OID: This is a shorthand term for 'OBJECT IDENTIFIER'.
* LEAF: This term refers to any accessible data object with a syntax that
resolves to a SMI base type.
* Method is basically Elements of Procedure as can be determined from a Use
case.
Next was a discussion about the merits of having a hierarchical oid namespace.
Hierarchical oids provide aggregates and aggregate information even at a
protocol level. They also enable the individual items of the aggregate to be
addressable. The difference between SMI-DS and SMIng documents is at what stage
during the definition process are the oids associated with the datastructure.
Consensus is that we want to explicitly assign oids within the data structures
and not have map them or define arbitrarily later. Smi-ds provides for reuse of
the suboid number as well as reuse of the data structures themselves, removing
at least one level of indirection. Consensus was to preserve the hierarchical
aggregations on the wire was a valuable thing to do (and not to strictly depend
on the syntax definition).
What followed was a discussion about indexing. SMI-DS keeps the index portion of
the sub-oid on the right. The reason for this is that oid pointers (eg. Row
pointers) expect indices on the right. If they are not, then old mib definitions
will not be able to effectively reference new smiv3 mib definitions. Keeping the
index on the right does have the side affect of making the getnext behavior look
even stranger. It was noted that the protocol will not allow aggregates to be
hidden, so you can only skip over hidden data. Given these issues, there was a
suggestion for having two oid spaces, one with indexing on the right, another
with indexing inline, adjacent to the current level of aggregation.
Randy brought up the issue of unions and getnext. There is a problem with
getting next lexical ordered element with a union because get next may skip over
the union because the index is on the right. It wasn't clear how bad this
problem would actually be, it simply would require the manager to try and get
the possible union values directly. A possible solution would be to put the
union discriminator on the end of the oid, but this will then mess up the
lexical ordering.
June 7, 2002
Indexing was further discussed with Andy's (corrected) slides showing conceptual
mib walk with smi-ds mibs. The main issue was how to determine where the prefix
oid stopped and when the index portion began w/o requiring the smi-ds mib (some
intermediate layers of the snmp stack may need to know this information, but
won't have access to the definitions). It was suggested to use a .0 between the
prefix and index portions to understand where the break point is. Since .0 is
not allowed in mibs today, it could be used for this purpose. Another suggestion
was to simply use meta data that specified where the prefix and index were for
any given oid. Conclusion was there needs to be sufficient meta data available
to figure out where each of the indicies are. But we should keep the naming the
same as it is today. It was also suggested to use the meta data to encode the
oid textual name, and other mib information so that mibs can be more
self-describing (like XML documents). Other more radical suggestions were to
move away from oids altogther, being that they seem to be the root of all evil.
Needless to say, such a radical step would break backward compatibility. In
which case, it would probably be better just to adopt XML or something else, and
not invent yet another mechanism for network management.
Next Steve presented the TRANSACTION clause concept to let implementations know
what attributes are expected to be part of a transaction. CREATE-TRANSACTION
{ipAddressData, ipAddressFlow, ...}. Needs to create transaction for an entire
row, in the specified order. CREATE-OPTIONAL ... provides a list of optional
transactional parameters. Most had an issue with forcing ordering. They believed
that create and go is sufficient to perform this functionality w/o ordering
constraint. The consensus was that it wasn't the ordering that matters, its
dribbling out the objects over multiple atomic sets that is the problem
currently. Some also had an issue with forcing some implementations to deal a
"must not use" object in the transaction. The transaction clause appears to be
useful vs. defval because there may be the need to combine variables across
tables as part of the same transaction.
Andy would like per high level object, elements of procedure. He just wants it
clearly specified, it doesn't have to be in machine readable clause, could be in
a description clause. Elements of procedure simply need to deal with the 90%
cases, clearly describing the steps required to achieve a desired result.
Next was a discussion on conformance. Much of the discussion related to
enforcing conformance. DavidH suggested that we write a conformance test script
at the end of every MIB (coincidently, scripts can be related to, or used to
define, a use case as well).
When applied to different levels of nesting there is an issue with status. What
if deprecated objects exist in a type def? If its use as a variable is
deprecated. What if it is deprecated as a type definition but its use is still
current by some variable? ... The consensus was that this should simply cause a
compiler to issue a warning.
With respect to ACCESS, group consensus was that the equivalent of a MAX-ACCESS
goes in a type definition that can be further constrained in the variable
definition. Where as the C semantic only goes from the first level down, we want
it to apply through all levels of nesting.
There was some discussion on the scope of reuse/amount of reuse. The old smiv2
pointers don't allow you to point at a particular instance of an aggregate. How
to distinguish between high-level object pointer vs. low-level instance pointer.
Oid based id's currently point at first accessible column. In an aggregate
composition, it is difficult to define what the first "column is", so we should
define smiv3 pointers in a new TC. Terminating the object tree with a "0" will
help describe where the base oid ends and the index portion starts. Bert
mentioned he has seen zero's in the prefix before, but this is not allowed, so
we shouldn't be overly concerned. This would help to define aggregate pointers.
There is value keeping the oid structure because we can remain backward
compatible with the SMI, and old mibs can point to leafs of new data structures.
Though when getting to aggregate data types, vacm becomes a problem.
Long discussion that the constraints imposed by the current protocol and charter
dilute the possible solutions. David Harrington presented removing UDP
limitation, port 161 restriction, 484 byte limitation, ASN.1, Security
restrictions, Get/Set/oids, no meta objects, no rpcs, no create/edit/delete.
There is the belief that OIDs are a big problem.
For now we can move forward with data aggregation and aggregated instance
naming. Preserve SMI compatible naming and we would like to get an SMI out the
door that will still work with SNMPv3 & v1. Finally, we can add features into
the language that would be useful for future protocol extensions. We just need
to write guidelines that specify when these features will actually be used. Some
things people would like:
* Getting away from global descriptors that have to be less than 64 bytes long.
* Indices can be longer than they are today
* Allow multiple sets of indices
* Introduce methods and/or elements of procedure
* Support for transactions
* A uniqueness clause that is different from indices
* Remove those annoying little rules: what you are allowed to create, what you
are allowed to change (revisit these). Eg. New conformance mib, once you
identify the version at run time, no need to deprecate a mib. Not allowed to
extend the range of an integer but you can extend enumerations.
June 8, 2002
There was a discussion about allowing anonymous types for adding columns. People
were comfortable with removing anonymous types IF one can add columns to the
named types. Then you have a short binding after the type declarations. Randy
cautioned that it can lead to readability problems, but the group consensus was
that using a type means you will have to know what the type is.
Next, Juergen lead a detailed discussion about how to merge the documents and
key issues still to be addressed:
General Issues:
===============
- Should we change name of the converged version to SMIv3? The Group consensus
was yes.
- The agreed set of documents & authors:
1. SMIv3 Language Definition: Andy, Juergen, Frank
2. SMIv3 MIB Modules(core types): Juergen by July 1st.
3. SMIv3 Guidelines : Andy
4. Transition from SMIv2 : Andy, Chris
5. Capabilities MIB : Andy, by June 24th.
6. INET Modules (textual conventions) ?
IETF deadline: July 1st for revised documents, June 24th for new documents.
The list of specific items below were addressed during the meeting and the group
consensus is reflected therein. Any specific objections to the group consensus
items listed below must be sent to the sming mailing list. Keep objections
specific.
draft-ietf-sming-0x.txt:
========================
- Changed the data format from ASN.1 ExtUTCTime to the format `YYYY-MM-DD HH:MM'
or `YYYY-MM-DD'. The group consensus was this is fine, but should clarify that
this is UTC time. Reason for changing: The current smiv2 format is unreadable to
most people.
- The set of SMIng base types is not identical to the set of tagged types used
in the SNMP protocol. SMIng base types:
Integer32, Unsigned32, Integer64, Unsigned64, OctetString, ObjectIdentifier,
Bits, Enumeration, Float*
Consensus was this is OK and base types should not be imported. While derived
types must be imported. The reason for the change: Make the type system
consistent with up-to-date languages, also there should be no spaces in keywords
because they make parsing a pain, and finally this gives us a consistent syntax
for types.
- [1] OctetString vs OCTET STRING and [2] (SIZE (1..20)) vs (1..20) and [3]
'0a0f'h vs 0x0a0f. Group consensus was:
1. Use OctetString? OK
2. Use SIZE and RANGE? NO
2a. Use no SIZE and no RANGE? NO
2b. Use what we have now? OK (not consistent, but not worth fixing)
3. Stay with '0a0f'h : OK (because it is meaningful to BER encodings to have
module 8, where as with c the encoding is fixed/same size.
- Pointer as a base type rather than OBJECT IDENTIFIER. Syntax of Pointer
restrictions. The room consensus was that Pointer should be a derived type so
one has the flexibility to change it later.
Distinction between Pointer and Identifier? (Examples are RowPointer and
TDomain.) Group consensus was YES.
Call Pointer Reference? No agreement. Pointer aligns with RowPointer,
InstancePointer and does not clash with REFERENCE. Consensus was to go with the
word "Pointer"
- [1] ObjectIdentifier vs OBJECT IDENTIFIER and [2] dotted notation for OID
values (including/excluding hexadecimal values) and module namespace separator.
The group consensus was:
1. Use ObjectIdentifier keeping with reasoning discussed for types above.
2. Should we add even more stringified versions of these oid numbers?
Rationale: Cut & paste between MIBs and SNMP implementations.
Keep in addition the { ifIndex 1 }?
Some confusion between { iso foo(2) 3 } and { iso 2 3 } and { iso foo 3 } ...
No conclusions on point 2.
- Hexadecimal Integer32/Integer64/Unsigned32/Unsigned64 constants ('0a0f'h vs
0x0a0f). The group was to keep using the quoted ''[hH] format.
- Float32/Float64/Float128.
People wanted to know why so many versions, why not just Float64?
Objectives document says some kind of floating type support is required.
- Enumeration vs INTEGER and syntax of enumerated values. What about things that
have been coming up such as status for enumerated values or descriptions for
enumerated values? Group consensus that using Enumeration is OK but do not add
more stuff for named numbers.
- Bits vs BITS and format of Bits named numbers. The group consensus was to use
the smiv2 { ... } format. This is not broken.
- Display formats are similar to SMIv2. There were however some comments some
months ago to change them. The group consensus was to keep them as they are -
though the usefulness of display hints is questionable - so keep it as is unless
someone comes up with good proposals on the mailing list.
- Comments. Allow // or keep the current -- with the arcane ASN.1 rules? Group
consensus was mixed, rough consensus was to change to // because the reasoning
was that more people are familiar with it (DavidH says -- comments often confuse
readers). Others suggested using # for comments though this would confuse
preprocessors. Given the varied differences of opinion, it is probably best to
leave comments unchanged from the smiv2 style, possibly with the exception of
just making them continue to the end of the line.
- CAPITALIZE all KEYWORDS for improved SMIv2 look & feel? The group consensus
was yes, keeps things similar to smiv2 look & feel.
- Use a consistent syntactic structure "<keyword> <identifier> ..."? Juergen
thinks SMI-DS also has changed into this direction. The group consensus was yes.
- Where to anchor module meta information? Removed the LAST-UPDATED clause - use
data of last REVISION instead. The group consensus was yes, remove the clause.
- Multiple import statements?
IMPORT IANAifType
FROM IANAifType-MIB
IMPORT mib-2
FROM SMIv3
IMPORT AutonomousType, Counter32, Counter64, DisplayString255, Gauge32,
PhysAddress, RowStatus, TestAndIncr, TimeStamp, TimeTicks,
TruthValue
FROM SMIv3-TYPES
IMPORT snmpTraps
FROM SNMPv2-MIB
With or without semicolons? The group consensus was to get rid of the semicolon.
The group was also comfortable with having an IMPORT for every module. This
makes cut-copy-paste operations easier.
- Remove the extension statement? The group consensus was YES.
- Change typedef to TYPE? SMIng allows DEFAULT clauses in TYPE definitions
(which can be overwritten in ATTRIBUTE definitions). Do people feel comfortable
with that? The group consensus was YES.
- Change 'type' back to SYNTAX for improved SMIv2 compatibility? Group consensus
was YES.
- OBJECT-IDENTITY vs IDENTITY and late OID assignment.
Change: foo OBJECT-IDENTITY ... => IDENTITY foo ...
The group consensus was this change is OK, it is less verbose.
- CLASS vs. STRUCT? The group consensus was to use STRUCT.
- Should notifications be bound to aggregate types? There was much discussion,
and other worlds have generic notifications such as a status change which can be
applied to various objects (interfaces, physical entities, ...). People wanted
to see the syntax to understand the usefulness of reuse here:
STRUCT Status {
ATTRIBUTE adminStatus
ATTRIBUTE operStatus
EVENT statusChange
}
STRUCT Interface {
ATTRIBUTE status { SYNTAX Status }
...
}
NOTIFICATION Status.statusChange {} = base.32
Reuse might be useful, but details need to be worked out.
- Discriminated Unions need to be added. The group consensus was strongly YES,
as seen in the smi-ds proposal.
- Arrays need to be added. The group consensus was YES, again as in the smi-ds
proposal.
- Remove inheritance? The group consensus was YES. Reason, adding
aggregate/structured data is sufficient. Inheritance adds unwelcome complexity.
- Implicit export of everything vs. "static" definitions? No agreement, this
needs to go to the list because it is unclear what the benefit is outside of
code modules.
draft-ietf-sming-modules-0x.txt: ================================
- Modules need to be adapted to reflect the syntactic changes. The group
consensus was yes.
- 'nil' vs. 'zeroDotZero'. The group consensus was to go with what we have.
- Merge contents of IETF-SMING-SNMP from draft-ietf-sming-snmp-0x.txt back into
SMIV3-TYPES. The group consensus was yes.
draft-ietf-sming-snmp-0x.txt:
=============================
- TABLE vs. VAR ARRAY and SCALAR vs. VAR STRUCT?
VAR would be enough in both cases since the presence of an INDEX in an aggregate
allows to distinguish both cases.
1. TABLE vs. ARRAY - The group consensus was to use the word ARRAY because table
already has a different meaning in DB land.
2. INDEX clauses might not always be bound to the aggregate type to allow index
swapping. - the group consensus was yes.
3. VAR ARRAY vs. VAR UNION vs. VAR ... even though the second keyword is not
really needed? The group consensus was that it may help the reader to see the
second keyword.
Side step: What is a VAR UNION?
UNION Foo {
ATTRIBUTE a { ... INDEX {} ... }
ATTRIBUTE b
}
VAR UNION c { SYNTAX Foo INDEX {b} }
This probably needs more thought.
The group consensus was to syntactically go with the VAR <aggtype> notation for
now. Also INDEX clauses (and similar beasts) are only allowed in ARRAYs.
- Allow anonymous aggregated types? The group consensus was No.
- Move revised version of introduction text from this document back into the
main SMIng document. The group consensus was YES.
- Other text needs also to be merged. Everything needs to be merged.
YES
- Define the rules for legal OID values? There has been ongoing confusion what
the restrictions on the first two subidentifier are. The group consensus was
YES, people wanted to cut & place into applications, define what is a legal
subid. Should also clarify we are not using ASN.1 notation here.
- Move mapping to today's SNMPv3 back to the main SMIng document. The group
consensus was YES.
- The notification statement probably needs some work (see above).
Yes, see above.
- SMIng does not distinguish anymore between OBJECT-GROUPs and
NOTIFICATION-GROUPs. They are just GROUPs. Is this useful? The group consensus
was that the distinction is not useful.
- SMIng removes the common
MODULE -- this module
construction as the same effect can be achieved in other ways.
Seems to be an odd construction, the group consensus was to either require the
module name or get rid of it, making it optional helps nothing.
- Would be nice to be able to define GROUPs for foreign definitions imported
from other modules.
- Would be nice to have simpler compliance statements. The group consensus was
yes, this would be nice, but someone has to provide proposals.
- The keywords EXTENDS and EXPANDS sound too similar and are thus a bit
confusing.
Use SPARSE-AUGMENTS since CISCO uses it in comments.
SMI-DS does not provide EXTENDS anymore. Need to think about it.
draft-ietf-sming-inet-modules-0x.txt:
=====================================
- Definitions need to be adapted to new syntax. Yes.
- Definitions must be aligned with recent changes in other MIBs. Perhaps the
INET-ADDRESS stuff should not be done here but rather in a revision of the
INET-ADDRESS-MIB since this is now actually being used? Yes.
Slides
SMI-DS Issues