Network Working Group R. Presuhn, Ed.
Internet-Draft Retired
Intended status: Informational January 30, 2008
Expires: August 2, 2008
Requirements for a Configuration Data Modeling Language
draft-presuhn-rcdml-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo contains a compilation of requirements for a Configuration
Data Modeling Language. Although focusing on the needs of the
NETCONF Protocol, these requirements potentially have broader
applicability. Comments should be sent to ngo@ietf.org.
Presuhn Expires August 2, 2008 [Page 1]
Internet-Draft Data Modeling Language Requirements January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Previous Work . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Taxonomy of Requirements . . . . . . . . . . . . . . . . . . . 5
3.1. Consequences of NETCONF . . . . . . . . . . . . . . . . . 6
3.1.1. Notification Definition #13 (Agreed) . . . . . . . . . 6
3.1.2. Notification Get #14 (NOT Agreed) . . . . . . . . . . 6
3.1.3. Define Actions (NOT Agreed) . . . . . . . . . . . . . 7
3.1.4. Locking #53 (Agreed) . . . . . . . . . . . . . . . . . 7
3.1.5. All Base Operations #56 (Agreed) . . . . . . . . . . . 7
3.1.6. Define new NETCONF Operations #60 (Agreed) . . . . . . 7
3.1.7. Separation of Operations and Payload #75 (Agreed) . . 8
3.1.8. NETCONF Error Strings (disappeared) . . . . . . . . . 8
3.2. Model Representation Requirements . . . . . . . . . . . . 8
3.2.1. Human Readable #3 (Agreed) . . . . . . . . . . . . . . 8
3.2.2. Machine Readable #2 (Agreed) . . . . . . . . . . . . . 8
3.2.3. Textual Representation #18 (Agreed) . . . . . . . . . 8
3.2.4. Language Versioning Rules #35 (Agreed) . . . . . . . . 8
3.2.5. Document Information #34 (Agreed) . . . . . . . . . . 9
3.2.6. Ownership and Change Control #31 (Agreed) . . . . . . 9
3.2.7. Dependency Risk Reduction (Agreed) . . . . . . . . . . 9
3.2.8. Diff-Friendly #17 (Agreed) . . . . . . . . . . . . . . 9
3.2.9. Internationalization and Localization . . . . . . . . 9
3.2.10. Model Equivalence #42 (NOT agreed) . . . . . . . . . . 10
3.3. Reusability Requirements . . . . . . . . . . . . . . . . . 11
3.3.1. Modularity #20 (Agreed) . . . . . . . . . . . . . . . 11
3.3.2. Reusable Definitions #30/46 (Agreed) . . . . . . . . . 11
3.3.3. Modular extension #22 (Agreed) . . . . . . . . . . . . 11
3.4. Instance Data Requirements . . . . . . . . . . . . . . . . 11
3.4.1. Default Values on the Wire (Agreed) . . . . . . . . . 11
3.4.2. Ordering . . . . . . . . . . . . . . . . . . . . . . . 11
3.4.3. Validation . . . . . . . . . . . . . . . . . . . . . . 12
3.4.4. No Mixed Content #64 (Agreed) . . . . . . . . . . . . 13
3.4.5. Instance Canonicalization #69 (Agreed) . . . . . . . . 13
3.4.6. Character Set and Encoding (Agreed) . . . . . . . . . 13
3.4.7. Model Instance Localization (NOT Agreed) . . . . . . . 13
3.5. Semantic Richness Requirements . . . . . . . . . . . . . . 13
3.5.1. Human-Readable Semantics (Agreed) . . . . . . . . . . 13
3.5.2. Error Annotation #16 (Agreed) . . . . . . . . . . . . 14
3.5.3. Basic Types #45 (Agreed) . . . . . . . . . . . . . . . 14
3.5.4. Handling Opaque Data #50 (Agreed) . . . . . . . . . . 14
3.5.5. Handling Non-Opaque Data #51 (NOT Agreed) . . . . . . 14
3.5.6. Keys . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.5.7. Relationships . . . . . . . . . . . . . . . . . . . . 15
3.5.8. Referential Integrity . . . . . . . . . . . . . . . . 16
3.5.9. Characterize Data #4/5/9 (Agreed) . . . . . . . . . . 16
3.5.10. Defaults . . . . . . . . . . . . . . . . . . . . . . . 17
Presuhn Expires August 2, 2008 [Page 2]
Internet-Draft Data Modeling Language Requirements January 2008
3.5.11. Formal Constraints . . . . . . . . . . . . . . . . . . 17
3.6. Extensibility Requirements . . . . . . . . . . . . . . . . 18
3.6.1. Language Extensibility . . . . . . . . . . . . . . . . 18
3.6.2. Model Extensibility . . . . . . . . . . . . . . . . . 18
3.6.3. Instance Data Extensibility . . . . . . . . . . . . . 19
3.7. Talking About Conformance . . . . . . . . . . . . . . . . 19
3.7.1. Conformance to the Modeling Language #74 (NOT
Agreed) . . . . . . . . . . . . . . . . . . . . . . . 20
3.7.2. Conformance to a Model #11 (Agreed) . . . . . . . . . 20
3.8. Techno-Political Constraints . . . . . . . . . . . . . . . 21
3.8.1. Standard Technology #1 (NOT Agreed) . . . . . . . . . 21
3.8.2. Translate Models to Other Forms #47 (Agreed) . . . . . 21
3.8.3. Minimize SMI Translation Pain #33 (NOT Agreed) . . . . 21
3.8.4. Generate Models from Other Forms #49 (NOT Agreed) . . 21
3.8.5. Isolate Models from Protocol #29 (NOT Agreed) . . . . 22
3.8.6. Library Support #39 (NOT Agreed) . . . . . . . . . . . 22
3.8.7. RFC 3139 Considerations . . . . . . . . . . . . . . . 22
3.8.8. RFC 3216 Considerations . . . . . . . . . . . . . . . 22
4. Requirement Interactions . . . . . . . . . . . . . . . . . . . 22
5. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Conformance to the Modeling Language . . . . . . . . . . . 22
5.2. Conformance to Schemas Defined Using the Modeling
Language . . . . . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix B. Use Cases . . . . . . . . . . . . . . . . . . . . . . 25
B.1. Multi-Version Scenarios . . . . . . . . . . . . . . . . . 25
B.1.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 25
B.1.2. Loosely Coupled - Support Matrix . . . . . . . . . . . 26
B.1.3. Forwards Compatibility . . . . . . . . . . . . . . . . 26
B.1.4. Mixed-Mode Forwards and Backwards Compatibility . . . 26
B.1.5. Multiple Extensions . . . . . . . . . . . . . . . . . 26
Appendix C. Example Instance Documents . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Presuhn Expires August 2, 2008 [Page 3]
Internet-Draft Data Modeling Language Requirements January 2008
1. Introduction
THIS IS STILL A VERY PRELIMINARY VERSION OF THIS MEMO. ALTHOUGH
EXPANDED AND CLARIFIED FROM -00, MOST POINTS ARE STILL UNDER
DISCUSSION BY THE DESIGN TEAM, AND MAY CHANGE AT ANY MOMENT. IN
PARTICULAR, INDICATIONS OF "AGREED" or "NOT AGREED" ARE TO BE TAKEN
WITH A GRAIN OF SALT, AND EXAMPLES AND USE CASES ARE STILL
INCOMPLETE.
Following discussions at the Vancouver IETF meeting (IETF 70), Dan
Romascanu organized a design team to work on Requirements for a
Configuration Data Modeling Language with participation from the
Applications area as well as the Operations and Management area.
This memo is that design team's product.
The principal goal of this memo is to increase the chances for a
successful BOF in Philadelphia at the seventy-first IETF meeting.
The goal of the BOF is to decide what needs to be done to support the
development of data models for configuration in the IETF, focusing on
the immediate requirements for the NETCONF protocol [RFC4741]. To
expedite the process, the design team started with requirements
gathered at previous IETF meetings where data modeling languages had
been discussed, as well as collecting requirements from the various
teams working in this space. These included both efforts to develop
new solutions as well as ones reusing or extending existing data
modeling languages and tools. The team identified the common
requirements, as well as ones motivating particular choices made in
specific solutions.
The focus of the requirements described here is on the immediate
needs of the Operations and Management Area and the NETCONF protocol,
and builds on precedent work, such as [RFC3535]. The design team
recognizes that a data modeling language based on these requirements
MAY have applicability beyond NETCONF, and that consequently the
decision to support any of these requirements SHOULD always be
considered in the light of the potential impact on extensibility and
broader applicability envisioned.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Previous Work
Numerous languages exist to describe data types and structured data
in the abstract, with associated sets of rules to describe how that
data can be transfered over networks. Important ones include:
Presuhn Expires August 2, 2008 [Page 4]
Internet-Draft Data Modeling Language Requirements January 2008
o ASN.1 (Abstract Syntax Notation One) with various encoding rules,
such as
* BER (Basic Encoding Rules)
* XER (XML Encoding Rules)
o XML (Extensible Markup Language) Schema
o RelaxNG (Regular Language for XML, New Generation)
o XDR (External Data Representation) [RFC4506]
All of these describe type systems and the structuring of
information, with relatively little emphasis given to representing
the information's semantics.
There have been numerous efforts over the years to develop languages
with the additional semantics needed to be suitable for defining
models for management data in general and configuration data in
particular. Some of the more important ones include:
o GDMO (Guidelines for the Definition of Managed Objects) with GRM
(General Relationship Model) extensions
o SMIv2 (Structure of Management Information version 2) [RFC2578]
o SPPI (Structure of Policy Provisioning Information) [RFC3159]
o SMIng (Next Generation Structure of Management Information)
[RFC3780]
o CIM (Common Information Model)
All of these presume a particular meta-model of the information to be
managed. To varying degrees these are all associated with specific
management protocol suites. None of these has yet gained serious
support as a model definition language for the NETCONF environment,
although some show pockets of use.
Efforts in the area of general-purpose information modeling have
largely converged in the UML effort. There has been little interest
in the IETF in using UML to standardize configuration data models.
There have been previous efforts to define a protocol-neutral data
modeling language in the IETF, including both requirements gathering
[RFC3216] and language definition [RFC3780]. The experience
[I-D.schoenw-sming-lessons] tempers claims that true protocol
neutrality is a sine qua non, even for very similar underlying
information models.
3. Taxonomy of Requirements
The grouping of requirements in this section is merely one chosen by
the design team for its convenience in helping separate easily-
confused requirements. The major categories are:
1. Consequences of Netconf
2. Representation of Models
Presuhn Expires August 2, 2008 [Page 5]
Internet-Draft Data Modeling Language Requirements January 2008
3. Reusability
4. Instance Data
5. Semantics of Models
6. Extensibility
7. Conformance
8. Techno-Political Constraints
The reader will notice that certain similar-sounding issues arise in
multiple categories. For example, representation of multilingual
information is a concern both for the representation of models as
well as for the representation of instance data. The issues are
included in both areas because they potentially afford different
solutions.
NOTE THAT ISSUE NUMBERS OF THE FORM #nn IN THIS SECTION ARE ONLY
TEMPORARY, USED BY THE DESIGN TEAM IN CROSS-CHECKING WITH SOURCE
REQUIREMENT LISTS. THEY WILL GO AWAY IN A FUTURE VERSION OF THIS
MEMO.
3.1. Consequences of NETCONF
Some requirements are direct consequences of the way the NETCONF
protocol works, and might be inappropriate for a protocol-neutral
configuration data modeling language. These differ from requirements
more about the information that NETCONF is managing. Whether
addressed as part of the modeling language itself, or as part of a
"binding" of that language for use with the NETCONF environment, a
solution needs to address these concerns.
3.1.1. Notification Definition #13 (Agreed)
The solution MUST support defining notifications. The solution MUST
describe any transformations or adaptations necessary to transport
notifications using the mechanisms defined in
[I-D.ietf-netconf-notification].
3.1.2. Notification Get #14 (NOT Agreed)
The solution MAY support defining notifications in a way that
minimizes duplication of definitions for polled or configured
content. This reduces errors caused by the failure to maintain
syntactic and semantic alignment of separate definitions. It also
permits what is logically the same chunk of information to be sent
via a get (or modified using edit-config) as would be conveyed
asynchronously in a notification.
There are three ways to define notifications:
Presuhn Expires August 2, 2008 [Page 6]
Internet-Draft Data Modeling Language Requirements January 2008
1. Completely separate the definition of the data elements and their
container from the definitions of the information objects defined
for get and edit-config operations.
2. Re-use the element definitions from get and edit-config
operations, but define a new container object for the
notification itself (as with SNMP)
3. Re-use both element definitions and containers from the
definition of content for get and edit-config operations. In
this method, notifications can almost be said to not require
defining. (This begs the question of what the semantics of the
notification itself are bound to.)
The solution SHOULD describe whether and how each of these is
handled. Some specific use cases for this are data change
notifications as well as being able to store and send alarm
definitions with the same definition. Note that the third option
makes log records much easier as well and that both the second and
third options may simplify fine-grained access control, if that is
required.
3.1.3. Define Actions (NOT Agreed)
The solution MAY provide a way to define specific actions to be
performed. Note that this is distinct from adding new operations
types to the protocol. If supported, the solution MUST describe how
these are mapped into the NETCONF protocol.
3.1.4. Locking #53 (Agreed)
The solution MUST NOT preclude fine grained locking, as described for
the NETCONF environment in the work-in-progress
[I-D.ietf-netconf-partial-lock].
3.1.5. All Base Operations #56 (Agreed)
The solution MUST unambiguously describe how all NETCONF [RFC4741]
base operations work with data defined under a model produced using
the solution. This includes both how information appears on the wire
as well as any effects on the configuration data store.
3.1.6. Define new NETCONF Operations #60 (Agreed)
The solution MUST provide a means to define new NETCONF operations
and their parameters (base, vendor extensions, and so on) in the same
language as is used for defining models.
Presuhn Expires August 2, 2008 [Page 7]
Internet-Draft Data Modeling Language Requirements January 2008
3.1.7. Separation of Operations and Payload #75 (Agreed)
If the solution provides a means for defining new NETCONF operations,
it MUST allow a clear separation between data model definitions and
the definition of new NETCONF operations.
3.1.8. NETCONF Error Strings (disappeared)
The solution should described how specific error strings are
associated with error conditions as required by the NETCONF protocol.
3.2. Model Representation Requirements
The requirements in this section are all connected to the mechanics
of how models are represented and manipulated, rather than what they
express. One issue, model canonicalization, straddles the border
between this grouping and the group on model semantics. It is in
this group because the use case for it is associated with others in
this group, such as performing a "diff" between versions of a model.
3.2.1. Human Readable #3 (Agreed)
The solution MUST support a human-readable representation of data
models. This requirement is independent of how an instance of a
model is represented.
3.2.2. Machine Readable #2 (Agreed)
The solution MUST support a machine-readable representation of data
models.
3.2.3. Textual Representation #18 (Agreed)
The solution MUST support a text-based representation for models. It
MAY support other representations. It MUST be possible to represent
model definitions as ASCII text in 72 columns so standard data models
can be included in RFCs. This requirement is independent of how an
instance of a model is represented.
3.2.4. Language Versioning Rules #35 (Agreed)
The data modeling language itself MUST be versioned. See the
requirements for language extensibility in the extensibility section
below for some of the motivations for this requirement.
Presuhn Expires August 2, 2008 [Page 8]
Internet-Draft Data Modeling Language Requirements January 2008
3.2.5. Document Information #34 (Agreed)
The solution MUST provide a means to specify document information for
a data model, such as when it was created, its revision history,
point of contact, and so on.
3.2.6. Ownership and Change Control #31 (Agreed)
It MUST be clear who exercises change control and ownership over the
data modelling framework, e.g., the IETF. This MUST also be clear
for the technologies on which it depends.
3.2.7. Dependency Risk Reduction (Agreed)
In cases where a proposed solution depends on other specifications,
there MUST be a way to reference the specific versions required, in
case that specification evolves in incompatible ways. This
requirement is motivated by bad experiences with how the ASN.1
specification mutated after its first version.
3.2.8. Diff-Friendly #17 (Agreed)
It MUST be possible for an operator using existing tools such as
"diff" to determine what has changed between two versions of a data
model.
3.2.9. Internationalization and Localization
There are several requirements associated with issues related to
languages and character sets in the representation of models. Note
that, with the exception of literal strings, these are distinct from
the questions about what appears in an instance of a model.
3.2.9.1. Descriptions using Local Languages #19 (Agreed)
The solution MUST be able to support the use of Unicode text in a
model definition to provide human readable descriptions of
information semantics. This is effectively required by [RFC2277].
This is not the same thing as requiring a mechanism for the
internationalization and localization of models, but rather a way of
allowing the model definer to work in his or her preferred language.
3.2.9.2. UTF-8 Encoding (Agreed)
It MUST be possible to encode model definitions using UTF-8. This is
effectively required by [RFC2277] as a consequence of the need for a
textual representation and the need to be able to include descriptive
text in the model definer's language of choice.
Presuhn Expires August 2, 2008 [Page 9]
Internet-Draft Data Modeling Language Requirements January 2008
3.2.9.3. Localization Support (Agreed)
The solution MUST outline how localization of an existing model would
proceed. The strong preference of members of the design team was to
treat model localization as a user interface issue. The solution
MUST be in alignment with the guidance given by [RFC2277].
3.2.9.4. Error String Localization #66 (Agreed)
The solution MUST NOT preclude localization for user display of
NETCONF error strings defined in conjunction with a data model.
(Since the NETCONF protocol itself does not provide for language
negotiation, such localization would presumably take place within the
NETCONF client. The question is how to associate an error string
defined as part of a model with its localization.)
3.2.9.5. Tag Names and Strings in Local Languages #67 (NOT agreed)
The solution MAY support the use of Unicode text for tag names and
strings in definitions. Note that this is not a question of
internationalization and localization, but rather the use of Unicode
for what are effectively protocol elements in an instance document
for a model defined using the solution. Even if a solution does
support the use of Unicode text for tag names and strings in
definitions, it SHOULD provide guidance on the use of an ASCII subset
for tags, since specifications for publication in an RFC will almost
certainly need to be written with such a restriction in mind. Note
also that this requirement can interact badly with solutions that use
labels taken directly (without any mapping) from models to generate
code in programming languages, which may have severe restrictions on
identifiers.
3.2.10. Model Equivalence #42 (NOT agreed)
It SHOULD be possible to determine whether two models are equivalent,
even if their definitions are not textually identical. This is an
extension of the requirement to be able to perform a "diff" of two
versions of a model. Though simplified by the requirement that there
needs to be a text-based way to represent a model, having a canonical
representation for model definitions could potentially improve the
accuracy of a "diff", and leads the way to being able to determine
whether two models are equivalent. Equivalence is understood here as
meaning that the sets of canonical representations of the instance
documents which could be generated from the two models are equal.
This requirement is distinct from the ability to generate a canonical
representation of an instance of model data.
Presuhn Expires August 2, 2008 [Page 10]
Internet-Draft Data Modeling Language Requirements January 2008
3.3. Reusability Requirements
The reusability requirements could also be though of as a sub-
category of the semantic richness requirements, since they focus on
the expressiveness of the modeling language. Their inclusion as a
top-level category of requirement reflects their importance to
standards-making.
3.3.1. Modularity #20 (Agreed)
The solution MUST provide a means to define data models in discrete
pieces, and support the publication of portions of models in separate
files.
3.3.2. Reusable Definitions #30/46 (Agreed)
The solution MUST support a way to reuse definitions from another
model. A type definition is a type of reusable definition. Note
that this potentially interacts with requirements to be able to
revise or extend a model.
3.3.3. Modular extension #22 (Agreed)
It should be possible to extend a published data model without
modifying it. Those specifying solutions are advised to carefully
consider how this capability might interact with the ability to
revise definitions and the ability to reference definitions in other
models.
3.4. Instance Data Requirements
This section contains specific requirements on what instance
documents for models defined using the solution will look like.
These are largely independent of requirements for what the modeling
language would look like, but do interact with the semantic
capabilities of the language.
3.4.1. Default Values on the Wire (Agreed)
The solution MUST specify how default values affect what is and is
not explicitly encoded in an instance document. Possibilities
include a default-free data modeling language, protocol-specific
default handling, or protocol-independent prescribed behavior.
3.4.2. Ordering
The common factor in this group of requirements is the ordering of
pieces of data on the wire. The cases differ in what is being
Presuhn Expires August 2, 2008 [Page 11]
Internet-Draft Data Modeling Language Requirements January 2008
ordered, and whether the ordering of itself conveys information. The
order in which things can appear in an instance document potentially
affects not only the complexity of the code to validate or parse it,
but can also interact with attempts to extend the corresponding
models.
3.4.2.1. Ordered Lists #32 (Agreed)
The solution MUST support the ability to specify whether the order of
list entries in an instance document has semantic significance, and
MUST consequently be preserved. An example of such a list might be a
list of access control rules. An example of a list where the order
would have no semantic significace might be a list of users.
3.4.2.2. Order within Containers (NOT Agreed)
A solution MAY support the ability to specify that in an instance of
a data model, the order of child elements within a containing element
needs to be preserved, due to semantics, backward compatibility
requirements, or processing efficiency considerations.
3.4.2.3. Interleaving (NOT Agreed)
A solution MAY support the ability for a model to allow interleaving
elements in the XML representation of an instance of a data model.
This means that those child elements MAY appear in any order on the
wire.
3.4.3. Validation
This section contains requirements pertaining to the validation of an
instance document. The term "valid" means more than merely well-
formed, and in the context of network management it includes the
notion of conforming to the semantics of a schema. A solution
proposal MUST describe precisely what is meant when by terms like
"valid" and "well-formed".
3.4.3.1. Validate Instance Data #40 (Agreed)
A solution proposal MUST provide sufficient detail to allow a
determination to be made whether an instance of a data model is well-
formed and valid in terms of the schema, as well as any additional
considerations.
3.4.3.2. Tools to Validate Instance Data #41 (NOT Agreed)
A solution MAY provide a means of determining whether an instance
document is a valid instance of a model.
Presuhn Expires August 2, 2008 [Page 12]
Internet-Draft Data Modeling Language Requirements January 2008
3.4.4. No Mixed Content #64 (Agreed)
The solution MUST NOT support mixed content, i.e., mixing tags and
data together, other than to treat it as opaque information. This
requirement could be understood as a consequence of the NETCONF
protocol environment.
3.4.5. Instance Canonicalization #69 (Agreed)
The solution MUST describe how to produce a canonicalized version of
the instance. This is a transform which can put the data in a form
which is suitable for comparison. See "Canonical XML Version 1.0"
[RFC3076] for more information. This does not imply that there is
any requirement for data on the wire to be sent in canonicalized
form. The design team recognizes that there is a point of
diminishing returns in canonicalizing human-readable strings, and
advises those proposing solutions to consider the trade-offs and not
get carried away.
3.4.6. Character Set and Encoding (Agreed)
The solution should support the creation of models which can handle
human-readable information in any language in an instance document.
In keeping with [RFC2277], this means that models MUST be able to
handle UTF-8 data appropriately.
3.4.7. Model Instance Localization (NOT Agreed)
Tags and other human-readable portions of an instance of a model
SHOULD be localizable. Underlying this requirement is the question
of whether tags in an instance document are really "human-readable"
or merely protocol elements. This requirement needs clarification:
is it a question of what an instance document looks like between a
NETCONF client and server, or is it a question of how an instance
document might be transfored for presentation to a user?
3.5. Semantic Richness Requirements
The requirements in this section are all related to the need to
describe information models in more than purely syntactic terms.
3.5.1. Human-Readable Semantics (Agreed)
The solution MUST provide a means for the developer of an information
model to associate human-readable text with components of that model,
in order to describe their semantics and use.
Presuhn Expires August 2, 2008 [Page 13]
Internet-Draft Data Modeling Language Requirements January 2008
3.5.2. Error Annotation #16 (Agreed)
The solution MUST be able to define specific error messages for a
given element. Note that this could interact with support for
internationalization and localization. (Shouldn't this be moved to
the NETCONF-specific requirements? The ability to associate specific
error messages with a given element is absent from several protocols
used for configuration management.)
3.5.3. Basic Types #45 (Agreed)
The solution MUST define frequently used types. This could be
accomplished in a standard data model definition as part of a
solution or part of the language definition, for example.
3.5.4. Handling Opaque Data #50 (Agreed)
It MUST be possible to perform certain operations on opaque data.
This means that completely replacing the data would be supported, but
not merging, for example. This data potentially does not conform to
any schema definition, but may happen to be well-formed XML within
the opaque.
3.5.5. Handling Non-Opaque Data #51 (NOT Agreed)
It should be possible to support all NETCONF operations on non-opaque
data that is not conformant to a schema definition. This includes
both data conforming to unknown schemas, and data which cannot
conform to a valid data model, which is nonetheless well-formed XML.
3.5.6. Keys
3.5.6.1. Define Keys #6 (Agreed)
The solution MUST support defining keys to data (i.e. the list of
fields which uniquely identify an element, or a specially created
identifier like an ifIndex or an XML id.)
3.5.6.2. Deep Keys #54 (NOT Agreed)
The solution SHOULD support using as a key the value of an element
which is not an immediate descendent of the element being "keyed".
Presuhn Expires August 2, 2008 [Page 14]
Internet-Draft Data Modeling Language Requirements January 2008
Example...
4 <--- key for module
3.5.7. Relationships
3.5.7.1. Simple Relationships #7( Agreed)
The solution should support defining cross references between
elements in different hierarchies. This should be a formal machine
readable definition rather than the value of an implicitly known
field. The solution should support defining reference pointers for
1:1 and 1:n relationships.
3.5.7.2. Many-to-Many Relationships #8 (NOT Agreed)
The solution should support defining many to many cross reference
relationships.
3.5.7.3. Retrieve Relationships instance #52 (NOT Agreed)
[Note this text needs to be reworked.]
It should be possible to represent specific relationship instances in
the data model instance. The model will define that objects are
related and this requirement is that the instantiation of that
relationship is visible in the instance data. For example, if there
is a general relationship between a card and a port, it should be
possible in the instance document to learn that it is specifically
card 12 that is involved in the relationship. This does not require
repeating information that can be learned from reading the schema.
2
Ideally onCard can be directly related back to the definition of the
relationship in the model rather then being a field who happens to
share the same value.
Presuhn Expires August 2, 2008 [Page 15]
Internet-Draft Data Modeling Language Requirements January 2008
3.5.7.4. Retrieve Relationships - qualified (NOT Agreed)
The language should support the ability to learn about specific
relationships in the instance document, including some context. For
example, if there is a general relationship between a card and a
port, it should be possible in the instance document to learn that it
is specifically card 12 that is involved in the relationship and the
information would be provided in a more descriptive manner to enable
some interpretation of in the absence of the schema - by being
displayed to a user as text for example.
3.5.8. Referential Integrity
3.5.8.1. Referential Integrity #25 (NOT Agreed)
It should be possible to describe in the modeling language that
validation (at configuration create / merge time) of data cross
references is required for a given piece of the model. For example,
it should be possible to verify that related data exists, and reject
a configuration if it is does not. Note this is only performed when
a NETCONF operation is being done. There is no requirement to
maintain this integrity over time and report issues. Cross
references are only within a given device's configuration (see also
extended referential integrity requirement)
3.5.8.2. Extended Referential Integrity #58 (NOT Agreed)
It should be possible to support more complex validating of instance
data cross references. Examples, pre-provisioning, validating
against unreachable resources (not just configuration data present on
the device - non-configuration data on this device or configuration
on other devices)
3.5.8.3. Referential Integrity Recovery #73 (NOT Agreed)
It should be possible to support validating of instance data cross
references and indicating the action to be taken if expected
references are not available beyond simply erroring.
3.5.9. Characterize Data #4/5/9 (Agreed)
The solution MUST be able to model configuration data. The solution
MUST be able to model non-configuration data, such as status
information and statistics. The solution MUST support characterizing
data definitions in a model as configuration or non-configuration.
The solution MAY support further characterization, such as
identifying status or statistics.
Presuhn Expires August 2, 2008 [Page 16]
Internet-Draft Data Modeling Language Requirements January 2008
3.5.10. Defaults
3.5.10.1. Default Values #10 (NOT Agreed)
The solution should support defining static default values for
elements. In the content of NETCONF, this is understood to mean that
in an edit-config "create" request, if the client does not provide
the value, the server will assume the specific value defined in the
model as the default. The solution should specify how this feature
interacts with backwards compatibility, canonicalization, and any
other NETCONF operations. The solution should specify the
implications for claims of conformance to a default if the server
uses a different default value.
3.5.10.2. Dynamic Defaults #44 (NOT Agreed)
The solution must support dynamic default values. These are defaults
whose value depends on the value of other fields. For example, if
the disk size is 2 gigs then the maximum file size is 1 meg, but if
the disk is 1 meg, then the maximum file size is 1 K.
3.5.11. Formal Constraints
3.5.11.1. Formal Description of Constraints #23 (Agreed)
It should be possible to specify constraints on the value of an
element such as uniqueness, ranges, patterns, etc. These constraints
can be evaluated in isolation and not related to other elements.
3.5.11.2. Multi-element Constraints #24 (NOT Agreed)
A solution MAY provide a means to define constraints on an element
which involve another element of the configuration. An example would
be where the value of an MTU depends on the ifType. Additional use
cases might include dependencies on some non-configuration data, such
as presence of a particular piece of hardware, or inter-system
constraints.
3.5.11.3. Non-Key Uniqueness #68 (Agreed)
The solution MUST provide a way to specify constraints on uniqueness
of non-key data elements. The scope of the uniqueness must be
specified (parent, device, etc.) The extent of checking and
enforcement needs to be spelled out. The solution MUST spell out
whether, for a model to be valid, this constraint always holds true,
or is it only required to be true at the time the configuration is
created or merged.
Presuhn Expires August 2, 2008 [Page 17]
Internet-Draft Data Modeling Language Requirements January 2008
3.6. Extensibility Requirements
3.6.1. Language Extensibility
3.6.1.1. Language Versioning #35 (Agreed)
The modeling language itself should be versioned.
3.6.1.2. User Extensions #21 (NOT Agreed)
It should be possible for the users to extend the language. This
means the ability of the user of the data modeling language, to add
new statements or functionality to the language.
It is useful for two things: - standards evolution - proprietary /
vendor-specific annotations Extensibility should be done in a way
that unknown extensions may be ignored.
3.6.1.3. Mandatory Extensions #57 (NOT Agreed)
It should be possible to label some language extensions as must-
understand. If the extension is not understood, then an error is
produced. [Open questions: What is the scope of the error? How is
it learned?]
3.6.1.4. Must-Understand Extensions #70 (NOT Agreed)
The solution should support defining language extensions which the
client must understand or otherwise error.
3.6.2. Model Extensibility
3.6.2.1. Model Version Identification #36 (Agreed)
Different versions of a given schema should be unambiguously
identified. This assumes that the schema itself can be uniquely
identified.
3.6.2.2. Interaction with defaults. # (NOT Agreed)
The solution should define interaction of model definition with
defaults. What happens when defaults are added to model or whether a
default can be changed.
3.6.2.3. Conformance Interface # (NOT Agreed)
The solution should define its interactions with conformance
Presuhn Expires August 2, 2008 [Page 18]
Internet-Draft Data Modeling Language Requirements January 2008
3.6.2.4. Obsolete Portions of a Model #15 (Agreed)
The solution MUST provide a way to signify that elements of a schema
are obsolete.
3.6.3. Instance Data Extensibility
These requirements deal with the impact on the instance data of
modifications to the model.
3.6.3.1. Schema Version of Instance # (NOT Agreed)
The solution should provide a means to determine what schema version
was used to generate an instance document.
3.6.3.2. Interaction with default Values # (NOT Agreed)
The solution should define its interactions with default values in
the instance, if supported. How does the fact that something is
defaulted show up on the wire and what happens when defaults are
added, removed or modified, for example.
3.6.3.3. Backwards Compatibility #43 (Agreed)
The solution should support the ability to extend the model and still
be usable to use it. A NETCONF client familiar with an older version
of the schema should still be able to function. An old client should
be able to work with a new server.
3.6.3.4. Forwards Compatibility #72 (NOT Agreed)
The solution should support the ability to extend the model and still
interoperate with older versions. A NETCONF client employing a newer
version of the schema should still be able to function with a server
using an older version.
3.6.3.5. Must-Understand Model Extensions #77 (NOT Agreed)
The solution should support defining model extensions which the
client must understand or otherwise error. Adding mandatory objects
to an update to a Schema for example.
3.7. Talking About Conformance
This section contains several requirements, all tied to the question
of what it means to claim conformance. The two major categories are:
Presuhn Expires August 2, 2008 [Page 19]
Internet-Draft Data Modeling Language Requirements January 2008
o Conformance to the modeling language
o Conformance to a specific data model
Discussion of issues related to conformance to a specific data model
can also be further refined into questions of what "conformance"
means for a NETCONF server and what it means for a NETCONF client.
3.7.1. Conformance to the Modeling Language #74 (NOT Agreed)
It must be understood how to evaluate whether or not a tool supports
the chosen solution.
3.7.2. Conformance to a Model #11 (Agreed)
The solution should support indicating compliance requirements for a
Schema. Note this does not necessarily imply it needs to be separate
definition from the actual content.
3.7.2.1. Conditional Conformance #65 (NOT Agreed)
The solution should provide a means of providing conditional
compliance. If this is MPLS, then you need the following stuff
supported, for example.
3.7.2.2. Server Conformance to Schema #26 (Agreed)
The solution MUST support a method of indicating whether support of
an object is required in order to claim conformance to a particular
schema.
A solution MUST spell out whether a means for specifying server
conformance to a schema exists. If such a means exists, it SHOULD
allow an automated determination of the elements (and possibly
subtypes or extensions) which MUST be processed (and not merely
ignored) by a server handling a NETCONF edit-config create or merge
operation.
3.7.2.3. Client Conformance To Schema #59 (NOT Agreed)
The solution should support a method of indicating whether presence
of an object is required in order to be a valid configuration.
[Mandatory to use (in a create) as NETCONF client as oppose to
mandatory to implement on NETCONF server]
A solution MUST spell out whether a means for specifying client
conformance to a schema exists. If such a means exists, it SHOULD
allow an automated determination of the elements (and possibly
subtypes or extensions) which MUST be processed (and not merely
ignored) by a server handling the response to NETCONF get-config
Presuhn Expires August 2, 2008 [Page 20]
Internet-Draft Data Modeling Language Requirements January 2008
operation.
Note that one could formulate this in terms of what is sent in an
edit-config operation, but that could be problematic if the solution
supports some types of defaults.
3.7.2.4. Versioned Conformance #12 (NOT Agreed)
The solution should provide a means of specifying what is required
for compliance when the schema is updated. One of the motivations
for this requirement is the need to know both what conformance to the
current version of a schema entails, as well as what conformance to a
previous version would entail. This becomes particularly important
when definitions are incorporated by reference in another model,
which is itself subject to revision.
3.8. Techno-Political Constraints
The requirements in this section arise mainly from the relationship
of this work to other standards, and technical constraints motivated
by factors other than the need to define network configuration
management data.
3.8.1. Standard Technology #1 (NOT Agreed)
The solution SHOULD leverage existing widely used language and tools
to define the NETCONF content, redefining as little as possible the
work that w3c and other relevant bodies have already done.
3.8.2. Translate Models to Other Forms #47 (Agreed)
The solution MUST support the ability to translate a model definition
to RelaxNG and XML Schema. Any proposed solution MUST describe
whether this translation is lossy or lossless and if lossy, what
information is lost.
3.8.3. Minimize SMI Translation Pain #33 (NOT Agreed)
Minimize translation pain from SMI into NETCONF content. Translation
of NETCONF content into SMI is not a consideration.
3.8.4. Generate Models from Other Forms #49 (NOT Agreed)
The solution should support higher level modelling languages. An
example would be generating configuration data models from UML
descriptions. (Possible or existing tools?)
Presuhn Expires August 2, 2008 [Page 21]
Internet-Draft Data Modeling Language Requirements January 2008
3.8.5. Isolate Models from Protocol #29 (NOT Agreed)
The solution, and data models developed using the solution, SHOULD
NOT be too tightly coupled to the NETCONF protocol. It should be
possible to evolve the NETCONF protocol and data models
independently. One use case is that it should also be possible to
transport the data model instance (NETCONF content) over other
protocols, such as FTP.
3.8.6. Library Support #39 (NOT Agreed)
The solution SHOULD have wide support from development languages C,
etc. The element of disagreement among the members of the design
team is whether the evaluation of a solution depends on the existence
or on the feasability of such support.
3.8.7. RFC 3139 Considerations
[RFC3139] defines "Requirements for Configuration Management of IP-
based Networks", which should be taken into consideration when
identifying a solution for use with NETCONF. Note that it is
possible that not all of these requirements will necessarily be
applicable to the current problem.
3.8.8. RFC 3216 Considerations
[RFC3216] defines "SMIng Objectives", which should be taken into
consideration when identifying a solution for use with NETCONF. Note
that not all of these requirements will necessarily be applicable to
the current problem.
4. Requirement Interactions
5. Conformance
For more detail on conformance-related issues, see "Talking About
Conformance" above.
5.1. Conformance to the Modeling Language
A solution MUST spell out what is meant by "conformance" to that
particular modeling language specification.
Presuhn Expires August 2, 2008 [Page 22]
Internet-Draft Data Modeling Language Requirements January 2008
5.2. Conformance to Schemas Defined Using the Modeling Language
When a solution is used to define specific data models, it is
important to be able to know what is meant by a claim of
"conformance" to a particular model, both from the perspective of a
client implementation and of a server implementation.
6. IANA Considerations
This document requires no action by IANA. Specifications based upon
these requirements will specify what, if any, IANA considerations are
appropriate.
7. Security Considerations
Although this document only lists requirements, some of these
requirements have security implications. For example, the
requirements for modular definitions open up the consideration of
possible attacks based on the modification of a component of a model
which is not under the control of the model developer. Other
concerns include robustness when an instance document conforms to a
model different from the one to which it purportedly conforms. The
evaluation of constraints specified in a model, which require
examining other configuration data, possibly even data from other
systems, opens another possible avenue of attack for consideration.
The kinds of models that can be defined by a solution will have
implications for an access control framework. Finally, as has long
been known, compilers and code generation tools are themselves open
to attack.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
8.2. Informative References
[I-D.ietf-netconf-notification]
Chisholm, S. and H. Trevino, "NETCONF Event
Notifications", draft-ietf-netconf-notification-11 (work
Presuhn Expires August 2, 2008 [Page 23]
Internet-Draft Data Modeling Language Requirements January 2008
in progress), November 2007.
[I-D.ietf-netconf-partial-lock]
Lengyel, B. and M. Bjorklund, "Partial Lock RPC for
NETCONF", draft-ietf-netconf-partial-lock-00 (work in
progress), January 2008.
[I-D.linowski-netconf-dml-requirements]
Linowski, B., Storch, M., Ersue, M., and M. Lahdensivu,
"NETCONF Data Modeling Language Requirements",
draft-linowski-netconf-dml-requirements-00 (work in
progress), January 2008.
[I-D.schoenw-sming-lessons]
Schoenwaelder, J., "Protocol Independent Network
Management Data Modeling Languages - Lessons Learned from
the SMIng Project", draft-schoenw-sming-lessons-01 (work
in progress), September 2007.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3076] Boyer, J., "Canonical XML Version 1.0", RFC 3076,
March 2001.
[RFC3139] Sanchez, L., McCloghrie, K., and J. Saperia, "Requirements
for Configuration Management of IP-based Networks",
RFC 3139, June 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] Elliott, C., Harrington, D., Jason, J., Schoenwaelder, J.,
Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216,
December 2001.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Presuhn Expires August 2, 2008 [Page 24]
Internet-Draft Data Modeling Language Requirements January 2008
Management Workshop", RFC 3535, May 2003.
[RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
Structure of Management Information", RFC 3780, May 2004.
[RFC4506] Eisler, M., "XDR: External Data Representation Standard",
STD 67, RFC 4506, May 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
Appendix A. Acknowledgements
This members of the design team that produced this document were:
Martin Bjorklund
Sharon Chisholm
Alex Clemm
Rohan Mahy
Chris Newman
David Partain
Randy Presuhn
Many of the ideas gathered here were extracted from discussions held
at various IETF meetings and on IETF mailing lists.
The members of the design team would also like to thank those who
have provided helpful comments on earlier versions of this memo:
David Harrington
Eric Rescorla
Appendix B. Use Cases
The use cases presented here were chosen to illustrate requirements
which proved contentious or were not agreed by the members of the
design team or otherwise needed clarification. For requirements
which were not contentious, we did not specifically devise use cases.
B.1. Multi-Version Scenarios
The following discusses typical deployment scenarios behind backwards
and forewords requirements.
B.1.1. Tightly Coupled
This is the simplest case. This is where the application which
manages the device is upgraded at the same time as the devices and
Presuhn Expires August 2, 2008 [Page 25]
Internet-Draft Data Modeling Language Requirements January 2008
only needs to worry about managing a single version of a single type
of network element. Tightly coupled solutions can be costly and
impractical, so are not a realistic solution to the problem of
version management.
B.1.2. Loosely Coupled - Support Matrix
It is more typical that a single application is required to support
different types of network elements and often more than one version
of that network element. A support window of the current version and
some set of older versions is commonly assumed. It should be
possible to support multiple versions of the same schema with as few
changes to application code (including data-driven configuration) as
possible.
B.1.3. Forwards Compatibility
There are a number of reasons that the management application might
not be upgraded when network elements are upgraded, including being
developed by a third party releasing on a different cadence. In this
case, the earlier version of the management application should be
able to continue to provide the same level of support against the
newer versions of the schema as it did in the older version.
B.1.4. Mixed-Mode Forwards and Backwards Compatibility
In mixed mode, different network elements, all supporting different
versions of the schema are present. There are also different
applications in the network, which each support different versions of
the schema.
All the applications should be able to support all the versions of
the schema. As in the case of forwards compatibility, best effort
support will be provided.
B.1.5. Multiple Extensions
This case is the same as the mixed-mode case above, except that
different network element support zero, one or more extensions to the
model.
Appendix C. Example Instance Documents
The instance documents presented here are examples to illustrate
specific requirements or their possible consequences.
Presuhn Expires August 2, 2008 [Page 26]
Internet-Draft Data Modeling Language Requirements January 2008
Author's Address
Randy Presuhn (editor)
Retired
Email: randy_presuhn@mindspring.com
Presuhn Expires August 2, 2008 [Page 27]
Internet-Draft Data Modeling Language Requirements January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Presuhn Expires August 2, 2008 [Page 28]