Network Working Group R. Presuhn, Ed.
Internet-Draft Retired
Intended status: Informational January 27, 2008
Expires: July 30, 2008
Requirements for a Configuration Data Modeling Language
draft-presuhn-rcdml-00
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 July 30, 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 July 30, 2008 [Page 1]
Internet-Draft Data Modeling Language Requirements January 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Taxonomy of Requirements . . . . . . . . . . . . . . . . . . . 4
2.1. Consequences of Netconf . . . . . . . . . . . . . . . . . 4
2.1.1. Notification Support . . . . . . . . . . . . . . . . . 5
2.1.2. Notification Definition #13 (Agreed) . . . . . . . . . 5
2.1.3. Notification Get #14 (NOT Agreed) . . . . . . . . . . 5
2.1.4. Define Actions (NOT Agreed) . . . . . . . . . . . . . 5
2.1.5. Locking #53 (Agreed) . . . . . . . . . . . . . . . . . 5
2.1.6. All Base Operations #56 (Agreed) . . . . . . . . . . . 5
2.1.7. Define new NETCONF Operations #60 (Agreed) . . . . . . 5
2.1.8. Separation of Operations and Payload #75 (Agreed) . . 5
2.2. Model Representation Requirements . . . . . . . . . . . . 5
2.2.1. Human Readable #3(Agreed) . . . . . . . . . . . . . . 6
2.2.2. Machine Readable #2 (Agreed) . . . . . . . . . . . . . 6
2.2.3. Textual Representation #18 (Agreed) . . . . . . . . . 6
2.2.4. Language Versioning Rules #35 (Agreed) . . . . . . . . 6
2.2.5. Document Information #34 (Agreed) . . . . . . . . . . 6
2.2.6. Ownership and Change Control #31 (Agreed) . . . . . . 6
2.2.7. Dependency Risk Reduction (Agreed) . . . . . . . . . . 6
2.2.8. Diff-Friendly #17 (Agreed) . . . . . . . . . . . . . . 6
2.2.9. Internationalization and Localization . . . . . . . . 6
2.2.10. Model Equivalence #42 (NOT agreed) . . . . . . . . . . 7
2.3. Reusability Requirements . . . . . . . . . . . . . . . . . 7
2.3.1. Modularity #20 (Agreed) . . . . . . . . . . . . . . . 7
2.3.2. Reusable Types #46 (Agreed) . . . . . . . . . . . . . 8
2.3.3. Reusable Definitions #30 (Agreed) . . . . . . . . . . 8
2.3.4. Modular extension #22 (Agreed) . . . . . . . . . . . . 8
2.4. Instance Data Requirements . . . . . . . . . . . . . . . . 8
2.4.1. Reference Pointers #7 (Agreed) . . . . . . . . . . . . 8
2.4.2. Default Values on the Wire (Agreed) . . . . . . . . . 8
2.4.3. Ordering . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.4. Validation . . . . . . . . . . . . . . . . . . . . . . 9
2.4.5. No Mixed Content #64 (Agreed) . . . . . . . . . . . . 10
2.4.6. Instance Canonicalization #69 (Agreed) . . . . . . . . 10
2.4.7. Character Set and Encoding (Agreed) . . . . . . . . . 10
2.4.8. Model Instance Localization (NOT Agreed) . . . . . . . 10
2.5. Semantic Richness Requirements . . . . . . . . . . . . . . 10
2.5.1. Human-Readable Semantics (Agreed) . . . . . . . . . . 10
2.5.2. Error Annotation #16 (Agreed) . . . . . . . . . . . . 10
2.5.3. Basic Types #45 (Agreed) . . . . . . . . . . . . . . . 11
2.5.4. Handling Opaque Data #50 (Agreed) . . . . . . . . . . 11
2.5.5. Handling Non-Opaque Data #51 (NOT Agreed) . . . . . . 11
2.5.6. Keys . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.5.7. Simple Relationships . . . . . . . . . . . . . . . . . 11
2.5.8. Determine Schema Equivalence #42 (NOT Agreed) . . . . 12
2.5.9. Configuration Data and Beyond . . . . . . . . . . . . 12
Presuhn Expires July 30, 2008 [Page 2]
Internet-Draft Data Modeling Language Requirements January 2008
2.5.10. Defaults . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.11. Formal Constraints . . . . . . . . . . . . . . . . . . 13
2.6. Extensibility Requirements . . . . . . . . . . . . . . . . 14
2.6.1. Language Extensibility . . . . . . . . . . . . . . . . 14
2.6.2. Model Extensibility . . . . . . . . . . . . . . . . . 14
2.6.3. Instance Data Extensibility . . . . . . . . . . . . . 15
2.7. Talking About Conformance . . . . . . . . . . . . . . . . 15
2.7.1. Conformance to the Modeling Language #74 (NOT
Agreed) . . . . . . . . . . . . . . . . . . . . . . . 15
2.7.2. Conformance to a Model #11 (Agreed) . . . . . . . . . 16
2.8. Techno-Political Constraints . . . . . . . . . . . . . . . 16
2.8.1. Standard Technology #1 (NOT Agreed) . . . . . . . . . 16
2.8.2. Translate Models to Other Forms #47 (Agreed) . . . . . 17
2.8.3. Minimize SMI Translation Pain #33 (NOT Agreed) . . . . 17
2.8.4. Generate Models from Other Forms #49 (NOT Agreed) . . 17
2.8.5. Isolate Models from Protocol #29 (NOT Agreed) . . . . 17
2.8.6. Library Support #39 (NOT Agreed) . . . . . . . . . . . 17
2.8.7. RFC 3139 Considerations . . . . . . . . . . . . . . . 17
2.8.8. RFC 3216 Considerations . . . . . . . . . . . . . . . 17
3. Requirement Interactions . . . . . . . . . . . . . . . . . . . 17
4. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Conformance to the Modeling Language . . . . . . . . . . . 18
4.2. Conformance to Schemas Defined Using the Modeling
Language . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. Client Conformance to Schemas . . . . . . . . . . . . 18
4.2.2. Server Conformance to Schemas . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Character Set Considerations . . . . . . . . . . . . . . . . . 18
7.1. Character Set Considerations for Human-Readable
Descriptions . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Character Set Considerations for Element Labels . . . . . 19
7.3. Character Set Considerations for Model-specific Error
Messages . . . . . . . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19
Appendix B. Use Cases . . . . . . . . . . . . . . . . . . . . . . 19
B.1. Multi-Version Scenarios . . . . . . . . . . . . . . . . . 20
B.1.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 20
B.1.2. Loosely Coupled - Support Matrix . . . . . . . . . . . 20
B.1.3. Forwards Compatibility . . . . . . . . . . . . . . . . 20
B.1.4. Mixed-Mode Forwards and Backwards Compatibility . . . 20
B.1.5. Multiple Extensions . . . . . . . . . . . . . . . . . 20
Appendix C. Example Instance Documents . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Presuhn Expires July 30, 2008 [Page 3]
Internet-Draft Data Modeling Language Requirements January 2008
1. Introduction
THIS IS A VERY PRELIMINARY VERSION OF THIS MEMO. 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 CUM GRANO SALIS, AND EXAMPLES AND USE CASES ARE
FRAGMENTARY AT BEST.
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 from the
Applications and the Operations and Management areas. This document
is that design team's product.
The principal goal of this document is to increase the chances for a
successful BOF in Philadelphia (IETF 71) aimed at deciding 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 existing requirements for data modeling languages
coming from the various teams working on new solutions or reusing
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. Taxonomy of Requirements
2.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. Others relate more to the
information that NETCONF is managing.
Presuhn Expires July 30, 2008 [Page 4]
Internet-Draft Data Modeling Language Requirements January 2008
2.1.1. Notification Support
2.1.2. Notification Definition #13 (Agreed)
The solution should support defining notifications.
2.1.3. Notification Get #14 (NOT Agreed)
The solution should support defining notifications in a way such that
the same definition can also be polled. (i.e., do a get on the
instance). Some use cases are data change notifications as well as
being able to store and send alarm definitions with the same
definition. Note this makes log records much easier as well and may
simplify access control.
2.1.4. Define Actions (NOT Agreed)
The solution should provide a way to define specific actions to be
performed. Note that this is distinct from adding new operations
types to the protocol.
2.1.5. Locking #53 (Agreed)
The solution MUST NOT preclude fine grained locking. Make sure the
implications are understood.
2.1.6. All Base Operations #56 (Agreed)
It MUST be unambiguous how NETCONF [RFC4741] base operations work
with data defined under a model produced using the solution.
2.1.7. Define new NETCONF Operations #60 (Agreed)
The solution SHOULD 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.
2.1.8. Separation of Operations and Payload #75 (Agreed)
If the solution provides a means for defining new NETCONF operations,
it should allow a clear separation between data model definitions and
the definition of new NETCONF operations.
2.2. Model Representation Requirements
Presuhn Expires July 30, 2008 [Page 5]
Internet-Draft Data Modeling Language Requirements January 2008
2.2.1. Human Readable #3(Agreed)
The solution MUST support a human-readable representation of data
models.
2.2.2. Machine Readable #2 (Agreed)
The solution MUST support a machine-readable representation of data
models.
2.2.3. Textual Representation #18 (Agreed)
The solution MUST support definitions which are text-based. 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.
2.2.4. Language Versioning Rules #35 (Agreed)
The language itself MUST be versioned.
2.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,
contact, and so on.
2.2.6. Ownership and Change Control #31 (Agreed)
It MUST be clear who owns the data modelling framework, e.g., the
IETF.
2.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.
2.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.
2.2.9. Internationalization and Localization
There are several requirements associated with issues related to
languages and character sets.
Presuhn Expires July 30, 2008 [Page 6]
Internet-Draft Data Modeling Language Requirements January 2008
2.2.9.1. Descriptions using Local Languages #19 (Agreed)
The solution MUST be able to support the use of Unicode text in to
provide human readable descriptions of information semantics in a
model definition. This is effectively required by [RFC2277].
2.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 include description in the
model definer's language of choice.
2.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].
2.2.9.4. Error String Localization #66 (Agreed)
The solution MUST NOT preclude localization of error strings for user
display.
2.2.9.5. Tag Names and Strings in Local Languages #67 (NOT agreed)
The solution SHOULD be able to 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.
2.2.10. Model Equivalence #42 (NOT agreed)
It should be possible to test the equivalence of model definitions,
even if they are not textually identical.
2.3. Reusability Requirements
2.3.1. Modularity #20 (Agreed)
The solution MUST provide a means to define data models in discrete
pieces.
Presuhn Expires July 30, 2008 [Page 7]
Internet-Draft Data Modeling Language Requirements January 2008
2.3.2. Reusable Types #46 (Agreed)
The solution MUST provide a means to define reusable types.
2.3.3. Reusable Definitions #30 (Agreed)
The solution MUST support a way to reuse definitions from another
model. An example of such a capability is IMPORTS.
2.3.4. Modular extension #22 (Agreed)
It should be possible to extend a data model without modifying the
existing models.
2.4. Instance Data Requirements
This section contains specific requirements on what an instance
document for a model defined using the solution should look like.
2.4.1. Reference Pointers #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. Should support 1-1 and 1-many relationships.
2.4.2. 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 prescriber behavior.
2.4.3. Ordering
The requirements in this section could use a better re-factoring.
Terminological cleanup would also help.
2.4.3.1. Disordered Lists #32 (NOT Agreed)
Support the ability to send child elements in a container in any
order. (This is ambiguous. Does it mean that it should be possible
to pick any arbitrary order, and specify that that is the order to
use, or does it mean that the order of elements in a list is
specified to not be deterministic, or does it merely mean that the
order of elements has no semantic significance?)
Presuhn Expires July 30, 2008 [Page 8]
Internet-Draft Data Modeling Language Requirements January 2008
<card>
<name>
<colour>
</card>
New Requirement (of instances of the same element)
<card>1</card>
<card>2</card>
(someone needs to explain what the heck this means)
2.4.3.2. Disorder Lists #62 (NOT Agreed)
Support the ability to specify that child elements in a list will be
sent in any order. (The only difference from the previous item is
"specify" rather than "send".)
2.4.3.3. Ordered Lists #61 (NOT Agreed)
Support the ability to send child elements in a list in strict order.
(Is the intent that the order should be semantically significant?)
2.4.3.4. Ordered Lists #63 (NOT Agreed)
Support the ability to specify that child elements in a list will be
sent in a strict order. (The only difference from the previous item
is "specify" rather than "send".)
2.4.3.5. Order Matters #71 (NOT Agreed)
It should be possible to specify whether order is semantically
significant. (Note there may be other reasons to order other than
semantics.)
2.4.3.6. Interleaving #48 (Agreed)
It should be possible to add new child elements anywhere in a list.
Inside a set of elements that do not have an inherent semantic order,
it should be possible to intermix new elements and existing elements
in any order underneath the common parent. (This could also belong
with the extensibility requirements.)
2.4.4. Validation
2.4.4.1. Validate Instance Data #40 (Agreed)
It should be understood how to make sure an instance of a data model
is well-formed and valid (in terms of the schema, etc.)
Presuhn Expires July 30, 2008 [Page 9]
Internet-Draft Data Modeling Language Requirements January 2008
2.4.4.2. Tools to Validate Instance Data #41 (NOT Agreed)
The solution should support a means of determining whether an
instance document is a valid instance of a model.
2.4.5. 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.
2.4.6. Instance Canonicalization #69 (Agreed)
The solution should support a canonicalized version of the instance.
This is a transform which can put the data in a form which is
suitable for comparison. This means that the rules for
canonicalization needs to be specified based on something like XML
digital signature specification. Common sense should be used to not
overdo it. This does not imply that there is any requirement for
data on the wire to be sent in canonicalized form. Details to be
determined later by working group.
2.4.7. 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.
2.4.8. Model Instance Localization (NOT Agreed)
Tags and other human-readable portions of an instance of a model
should be localizable.
2.5. Semantic Richness Requirements
2.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.
2.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.
Presuhn Expires July 30, 2008 [Page 10]
Internet-Draft Data Modeling Language Requirements January 2008
2.5.3. Basic Types #45 (Agreed)
The solution should define frequently used types. Note this can also
be done in the data model content.
2.5.4. Handling Opaque Data #50 (Agreed)
It should be possible to perform certain operations on opaque data.
This means that completely replacing the data should be supported,
but not merging, for example. This data potentially does not conform
to any schema definition, but is well-formed XML.
2.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.
2.5.6. Keys
2.5.6.1. Define Keys #6 (Agreed)
The solution should support defining keys to data (i.e. the
collection of fields which define uniqueness for an element or a
specially created identifier ala ifIndex or xml id.)
2.5.6.2. Deep Keys #54 (NOT Agreed)
The solution SHOULD support making keys from elements which are not
the immediate descendents of the element being "keyed".
Example...
<card>
<port>
</card>
What does this example show?
2.5.7. Simple Relationships
2.5.7.1. (NOT Agreed)
define reference pointers for 1:1 and 1:n relationships
2.5.7.2. Many-to-Many Relationships #8 (NOT Agreed)
The solution should support defining many to many cross reference
relationships.
Presuhn Expires July 30, 2008 [Page 11]
Internet-Draft Data Modeling Language Requirements January 2008
2.5.7.3. Retrieve Relationships #52 (NOT Agreed)
It should be possible to retrieve the data, including relationships
between elements. Relationships SHOULD be visible in instances. For
example, "this port is associated with card 12".
2.5.7.4. Referential Integrity #25 (NOT Agreed)
It should be possible to describe in the 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)
2.5.7.5. 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)
2.5.7.6. 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.
2.5.8. Determine Schema Equivalence #42 (NOT Agreed)
It should be possible to determine whether schemas are equivalent
even if they are not identical in the way they were defined.
2.5.9. Configuration Data and Beyond
2.5.9.1. Define Configuration Data #4 (Agreed)
The solution should be able to model configuration data.
2.5.9.2. Define Non-Configuration Data #5 (Agreed)
The solution should be able to model non-configuration data.
Presuhn Expires July 30, 2008 [Page 12]
Internet-Draft Data Modeling Language Requirements January 2008
2.5.9.3. Characterize Data #9 (Agreed)
The solution MUST support characterizing data definitions as
configuration or non-configuration. The solution MAY support further
characterization, such as identifying status or statistics.
2.5.10. Defaults
2.5.10.1. Default Values #10 (NOT Agreed)
The solution should support defining default values for elements. If
you do not specify this value when creating, the other end will
assume the value in the default. The solution should specify how
this feature interacts with backwards compatibility,
canonicalization. The solution should specify what conformance to
this means if you use a different default value.
2.5.10.2. Static Defaults #44 (NOT Agreed)
The solution must support static default values.
2.5.10.3. Dynamic Defaults #44 (NOT Agreed)
The solution must support dynamic default values.
2.5.11. Formal Constraints
2.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.
2.5.11.2. Multi-element Constraints #24 (NOT Agreed)
It should be possible to indicate constraints on an element which
involve another element of the configuration. If the value of an
MTU, for example depends on the ifType. (Additional cases:
dependency on some non-configuration data, such as presence of a
particular piece of hardware, or inter-system constraints.)
2.5.11.3. Non-Key Uniqueness #68 (Agreed)
It should be possible 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. For a model to be valid, must this constraint always
hold true? Or is it only required to be true at the time of creation
Presuhn Expires July 30, 2008 [Page 13]
Internet-Draft Data Modeling Language Requirements January 2008
or merger?
2.6. Extensibility Requirements
2.6.1. Language Extensibility
2.6.1.1. Language Versioning #35 (Agreed)
The modeling language itself should be versioned.
2.6.1.2. #21 (NOT Agreed)
It should be possible for the NETCONF server implementer to extend
the language. This means extensibility of the language by the user
of the data modeling language, to add new statements or functionality
to the language. {Randy wonders why it talks about "server
implementer". The server really doesn't even need to know the
modeling language exists.)
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.
2.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. [What is the scope of the error? How is it learned?]
2.6.1.4. Must-Understand Extensions #70 (NOT Agreed)
The solution should support defining language extensions which the
client must understand or otherwise error.
2.6.2. Model Extensibility
2.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.
2.6.2.2. # (NOT Agreed)
define interactions with defaults
Presuhn Expires July 30, 2008 [Page 14]
Internet-Draft Data Modeling Language Requirements January 2008
2.6.2.3. # (NOT Agreed)
define interactions with conformance
2.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.
2.6.3. Instance Data Extensibility
2.6.3.1. # (NOT Agreed)
The solution should provide a means to determine what schema version
was used to generate an instance document.
2.6.3.2. # (NOT Agreed)
define interactions with defaults
2.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.
2.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.
2.6.3.5. Must-Understand Extensions #77 (NOT Agreed)
The solution should support defining content extensions which the
client must understand or otherwise error. Adding mandatory objects
to an update to a Schema for example.
2.7. Talking About Conformance
2.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.
Presuhn Expires July 30, 2008 [Page 15]
Internet-Draft Data Modeling Language Requirements January 2008
2.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.
2.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.
2.7.2.2. Optional or Mandatory #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.
2.7.2.3. Optional and Mandatory Instance #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]
2.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.
2.7.2.5. (NOT Agreed)
model conformance: client
2.7.2.6. (NOT Agreed)
model conformance: server
2.8. Techno-Political Constraints
2.8.1. Standard Technology #1 (NOT Agreed)
The solution should leverage existing widely used language and tools
to define the content. [what is meant by "the content"?] Redefining
as little as possible the work that w3c and other relevant bodies
have already done.
Presuhn Expires July 30, 2008 [Page 16]
Internet-Draft Data Modeling Language Requirements January 2008
2.8.2. Translate Models to Other Forms #47 (Agreed)
The solution should support the ability to translate to Relax NG and
XML Schema. Any proposed solution will describe whether this
translation is lossy or lossless and if lossy, what information is
lost.
2.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.
2.8.4. Generate Models from Other Forms #49 (NOT Agreed)
The solution should support higher level modelling languages.
Translate from UML, for example. (Possible or existing tools?)
2.8.5. Isolate Models from Protocol #29 (NOT Agreed)
The data model 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.
2.8.6. Library Support #39 (NOT Agreed)
The solution should have wide support from development languages C,
etc.
2.8.7. RFC 3139 Considerations
expand into other categories from final table
2.8.8. RFC 3216 Considerations
expand into other categories
3. Requirement Interactions
4. Conformance
Presuhn Expires July 30, 2008 [Page 17]
Internet-Draft Data Modeling Language Requirements January 2008
4.1. Conformance to the Modeling Language
A solution MUST spell out what is meant by "conformance" to that
particular modeling language specification.
4.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 as particular model.
4.2.1. Client Conformance to Schemas
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
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.
4.2.2. Server Conformance to Schemas
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.
5. IANA Considerations
This document requires no action by IANA. Specifications based upon
these requirements will specify what, if any, IANA considerations are
appropriate.
6. Security Considerations
7. Character Set Considerations
Presuhn Expires July 30, 2008 [Page 18]
Internet-Draft Data Modeling Language Requirements January 2008
7.1. Character Set Considerations for Human-Readable Descriptions
7.2. Character Set Considerations for Element Labels
7.3. Character Set Considerations for Model-specific Error Messages
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
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003.
[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.
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.
Presuhn Expires July 30, 2008 [Page 19]
Internet-Draft Data Modeling Language Requirements January 2008
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
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
Presuhn Expires July 30, 2008 [Page 20]
Internet-Draft Data Modeling Language Requirements January 2008
model.
Appendix C. Example Instance Documents
The instance documents presented here are examples to illustrate
specific requirements or their possible consequences.
Author's Address
Randy Presuhn (editor)
Retired
Email: randy_presuhn@mindspring.com
Presuhn Expires July 30, 2008 [Page 21]
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 July 30, 2008 [Page 22]