< draft-schoenw-sming-lessons-00.txt   draft-schoenw-sming-lessons-01.txt >
Network Working Group J. Schoenwaelder Network Working Group J. Schoenwaelder
Internet-Draft Jacobs University Bremen Internet-Draft Jacobs University Bremen
Intended status: Informational June 15, 2007 Intended status: Informational September 25, 2007
Expires: December 17, 2007 Expires: March 28, 2008
Protocol Independent Network Management Data Modeling Languages -
Lessons Learned from the SMIng Project Lessons Learned from the SMIng Project
draft-schoenw-sming-lessons-00.txt draft-schoenw-sming-lessons-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 17, 2007. This Internet-Draft will expire on March 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
A data modeling language for network management protocols called A data modeling language for network management protocols called
SMIng was developed within the Network Management Research Group of SMIng was developed within the Network Management Research Group of
the Internet Research Task Force over a period of several years. the Internet Research Task Force over a period of several years.
This memo documents some of the lessons learned during the project This memo documents some of the lessons learned during the project
for consideration by designers of future data modeling languages for for consideration by designers of future data modeling languages for
network management protocols. network management protocols.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SMIng Goals and History . . . . . . . . . . . . . . . . . . . 3 2. SMIng Goals and History . . . . . . . . . . . . . . . . . . . 4
3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 4 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Readers, Writers, Tool Developers . . . . . . . . . . . . 4 3.1. Readers, Writers, Tool Developers . . . . . . . . . . . . 5
3.2. Data vs. Command vs. Object vs. Document . . . . . . . . . 5 3.2. Data vs. Command vs. Object vs. Document . . . . . . . . . 5
3.3. Naming Independence . . . . . . . . . . . . . . . . . . . 5 3.3. Naming Independence . . . . . . . . . . . . . . . . . . . 7
3.4. Errors and Exceptions . . . . . . . . . . . . . . . . . . 6 3.4. Errors and Exceptions . . . . . . . . . . . . . . . . . . 7
3.5. Configuration Storage Models . . . . . . . . . . . . . . . 6 3.5. Configuration Storage Models . . . . . . . . . . . . . . . 8
3.6. Selection of Language Features . . . . . . . . . . . . . . 7 3.6. Selection of Language Features . . . . . . . . . . . . . . 8
3.7. Syntax versus Semantics . . . . . . . . . . . . . . . . . 7 3.7. Syntax versus Semantics . . . . . . . . . . . . . . . . . 8
3.8. Reuse of Definitions . . . . . . . . . . . . . . . . . . . 7 3.8. Reuse of Definitions . . . . . . . . . . . . . . . . . . . 9
3.9. Versioning and Meta Information . . . . . . . . . . . . . 8 3.9. Versioning and Meta Information . . . . . . . . . . . . . 9
3.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 3.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
3.11. Language Independence . . . . . . . . . . . . . . . . . . 8 3.11. Language Independence . . . . . . . . . . . . . . . . . . 10
3.12. Compliance and Conformance . . . . . . . . . . . . . . . . 9 3.12. Compliance and Conformance . . . . . . . . . . . . . . . . 10
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. Informative References . . . . . . . . . . . . . . . . . . . . 10 8. Informative References . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14
1. Introduction 1. Introduction
Network management is often performed using a collection of different
management protocols. Many operators use several different
management protocols to access a single managed device for different
purposes, such as device configuration, event and notification
delivery, and collection of statistics. While some operators manage
to settle on a single protocol for a given management task and/or
domain, it is not uncommon that different operators select different
competing management protocols for the same management task and/or
domain.
As a result, device vendors are forced to support multiple management
interfaces to satisfy their customers. This increases software
complexity and costs. It is therefore understandable that device
vendors are interested to reduce the complexity and efforts
associated with supporting multiple management interfaces. One
obvious step in this direction could be to have a common data model
which is underlying all management protocol interfaces instead of the
current situation where every management protocol interface has its
own slightly different data model. As a consequence, it is
attractive to design data modeling languages that are protocol
independent and allow for a "late binding" to concrete management
protocols.
The Network Management Research Group (NMRG) of the Internet Research The Network Management Research Group (NMRG) of the Internet Research
Task Force (IRTF) has developed a new data modeling language for Task Force (IRTF) has developed a new protocol independent data
network management protocols called SMIng [RFC3780]. Work on SMIng modeling language for network management protocols called SMIng
started in the late 1999 and concluded with the publication of the [RFC3780]. Work on SMIng started in 1999 and concluded with the
core language [RFC3780] and an extension which provides the mappings publication of the core language [RFC3780] and an extension providing
to the Simple Network Management Protocol (SNMP) [RFC3781] in 2004. mappings to the Simple Network Management Protocol (SNMP) [RFC3781]
in 2004.
This memo documents some of the lessons learned during the project This memo documents some of the lessons learned during the project
for consideration by engineers of future data modeling languages for for consideration by engineers of future data modeling languages for
network management protocols. Our focus is on technical design network management protocols. Our focus is on technical design
aspects that have turned out to be more difficult than expected as aspects that have turned out to be more difficult than expected as
well as aspects that required significant discussions in order to well as aspects that required significant discussions in order to
understand trade-offs. understand trade-offs.
The rest of this document is structured as follows. Section 2
provides a short review of the goals and the history of the SMIng
project. Section 3 discusses twelve lessons learned. The document
concludes in Section 4.
2. SMIng Goals and History 2. SMIng Goals and History
SMIng started in 1999 as a research project to address some drawbacks The SMIng project started in 1999 as a research project to address
of SMIv2, the current data modeling language for management some drawbacks of SMIv2 [RFC2578] [RFC2579] [RFC2580], the current
information bases. Primarily, its partial dependence on ASN.1 and a standard data modeling language for management information base
number of exception rules turned out to be problematic. In 2000, the modules in the IETF [DSOM99]. Primarily, SMIv2's partial dependence
work was handed over to the IRTF Network Management Research Group on ASN.1 and a number of exception rules were considered to be
where it was significantly detailed. Since the work of the RAP problematic. In 2000, the work was handed over to the IRTF Network
Working Group on COPS-PR and SPPI emerged in 1999/2000, SMIng was Management Research Group where SMIng was significantly detailed. In
split into two parts: a core data definition language (defined in 1999/2000, the work of the Resource Allocation Protocol (RAP) working
this document) and protocol mappings to allow the application of core group on the Common Open Policy Service (COPS) usage for Policy
definitions through (potentially) multiple management protocols. The Provisioning (COPS-PR) [RFC3084] lead to the creation of the
replacement of SMIv2 and SPPI by a single merged data definition Structure of Policy Provisioning Information (SPPI) [RFC3159]. As a
language was also a primary goal of the IETF SMING Working Group that consequence, SMIng was split into two parts: a core protocol
was chartered at the end of 2000. The SMING Working Group could not independent data definition language and protocol specific mappings
reach agreement, resulting in the Working Group being closed down in to allow the access of core definitions through (potentially)
April 2003. The NMRG then published the SMIng specifications in multiple management protocols. The replacement of SMIv2 and SPPI by
[RFC3780] and [RFC3781] in order to document the results achieved in a single merged data definition language was also a primary goal of
the NMRG. the IETF SMING working group chartered at the end of 2000. The SMING
working group, after carefully documenting the objectives [RFC3216],
could not reach agreement on a common solution, resulting in the
working group being closed down in April 2003. The NMRG then
published the SMIng specifications in 2004 in [RFC3780] and [RFC3781]
in order to document the results achieved in the NMRG.
In short, the published version of SMIng aimed at being a data The published version of SMIng aimed at being a data modeling
modeling language that can be adapted for different management language that can be adapted for different management protocols and
protocols and thus be closer to an information modeling language. thus be closer to an information modeling language. See RFC 3444
For a more detailed discussion of the terms data modeling language [RFC3444] for a more detailed discussion of the terms data modeling
and information modeling languages, we refer the reader to RFC 3444 language and information modeling language.
[RFC3444].
The problem which drove the development of SMIng, namely duplicated The problem which drove the development of SMIng, namely duplicated
data modeling efforts and often also duplicated instrumentation code, data modeling efforts and often also duplicated instrumentation code,
has not been solved and it even may have become more pressing. A is still widely unsolved and it even may have become more pressing.
data modeling language capable to drive tools that can automate the A standard data modeling language capable to drive tools that can
implementation of command line interfaces, monitoring interfaces, and automate the implementation of command line interfaces, monitoring
configuration interfaces from a single specification surely would interfaces, and configuration interfaces from a single specification
have significant value. surely would have significant value for the networking industry and
standardization bodies.
During the SMIng project, people have looked at various issues that During the SMIng project, people have looked at various issues that
have to be dealt with in this context. The purpose of this memo is have to be dealt with in this context. The purpose of this memo is
to document these issues and some of the alternatives that have been to document these issues and some of the alternatives that have been
explored to tackle them so that future language designers can learn explored to tackle them so that future language designers can learn
from the SMIng experiment. from the SMIng experiment.
3. Lessons Learned 3. Lessons Learned
This section summarizes the lessons learned from the SMIng project. This section summarizes the lessons learned from the SMIng project.
Designers of future data modeling languages for network management Designers of future data modeling languages for network management
protocols are encouraged to study these lessons to avoid potential protocols are encouraged to study these lessons to avoid potential
pitfalls. pitfalls.
3.1. Readers, Writers, Tool Developers 3.1. Readers, Writers, Tool Developers
Network management data modeling languages are used by engineers to Network management data modeling languages are used by engineers to
develop and specify data models for (sub-components of) managed develop and specify data models for (sub-components of) managed
systems. The data models are later read by implementers with the systems. The data models are later read by implementers with the
goal to create interoperable implementations as well as network goal to create interoperable implementations. Network operators
operators while managing networks and services. A data modeling often read data models while managing networks and services. A data
language is therefore used by both, data model writers and data model modeling language is therefore used by both data model writers and
readers. In most cases, the number of readers of a data model is data model readers. In most cases, the number of data model readers
much larger than the number of writers. Hence, when taking design is much larger than the number of data model writers. Hence, when
decisions, it may be necessary to consider to what extend the design taking design decisions, it may be necessary to consider to what
choice simplifies the task of data model readers and the task of data extent the design choice simplifies the task of data model readers
model writers. All other things being equal, preference should be and the task of data model writers. All other things being equal,
given to solutions that simplify the task of the human reader. preference should be given to solutions that simplify the task of
data model readers.
The third group to be considered in the data modeling language design The third group to be considered in the data modeling language design
process are tool developers. In general, language features should be process are tool developers creating parser libraries or compilers.
simple and straight forward to implement in order to achieve wide In general, language features should be simple and straight forward
spread tool support. However, when considering alternatives, it is to implement in order to achieve wide spread tool support. However,
important to realize that in most cases the number of data model when considering alternatives, it is important to realize that in
writers is much larger than the number of tool developers. most cases the number of data model writers is much larger than the
number of developers of tools (e.g., parsers, compilers) supporting a
data modeling language.
As a consequence, preference should be give to solutions that As a consequence, preference should be give to solutions that
simplify the task of readers. Reduction of the efforts required by simplify the task of readers. Reduction of the efforts required by
writers is of secondary importance and the reduction of the efforts writers is of secondary importance and the reduction of the efforts
required by tool developers is of least important preference. While required by tool developers is of least important preference. While
this perhaps seems obvious, it is at times difficult to take this perhaps seems obvious, it is at times difficult to take
according design decisions if the group working on a new data according design decisions, especially if the group working on a new
modeling language is dominated by say tool developers or data model data modeling language is dominated by tool developers or data model
writers. writers.
3.2. Data vs. Command vs. Object vs. Document 3.2. Data vs. Command vs. Object vs. Document
There are different approaches to model network management interfaces There are different approaches to model network management interfaces
and to design supporting protocols: and to design supporting protocols:
o The data-oriented approach models all management aspects through o The data-oriented approach models all management aspects through
data objects that can be read, written, created, and destroyed. data objects that can be read, written, created, and destroyed.
The SNMP technology is an extreme example of this approach where The SNMP technology is an extreme example of this approach where
even create and destroy operations are handled as side effects of even create and destroy operations are handled as side effects of
write operations. While the data-oriented approach is write operations. While the data-oriented approach is
conceptually simple, it is usually difficult to use for modeling conceptually simple, it is usually difficult to use for modeling
complex operations, for example due to atomicity issues. complex operations, for example due to atomicity issues.
o The command-oriented approach does not model state objects but o The command-oriented approach does not model data objects but
instead treats the state maintained by a managed element as a instead treats the state maintained by a managed element as a
black box and provides specific commands to cause state changes or black box and provides specific commands to cause state changes or
to retrieve/write some selected state information. The command- to retrieve/modify some selected internal state information. The
oriented approach is widely used by command line interfaces. command-oriented approach is widely used by command line
interfaces.
o The object-oriented approach can be seen as a combination of the o The object-oriented approach can be seen as a combination of the
data-oriented and the command-oriented approach where commands are data-oriented and the command-oriented approach where commands are
bound to data objects and the black-box state is limited to the bound to data objects and the black-box state is limited to the
internal state of objects. The object-oriented approach is being internal state of objects. The object-oriented approach is being
used for example by the Common Information Model. used for example by the Common Information Model.
o The document-oriented approach represents the state of a device o The document-oriented approach represents the state of a device
and its configuration as a structured document. As a consequence, and its configuration as a structured document. As a consequence,
primitive operations are the retrieval of (parts of) a document primitive operations are the retrieval of (parts of) a document
and the application of changes to move from one document version and the application of changes to move from one document version
to the next. Since a configuration is treated as a complete to the next. Since a configuration is treated as a complete
document, it becomes more natural to support course grained atomic document, it becomes more natural to support coarse grained atomic
operations. The document-oriented approach is used by NETCONF for operations. The document-oriented approach is used by the Network
dealing with configurations. Configuration (NETCONF) protocol [RFC4741] recently published by
the IETF.
Note that the choice of the approach has impact on the features Note that the choice of the data modeling approach has impact on the
required by a data modeling language. Trying to be protocol neutral features required by a data modeling language. Trying to be protocol
may imply to support multiple of these approaches, which clearly neutral may imply to support multiple of these approaches, which
increases the complexity of the language design. A data modeling clearly increases the complexity of the language design. A data
language aiming at supporting a document-oriented view for modeling language aiming at supporting a document-oriented view for
configuration, a data-oriented view for monitoring, and a command- configuration, a data-oriented view for monitoring, and a command-
oriented view for ad-hoc operations on a device must be able to link oriented view for ad-hoc operations on a device must be able to link
say a command to the data objects that may be triggered to achieve say a command to the data objects that may be manipulated to achieve
the behaviour defined for that command. This quickly becomes the behaviour defined for that command. This quickly becomes
difficult and it might be better to avoid mixing different approaches difficult and it might be better to avoid mixing different data
for the same functionality. modeling approaches.
Unfortunately, in many real-world implementations, new management
protocols will be used together with existing interfaces or
databases, which already follow one of the approaches. This will
force the designers of new data modeling languages to accommodate
features of multiple approaches, even if this makes the result more
complicated.
3.3. Naming Independence 3.3. Naming Independence
One of the goals of the SMIng project was to provide a data One of the goals of the SMIng project was to provide a data
definition language where the data definitions are not tied to a definition language where the data definitions are not tied to a
specific management protocol. Since protocols typically use specific management protocol. Since protocols typically use
different approaches to name instances, it is required to support different approaches to name instances of managed objects, it is
multiple instance naming systems. While this may sound easy to do, required to support multiple instance naming systems. While this may
it turns out that trying to achieve naming independence has many sound easy to do, it turns out that trying to achieve naming
implications: independence has many implications:
o There is in general a need to model relationships. A common o There is in general a need to model relationships. A common
approach is to refer to other definitions using names as pointers. approach is to refer to other definitions using names as pointers.
Being naming system independent, such a pointer needs to be Being naming system independent, such a pointer needs to be
abstracted and the protocol mappings then need to explain how the abstracted and the protocol mappings then need to explain how the
pointer works for a given protocol. This becomes quickly pointer works for a given protocol. This quickly becomes
difficult since management protocols tend to introduce different difficult since management protocols tend to impose protocol
specific constraints. specific constraints, resulting from the different naming systems.
o Many relationships between data model components are typically o Many relationships between data model components are typically
explained in description clauses. Being protocol neutral, explained in description clauses. Being protocol neutral,
description clauses have to be worded carefully so that they make description clauses have to be worded carefully so that they make
sense with the various protocol mappings. This significantly sense with the various protocol mappings. This significantly
increases the efforts to write data models and to review them. increases the efforts to write data models and to review them.
o When thinking about relationships, it is crucial to think about o When thinking about relationships, it is crucial to think about
fate sharing of data objects, namely does the removal of an object fate sharing of data objects, namely does the removal of an object
imply the removal of other objects? Being naming system imply the removal of other objects? Being naming system
independent causes some additional challenges here since some fate independent causes some additional challenges here since some fate
sharing properties may be implicit in the naming system used in sharing properties may be implicit in the naming system used in
once protocol mapping while they must be explicit in other one protocol mapping while they must be explicit in other protocol
protocol mappings. mappings.
3.4. Errors and Exceptions 3.4. Errors and Exceptions
Well written data definitions include clear definitions how Well written data definitions include clear definitions how
implementations should react in various error situations or during implementations should react in various error situations or during
run-time exceptions. It is often a mistake if a data model writer run-time exceptions. It is often a mistake if a data model writer
assumes that implementers will choose a particular error code in a assumes that implementers will choose a particular error code in a
given error situation. For interoperability reasons, it is far given error situation. For interoperability reasons, it is far
better to spell out the precise behaviour in error situations and better to spell out the precise behaviour in error situations and
run-time exceptions. Unfortunately, it becomes quite difficult to be run-time exceptions. Unfortunately, it becomes quite difficult to be
precise about errors and exceptions in a protocol and naming system precise about errors and exceptions in a protocol and naming system
neutral data modeling framework such as SMIng since all error and neutral data modeling framework such as SMIng since all error and
exception reporting mechanisms of the underlying protocols need to be exception reporting mechanisms of the underlying protocols need to be
abstracted since otherwise description clauses become protocol abstracted because otherwise description clauses become protocol
specific. Furthermore, due to the varying features of the underlying specific. Furthermore, due to the varying features of the underlying
protocols, some errors and exceptions may only exist in some of the protocols, some errors and exceptions may only exist in some of the
mappings and must therefore be dealt with when the generic data model mappings and must therefore be dealt with when the generic data model
is mapped to a concrete protocol. is mapped to a concrete protocol.
3.5. Configuration Storage Models 3.5. Configuration Storage Models
Management protocols use different mechanisms to deal with Management protocols use different mechanisms to deal with
persistence of configuration state. The SNMP protocol uses persistence of configuration state. The SNMP protocol uses
StorageType [RFC2579] columns in conceptual tables to indicate which StorageType [RFC2579] columns in conceptual tables to indicate which
rows are persistent. The COPS-PR [RFC3084]protocol binds provisioned rows are persistent. The COPS-PR [RFC3084] protocol binds
information to the existence of the COPS-PR session which provisioned provisioned information to the existence of the COPS-PR session which
policy information. The NETCONF protocol [RFC4741] has a concept of provisioned policy information. The NETCONF protocol [RFC4741] has a
different data stores (running, startup, candidate) that imply concept of different data stores (running, startup, candidate) that
whether configuration state is persistent or not. imply whether configuration state is persistent or not.
Given these fundamentally different approaches, it is difficult to Given these fundamentally different approaches, it is difficult to
write protocol neutral configuration data models that work equally write protocol neutral configuration data models that work equally
well with the various management protocols. While it is possible to well with the various management protocols. While it is possible to
introduce say StorageType columns in protocol mappings, it is introduce say StorageType columns in protocol mappings, it is
sometimes awkward to define the semantics of data objects if the sometimes awkward to define the semantics of data objects if the
persistence model is left to the protocol mappings. persistence model is left to the protocol mappings.
3.6. Selection of Language Features 3.6. Selection of Language Features
A data modeling language should be based on a small orthogonal set of A data modeling language, like any good language, should be based on
language features. In addition, the language should be minimalistic. a small orthogonal set of language features to control the overall
During the design of the language, it is useful to repeatedly ask the complexity of the language, both in terms of usage and
question why certain features are needed or whether there are any implementation. While it is relatively easy to invent and propose
language rules without a strong justification. The general principle new features, it seems much harder to find a minimal and orthogonal
stated by Antoine de Saint-Exupery holds: set of basic features that addresses the requirements.
During the design of the SMIng language, it was found useful to
repeatedly ask the question why certain features are needed or
whether there are any language rules without a strong and convincing
justification. The general principle stated by Antoine de Saint-
Exupery was followed:
Perfection [in design] is achieved, not when there is nothing more Perfection [in design] is achieved, not when there is nothing more
to add, but when there is nothing left to take away. to add, but when there is nothing left to take away.
Language features should be selected by considering what tools can do Language features should be selected by considering what tools can
with the information formalized by a language feature. In the actually do with the information formalized by a language feature.
general case, language features should raise automation and improve In general, language features should raise automation and improve
clarity. Features without a clear justification that they actually clarity. Features without a clear justification that they actually
reduce implementation efforts or significantly improve the clarity of reduce implementation efforts or significantly improve the clarity of
a data model specification should not be accepted. a data model specification should not be accepted.
3.7. Syntax versus Semantics 3.7. Syntax versus Semantics
During the design of a data modeling language, it is most important During the design of a data modeling language, it is most important
to focus on a clear semantic of all language constructs. Syntactical to focus on a clear semantic of all language constructs. Syntactical
issues are of secondary importance. While this may sound obvious, it issues are of secondary importance. While this may sound obvious, it
is important especially in open concensus driven processes to keep is important, especially in open consensus driven processes, to keep
contributors reminded that semantics of language constructs come contributors reminded that semantics of language constructs come
first while the syntactic aspects are of secondary importance. first while the syntactic aspects are of secondary importance.
3.8. Reuse of Definitions 3.8. Reuse of Definitions
A good data modeling language should allow data model writers to A good data modeling language should allow data model writers to
produce reusable definitions. However, not all definitions are produce reusable definitions. However, not all definitions are
equally easy to reuse. Experience has shown that data types derived equally easy to reuse. Experience has shown that data types derived
from a small set of base types are usually very easy to reuse; from a small set of base types are usually very easy to reuse;
structured data types are often getting slightly more complex to structured data types are often getting slightly more complex to
skipping to change at page 8, line 20 skipping to change at page 9, line 31
constraining values is often a good thing, it should be noted that constraining values is often a good thing, it should be noted that
too strict constraints can turn out to be painful in the future. too strict constraints can turn out to be painful in the future.
There are many examples where data types proved too constrained to There are many examples where data types proved too constrained to
represent protocols that followed a natural evolution. represent protocols that followed a natural evolution.
3.9. Versioning and Meta Information 3.9. Versioning and Meta Information
Changes to data models are inevitable. Even the most careful design Changes to data models are inevitable. Even the most careful design
and review process will not be able to predict how technologies and review process will not be able to predict how technologies
evolve in the future. It is therefore crucial that the data modeling evolve in the future. It is therefore crucial that the data modeling
language supports a suitable versioning model and that it established language supports a suitable versioning model and that it establishes
clear rules which changes are possible without having to change a clear rules which changes are possible without having to change a
version number or (module) name. Supporting complex collections of version number or (module) name. Supporting complex collections of
meta data (e.g., a granular revision log) as part of the data meta data (e.g., a granular revision log) as part of the data
modeling language may be less of an issue since such information can modeling language may be less of an issue since such information can
often be maintained in revision control systems and automatically often be maintained in revision control systems and automatically
places into comments where needed. placed into comments where needed.
3.10. Extensibility 3.10. Extensibility
It has proven to be useful to support language extensibility features It has proven to be useful to support language extensibility features
that avoid backward compatibility problems with existing parsers when that avoid backward compatibility problems with existing parsers when
new language features are introduced. If a data modeling language new language features are introduced. If a data modeling language
supports language extensions, it should be possible to gradually supports language extensions, it should be possible to gradually
introduction of new language features. introduce new language features.
Supporting language extensions essentially requires to be very Supporting language extensions essentially requires to be very
consistent with the syntactic structure so that implementations can consistent with the syntactic structure so that deployed
skip over new language constructs. In addition, it is necessary to implementations can skip over new language constructs. In addition,
precisely identify language extensions so that implementations it is necessary to precisely identify language extensions so that
supporting extensions know where to apply the appropriate additional implementations supporting extensions know where to apply the
processing. appropriate additional processing.
3.11. Language Independence 3.11. Language Independence
Once way to define a new data modeling language is to start from an One way to define a new data modeling language is to start from an
existing language and to extend it and/or subset it as needed. existing language and to extend it and/or subset it as needed.
However, there are some dangers associated with this approach. Since However, there are some dangers associated with this approach.
languages that are used are not static, it is important to deal with
conflicts that can arise if the base language is revised such that Since languages that are in actual use are not static, it is
the extensions or subsets do not work anymore. This issue becomes important to deal with conflicts that can arise if the base language
particularly important if different organizations have change control is revised such that the extensions or subsets do not work anymore.
since this makes coordination relatively complex. Things get even This issue becomes particularly important if different organizations
worse if the data modeling extension constitutes not a significant have change control since this makes coordination relatively complex.
usage of the core language. Things get even worse if the data modeling extension constitutes not
a significant usage of the core language.
Another risk associated with sub-setting an existing language is that
generic tools are likely not aware of the subset allowed in data
models and hence such tools will not help to restrict the features of
the general language to the subset adequate to define management data
models.
The alternative is to provide a complete and self-contained The alternative is to provide a complete and self-contained
definition for the data modeling language. This protects against definition for the data modeling language. This protects against
change control issues and also makes it simpler for implementors or change control issues and also makes it simpler for implementers or
data model writers to find all language rules in one place. data model writers to find all language rules in one place.
As a general rule, there is hardly a reason to import language As a general rule, there is hardly a reason to import language
definitions. If you like to import something from a source that is definitions from other organizations. If you like to import
likely to change, do not import. If, however, the source is assumed something from a source that is likely to change, do not import. If,
to be stable, then you can just import by value and explain the however, the source is assumed to be stable, then you can just import
relationship to the original source. by value and explain the relationship to the original source.
3.12. Compliance and Conformance 3.12. Compliance and Conformance
Any successful data modeling language will at some point have to deal Any successful data modeling language will at some point have to deal
with compliance and conformance definitions. However, getting with compliance and conformance definitions. However, designing
language features to express compliance and conformance statements language features to express compliance and conformance statements is
right is non-trivial. Very fine grained mechanisms to define non-trivial. Very fine grained mechanisms to define implementation
implementation requirements for different usage scenarios can lead to requirements for different usage scenarios can lead to very detailed
very detailed but also very complex compliance and conformance but also very complex compliance and conformance definitions that are
definitions that are difficult to understand and review. difficult to understand, review and maintain.
It is therefore important to make a good tradeoff between the It is therefore important to make a good trade-off between the
required expressiveness and the pragmatic usage of compliance and required expressiveness and the pragmatic usage of compliance and
conformance definitions. The general considerations for language conformance definitions. The general considerations for language
features discussed Section 3.6 particularly apply here. One approach features discussed Section 3.6 particularly apply here. One approach
is to first gain experience with the usage of a new data modeling is to first gain experience with the usage of a new data modeling
language and to support compliance and conformance definitions language and to support compliance and conformance definitions
through language extensions. through language extensions, improving their expressiveness over time
as needed.
4. Conclusions 4. Conclusions
This memo documents some of the insights gained in the SMIng project This memo documents some of the insights gained in the SMIng project
in order to guide future data modeling language designers by making in order to guide future data modeling language designers by making
them aware of some of the problems encountered in the SMIng project them aware of some of the problems encountered in the SMIng project
and some of the design guidelines that have been developed through and some of the design guidelines that have been developed through
the project. the project.
While protocol independent data modeling languages seem like a very
good idea in world which uses several different management protocols
for different tasks and deployments, the complexity associated with
the design and effective usage of protocol independent data modeling
languages should not be underestimated.
5. IANA Considerations 5. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
This document discusses lessons learned during the design of a This document discusses lessons learned during the design of a
network management data modeling language and they have no impact on network management data modeling language and they have no impact on
the security of the Internet. the security of the Internet.
7. Acknowledgements 7. Acknowledgements
Many people contributed directly or indirectly to this documented Many people contributed directly or indirectly to this documented
through their participation in the SMIng project. Frank Strauss through their participation in the SMIng project. Martin Bjorklund,
David Harrington, Balazs Lengyel, Frank Strauss and Bert Wijnen
provided valuable feedback on earlier versions of this document. provided valuable feedback on earlier versions of this document.
8. Informative References 8. Informative References
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
RFC 2578, STD 58, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", RFC 2579, April 1999. "Textual Conventions for SMIv2", RFC 2579, STD 58,
April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", RFC 2580, STD 58,
April 1999.
[RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A.
Smith, "COPS Usage for Policy Provisioning (COPS-PR)", Smith, "COPS Usage for Policy Provisioning (COPS-PR)",
RFC 3084, March 2001. RFC 3084, March 2001.
[RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn,
S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure
of Policy Provisioning Information (SPPI)", RFC 3159,
August 2001.
[RFC3216] Elliot, C., Harrington, D., Jason, J., Schoenwaelder, J.,
Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216,
December 2001.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780, May 2004. Structure of Management Information", RFC 3780, May 2004.
[RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation [RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation
Structure of Management Information (SMIng) Mappings to Structure of Management Information (SMIng) Mappings to
the Simple Network Management Protocol (SNMP)", RFC 3781, the Simple Network Management Protocol (SNMP)", RFC 3781,
May 2004. May 2004.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
January 2003. January 2003.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006. December 2006.
[DSOM99] Schoenwaelder, J. and F. Strauss, "Next Generation
Structure of Management Information for the Internet",
Springer LNCS 1700, October 1999.
Author's Address Author's Address
Juergen Schoenwaelder Juergen Schoenwaelder
Jacobs University Bremen Jacobs University Bremen
Campus Ring 1 Campus Ring 1
28725 Bremen 28725 Bremen
Germany Germany
Phone: +49 421 200-3587 Phone: +49 421 200-3587
Email: j.schoenwaelder@jacobs-university.de Email: j.schoenwaelder@jacobs-university.de
 End of changes. 46 change blocks. 
144 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/