Network Working Group R. Presuhn, Ed. Internet-Draft Retired Intended status: Informational February 15, 2008 Expires: August 18, 2008 Requirements for a Configuration Data Modeling Language draft-presuhn-rcdml-02 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 18, 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 18, 2008 [Page 1] Internet-Draft Data Modeling Language Requirements February 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 (Agreed) . . . . . . . . . . . 6 3.1.2. Notification Get (NOT Agreed) . . . . . . . . . . . . 6 3.1.3. Locking (Agreed) . . . . . . . . . . . . . . . . . . . 7 3.1.4. All Base Operations (Agreed) . . . . . . . . . . . . . 7 3.1.5. Define new NETCONF Operations (Agreed) . . . . . . . . 7 3.1.6. Separation of Operations and Payload (Agreed) . . . . 8 3.1.7. Error Annotation (Agreed) . . . . . . . . . . . . . . 8 3.1.8. No Mixed Content (Agreed) . . . . . . . . . . . . . . 8 3.2. Model Representation Requirements . . . . . . . . . . . . 8 3.2.1. Human Readable (Agreed) . . . . . . . . . . . . . . . 8 3.2.2. Machine Readable (Agreed) . . . . . . . . . . . . . . 9 3.2.3. Textual Representation (Agreed) . . . . . . . . . . . 9 3.2.4. Document Information (Agreed) . . . . . . . . . . . . 9 3.2.5. Ownership and Change Control (Agreed) . . . . . . . . 9 3.2.6. Dependency Risk Reduction (Agreed) . . . . . . . . . . 9 3.2.7. Diff-Friendly (Agreed) . . . . . . . . . . . . . . . . 9 3.2.8. Internationalization and Localization . . . . . . . . 9 3.3. Reusability Requirements . . . . . . . . . . . . . . . . . 11 3.3.1. Modularity (Agreed) . . . . . . . . . . . . . . . . . 11 3.3.2. Reusable Definitions (Agreed) . . . . . . . . . . . . 11 3.3.3. Modular extension (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. Instance Canonicalization (Agreed) . . . . . . . . . . 13 3.4.5. Character Set and Encoding (Agreed) . . . . . . . . . 13 3.4.6. Model Instance Localization (NOT Agreed) . . . . . . . 13 3.5. Semantic Richness Requirements . . . . . . . . . . . . . . 13 3.5.1. Human-Readable Semantics (Agreed) . . . . . . . . . . 13 3.5.2. Basic Types (Agreed) . . . . . . . . . . . . . . . . . 14 3.5.3. Handling Opaque Data (Agreed) . . . . . . . . . . . . 14 3.5.4. Keys . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5.5. Relationships . . . . . . . . . . . . . . . . . . . . 15 3.5.6. Hierarchical Data . . . . . . . . . . . . . . . . . . 16 3.5.7. Referential Integrity . . . . . . . . . . . . . . . . 16 3.5.8. Characterize Data (Agreed) . . . . . . . . . . . . . . 17 3.5.9. Defaults . . . . . . . . . . . . . . . . . . . . . . . 18 3.5.10. Formal Constraints . . . . . . . . . . . . . . . . . . 18 3.5.11. Units (Agreed) . . . . . . . . . . . . . . . . . . . . 19 3.5.12. Define Actions (NOT Agreed) . . . . . . . . . . . . . 20 3.6. Extensibility Requirements . . . . . . . . . . . . . . . . 20 Presuhn Expires August 18, 2008 [Page 2] Internet-Draft Data Modeling Language Requirements February 2008 3.6.1. Language Extensibility . . . . . . . . . . . . . . . . 20 3.6.2. Model Extensibility . . . . . . . . . . . . . . . . . 21 3.6.3. Instance Data Extensibility . . . . . . . . . . . . . 21 3.7. Talking About Conformance . . . . . . . . . . . . . . . . 22 3.7.1. Conformance to the Modeling Language (NOT Agreed) . . 22 3.7.2. Conformance to a Model (Agreed) . . . . . . . . . . . 22 3.8. Techno-Political Constraints . . . . . . . . . . . . . . . 24 3.8.1. Standard Technology (NOT Agreed) . . . . . . . . . . . 24 3.8.2. Translate Models to Other Forms (Agreed) . . . . . . . 24 3.8.3. Minimize SMI Translation Pain (NOT Agreed) . . . . . . 24 3.8.4. Generate Models from Other Forms (NOT Agreed) . . . . 24 3.8.5. Isolate Models from Protocol (NOT Agreed) . . . . . . 25 3.8.6. Library Support (NOT Agreed) . . . . . . . . . . . . . 25 3.8.7. RFC 3139 Considerations . . . . . . . . . . . . . . . 25 3.8.8. RFC 3216 Considerations . . . . . . . . . . . . . . . 25 4. Requirement Interactions . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 28 Appendix B. Use Cases . . . . . . . . . . . . . . . . . . . . . . 28 B.1. Multi-Version Scenarios . . . . . . . . . . . . . . . . . 28 B.1.1. Tightly Coupled . . . . . . . . . . . . . . . . . . . 29 B.1.2. Loosely Coupled - Support Matrix . . . . . . . . . . . 29 B.1.3. Forwards Compatibility . . . . . . . . . . . . . . . . 29 B.1.4. Mixed-Mode Forwards and Backwards Compatibility . . . 29 B.1.5. Multiple Extensions . . . . . . . . . . . . . . . . . 29 Appendix C. Example Instance Documents . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Presuhn Expires August 18, 2008 [Page 3] Internet-Draft Data Modeling Language Requirements February 2008 1. Introduction 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: 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 Presuhn Expires August 18, 2008 [Page 4] Internet-Draft Data Modeling Language Requirements February 2008 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] with its facilities for defining Textual Conventions [RFC2579] and conformance Statements [RFC2580]; 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]. While true protocol neutrality is a laudable goal in theory, the experience documented in the work-in-progress [I-D.schoenw-sming-lessons] shows that this property taken to its extreme can have negative consequences, even for very similar underlying information models. The design team recognizes that any effort like this will necessarily be incomplete, whether considered from the perspective of breadth or depth. The work-in-progress [I-D.linowski-netconf-dml-requirements] provides additional requirements along with their motivation. 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: Presuhn Expires August 18, 2008 [Page 5] Internet-Draft Data Modeling Language Requirements February 2008 1. Consequences of Netconf 2. Representation of Models 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. The notations "Agreed" and "NOT Agreed" merely indicate whether the members of the design team agreed that the requirement in question was an appropriate requirement to impose on solution candidates. In cases, requirements were not agreed to despite being adequately met by all the proposals of which the design team was aware. The "minimize SMI translation pain" requirement was an example of this. 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 are distinct from requirements driven by the NETCONF environment's information modeling needs. 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 (Agreed) The solution MUST support defining notifications. The solution MUST describe any transformations or adaptations necessary to transport notifications using the mechanisms defined in the work-in-progress [I-D.ietf-netconf-notification]. 3.1.2. Notification Get (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 is disagreement on just how Presuhn Expires August 18, 2008 [Page 6] Internet-Draft Data Modeling Language Requirements February 2008 much of a need there is for this kind of feature. Possible analogues which have been used to argue both for and against including this requirement include Syslog [RFC3164] and the SNMP Notification Log MIB [RFC3014]. There are three ways to define notifications: 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. One possibility might be to have a definition which consists simply of the binding of the notification semantic to whatever they payload container will be.) 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 than approaches (like that used in GDMO) which require the definition of an ad hoc notification syntax and a separate definition for the log record for each notification type, and that both the second and third options may simplify fine- grained access control, if that is required. 3.1.3. Locking (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.4. All Base Operations (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.5. Define new NETCONF Operations (Agreed) The solution MUST provide a means to define new NETCONF operations and their parameters (base, vendor extensions, and so on) in the same Presuhn Expires August 18, 2008 [Page 7] Internet-Draft Data Modeling Language Requirements February 2008 language as is used for defining models. One could argue that this is a layering violation, however there is a clear need for this function in the NETCONF space, and the members of the design team felt there was no particular advantage to requiring a separate mechanism. 3.1.6. Separation of Operations and Payload (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. This requirement exists to mitigate that apparent layering violation caused by the requirement to be able to define new NETCONF operations. 3.1.7. Error Annotation (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. The solution MUST describe how specific error strings are associated with error conditions as required by the NETCONF protocol. 3.1.8. No Mixed Content (Agreed) The solution MUST prevent mixed content, i.e., tags and data mixed together as part of a value, other than to treat it as opaque information. This requirement is a consequence of the NETCONF protocol environment. 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 which appeared in earlier versions of this memo, model canonicalization, straddles the border between this grouping and the group on model semantics. It was 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. However, the consensus of the design team was that this was not a requirement, so it was been removed. 3.2.1. Human Readable (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. Presuhn Expires August 18, 2008 [Page 8] Internet-Draft Data Modeling Language Requirements February 2008 3.2.2. Machine Readable (Agreed) The solution MUST support a machine-readable representation of data models. 3.2.3. Textual Representation (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. Document Information (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.5. Ownership and Change Control (Agreed) It MUST be clear who exercises change control and ownership over the data modeling framework, e.g., the IETF. This MUST also be clear for the technologies on which it depends. 3.2.6. 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.7. Diff-Friendly (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.8. 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. Presuhn Expires August 18, 2008 [Page 9] Internet-Draft Data Modeling Language Requirements February 2008 3.2.8.1. Descriptions using Local Languages (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.8.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. 3.2.8.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.8.4. Error String Localization (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.8.5. Tag Names and Strings in Local Languages (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. Presuhn Expires August 18, 2008 [Page 10] Internet-Draft Data Modeling Language Requirements February 2008 3.3. Reusability Requirements The reusability requirements could also be thought 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 (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 (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 (Agreed) It MUST be possible to extend a published data model without modifying the original data model. 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 18, 2008 [Page 11] Internet-Draft Data Modeling Language Requirements February 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 (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 significance might be a list of users. In cases where a list's order would have no semantic significance, the solution SHOULD nonetheless specify whether order is maintained, since this would affect instance data canonicalization. 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 (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. Presuhn Expires August 18, 2008 [Page 12] Internet-Draft Data Modeling Language Requirements February 2008 3.4.3.2. Tools to Validate Instance Data (NOT Agreed) A solution MAY provide a means of determining whether an instance document is a valid instance of a model. (The difference between the previous requirement and this one is that the former (agreed) merely requires that a solution is known, while the latter (not agreed) requires that a solution have been implemented.) 3.4.4. Instance Canonicalization (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.5. Character Set and Encoding (Agreed) The solution SHOUL 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.6. 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 transformed 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 18, 2008 [Page 13] Internet-Draft Data Modeling Language Requirements February 2008 3.5.2. Basic Types (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.3. Handling Opaque Data (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 data. In light of the negative experience with the opaque date type in SNMP, one might regard this requirement as a "necessary evil." 3.5.4. Keys The issues in this section all relate to the problem of uniquely identifying an entity in an instance of a model. A solution SHOULD spell out whether and how it supports creating models which permit instances which are not uniquely identified using keys. 3.5.4.1. Define Keys (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.4.2. Deep Keys (NOT Agreed) The solution SHOULD support using as a key the value of an element which is not an immediate descendant of the element being "keyed".
1.2.0.0
16 5.6.7.8 ... Here the desired key is constructed using both address and length. Though it could also have been be modeled with prefixAddress and Presuhn Expires August 18, 2008 [Page 14] Internet-Draft Data Modeling Language Requirements February 2008 prefixLength, doing so this would prevent reuse of the prefix data type. This example actually illustrates two distinct features: "deep" keys and compound keys. Support for one does not imply support for the other. 3.5.5. Relationships Issues discussed with respect to relationships included: o the tools available for modeling relationships in the solution; o the syntactic means available for representing relationships in configuration data; o the kinds of constraints on relationships that can be expressed in a model. On the issue of constraints, the design team found it helpful to consider them as conceptually belonging to various phases, characterized by the kind of information needed to determine whether a particular relationship was "valid" or not. Specifically: o constraints that could be enforced purely syntactically, as in the case, for example, of a foreign key (like ifIndex) being of the correct type; o constraints that could be evaluated in the context of a candidate configuration as it was "under construction"; o constraints requiring a "complete" candidate configuration to evaluate; o constraints requiring a running system to evaluate, such as a relationship to a physical piece of hardware; o constraints which can only be evaluated in a network context, such as a relationship to a peer entity on another system. It's important to note that these kinds of validation are far beyond what is normally understood as XML validation, but have been long- standing the practice in network management. 3.5.5.1. Simple Relationships (Agreed) The solution MUST 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 both 1:1 and 1:n relationships. 3.5.5.2. Many-to-Many Relationships (NOT Agreed) The solution SHOULD support defining many to many cross reference relationships. Presuhn Expires August 18, 2008 [Page 15] Internet-Draft Data Modeling Language Requirements February 2008 3.5.5.3. Retrieve Relationships instance (NOT Agreed) The solution SHOULD support a means of specifying relationships which can be represented in a configuration or on the wire with minimal redundancy. Knowledge of the model would be needed to transform this representation into a fully qualified instance identifier. The use of an integer interface index in a MIB, rather than a rowPointer [RFC2579], would be analogous to this capability. Ideally, the knowledge required to generate the fully qualified instance identifier would be present in the model in machine-readable form. 3.5.5.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.6. Hierarchical Data The solution MUST support defining data in hierarchies of arbitrary depth. This enables closer modeling of data to real world relationships, such as containment. 3.5.7. Referential Integrity The issues related to referential integrity can consume a significant amount of time. There are significant differences in expectation regarding what is meant by "referential integrity checking," and the following sub-sections reflect those differences. Presuhn Expires August 18, 2008 [Page 16] Internet-Draft Data Modeling Language Requirements February 2008 3.5.7.1. Referential Integrity (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). This kind of checking will not always be possible while a candidate configuration is under construction, since there may be cycles in relationships which prevent checking of an incomplete instance document. 3.5.7.2. Extended Referential Integrity (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.7.3. Referential Integrity Robustness (NOT Agreed) The solution SHOULD provide a means of indicating that the presence of data cross reference which cannot be verified, or which is known to not exist at the moment a configuration becomes the active configuration, is nonetheless not to be considered a configuration error. An example of a use case would be a relationship configured with respect to a hot-swappable component, which potentially can be absent from the system being configured when the configuration is made active. 3.5.8. Characterize Data (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 18, 2008 [Page 17] Internet-Draft Data Modeling Language Requirements February 2008 3.5.9. Defaults Discussion on IETF mailing lists as well as among the members of the design team has made it clear that there are many different ways of understanding "default" and correspondingly many different use cases. However, among the members of the design team, we were able to reach agreement that if a notion of "default" is to be at all useful in the context of configuration management, where knowing precisely what the configuration of a system is, and being able to bring the configuration of a system to a precisely known state are essential, "default"needs to be understood in terms of a binding contract between client and server. A consequence of this understanding of defaults would be to minimize their use in standardized definitions, since experience has shown that there are relatively few cases where a truly standard default is possible. Furthermore, vendor experience with defaults has shown that they can be problematic to versioning; what is an appropriate default in one version of a product might not make sense in a later release. Consequently, it might make sense to assume that if defaults are supported, their primary application would be as extensions to a model reflecting a particular implementation. 3.5.9.1. Default Values (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.9.2. Dynamic Defaults (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.10. Formal Constraints As with relationships, one way of conceptualizing the validation of formal constraints is to think of them in terms of what information is needed to determine whether a particular constraint is satisfied. Roughly, these are: Presuhn Expires August 18, 2008 [Page 18] Internet-Draft Data Modeling Language Requirements February 2008 o syntactic constraints determined by the base data type o range and pattern constraints which can be evaluated without considering any other configuration or status data o constraints which can be evaluated in terms of other information present in a candidate configuration, but which do not require that the complete configuration be present o constraints which can be evaluated in the context of a complete candidate configuration o constraints which require knowledge of non-configuration data expressed in the model o constraints which can only be evaluated in a running system o constraints which require knowledge of resources elsewhere in the network 3.5.10.1. Formal Description of Constraints (Agreed) It MUST 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.10.2. Multi-element Constraints (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.10.3. Non-Key Uniqueness (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. 3.5.11. Units (Agreed) The solution MUST provide a means of associating units with values, since unit errors in the configuration of values have potentially catastrophic consequences. Presuhn Expires August 18, 2008 [Page 19] Internet-Draft Data Modeling Language Requirements February 2008 3.5.12. Define Actions (NOT Agreed) The solution MAY provide a way to define specific actions to be performed. Here "actions" are understood as being associated with specific elements (objects) of information models. This requirement is distinct from the requirement to support the addition of new "operations", even though the two may be indistinguishable at the level of the protocol. If supported, the solution MUST describe how these are mapped into the NETCONF protocol. One of the motivations for this feature is the desire to avoid mapping action semantics onto data, as was necessary in the SNMP SMI [RFC2578]. The resulting "go buttons" proved unpopular. Another concern with this kind of feature is how to accommodate actions in a fine-grained access control framework, if one is ever developed. 3.6. Extensibility Requirements There are two broad categories of extensibility requirements: those having to do with the modeling language, and those related to the extensibility of models defined using that language. 3.6.1. Language Extensibility This section lists requirements concerned with the extensibility of the modeling language itself, rather than of models defined using that language. 3.6.1.1. Language Versioning (Agreed) The modeling language itself MUST be versioned. This requirement is motivated by the requirements for language extensibility below. 3.6.1.2. User Extensions (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: o standards evolution; o proprietary / vendor-specific annotations. Extensibility SHOULD be done in a way that unknown extensions MAY be ignored. 3.6.1.3. Mandatory Extensions (NOT Agreed) The solution SHOULD support defining language extensions which the client MUST understand; a client which does not understand one of Presuhn Expires August 18, 2008 [Page 20] Internet-Draft Data Modeling Language Requirements February 2008 these extensions MUST treat it as an error. It is unclear how this could be supported with the NETCONF protocol. It SHOULD be possible to label such language extensions as must-understand. If the extension is not understood, then an error is produced. It is unclear What the scope of the error would be, or how it would be learned. 3.6.2. Model Extensibility The requirements in this section concern the extensibility of specific models. 3.6.2.1. Model Version Identification (Agreed) Different versions of a given schema MUST 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 Interference (NOT Agreed) The solution SHOULD define how revising a model interacts with claims of conformance to its earlier versions, as well as what the impact is on claims for conformance to other models which have re-used definitions from the earlier version. 3.6.2.4. Obsolete Portions of a Model (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. Use cases for some of the requirements discussed in this section are described in Appendix B.1. 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. Presuhn Expires August 18, 2008 [Page 21] Internet-Draft Data Modeling Language Requirements February 2008 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 (Agreed) The solution MUST 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 (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 (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: 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 (NOT Agreed) A solution MUST spell out what is meant by "conformance" to that particular modeling language specification. This requirement is motivated by the need to evaluate whether or not a tool supports the chosen solution. 3.7.2. Conformance to a Model (Agreed) 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 Presuhn Expires August 18, 2008 [Page 22] Internet-Draft Data Modeling Language Requirements February 2008 "conformance" to a particular model, both from the perspective of a client implementation and of a server implementation. The solution SHOULD support indicating conformance requirements for a Schema. There is not a requirement that conformance requirements would be stated separately from the model 3.7.2.1. Conditional Conformance (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 (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 (NOT Agreed) The solution should support a method of indicating whether presence of an object is required in order to be a valid configuration. This has been explained as "mandatory to use (in a create) as NETCONF client as opposed to mandatory to implement on NETCONF server", but this explanation begs the question of what the server that doesn't implement the object is supposed to do with the create request in which the object is required to be present. 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. Presuhn Expires August 18, 2008 [Page 23] Internet-Draft Data Modeling Language Requirements February 2008 3.7.2.4. Versioned Conformance (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 (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 (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 (NOT Agreed) Minimize translation pain from SMI into NETCONF content. Translation of NETCONF content into SMI is not a consideration. Disagreement about this requirement stems from concern about the possibility that this might be interpreted as requiring the perpetuation of SMI-style models, rather than merely accommodating the basic types, as described in the work-in-progress [I-D.ietf-opsawg-smi-datatypes-in-xsd]. 3.8.4. Generate Models from Other Forms (NOT Agreed) The solution SHOULD support higher level modeling languages. An example would be generating configuration data models from UML descriptions. This requirement gets interesting regarding the question of whether anything needed in a network configuration data model might be impossible to represent in UML in machine-readable form. Presuhn Expires August 18, 2008 [Page 24] Internet-Draft Data Modeling Language Requirements February 2008 3.8.5. Isolate Models from Protocol (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 (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 feasibility 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 Numerous interactions are identified in conjunction with individual requirements. In general, the interactions between re-use, extensibility, and conformance demand special attention. 5. IANA Considerations This document requires no action by IANA. Specifications based upon these requirements will specify what, if any, IANA considerations are appropriate. Presuhn Expires August 18, 2008 [Page 25] Internet-Draft Data Modeling Language Requirements February 2008 6. 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. 7. References 7.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. 7.2. Informative References [I-D.ietf-netconf-notification] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", draft-ietf-netconf-notification-11 (work 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.ietf-opsawg-smi-datatypes-in-xsd] Natale, B. and Y. Li, "Expressing SNMP SMI Datatypes in XML Schema Definition Language", draft-ietf-opsawg-smi-datatypes-in-xsd-00 (work in progress), February 2008. [I-D.linowski-netconf-dml-requirements] Linowski, B., Storch, M., Ersue, M., and M. Lahdensivu, Presuhn Expires August 18, 2008 [Page 26] Internet-Draft Data Modeling Language Requirements February 2008 "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. [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 2000. [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. [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 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 Management Workshop", RFC 3535, May 2003. [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation Presuhn Expires August 18, 2008 [Page 27] Internet-Draft Data Modeling Language Requirements February 2008 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. Acknowledgments This members of the design team that produced this memo were: Martin Bjorklund Sharon Chisholm Alex Clemm Rohan Mahy Chris Newman David Partain Randy Presuhn The editor would like to thank everyone for the time, thought, and text they contributed to make this memo possible. 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: Andy Bierman Balasz Lengyel 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 forwards requirements described in Section 3.6.3. Presuhn Expires August 18, 2008 [Page 28] Internet-Draft Data Modeling Language Requirements February 2008 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 model. Presuhn Expires August 18, 2008 [Page 29] Internet-Draft Data Modeling Language Requirements February 2008 Appendix C. Example Instance Documents The instance documents presented here are examples to illustrate specific requirements or their possible consequences. 600 7200 10.254.240.0 22 10.254.240.10 10.254.240.230 10.254.240.1 10.254.240.2 US/Indiana Presuhn Expires August 18, 2008 [Page 30] Internet-Draft Data Modeling Language Requirements February 2008 1200 2008-10-10T08:00:00Z 2008-10-10T08:20:00Z 00:11:22:33:44:55 2008-10-10T08:04:22Z 2008-10-10T08:24:22Z 11:22:33:44:55:66 lo0 en2 10.17.224.0 24 10.17.224.10 10.17.224.250 Presuhn Expires August 18, 2008 [Page 31] Internet-Draft Data Modeling Language Requirements February 2008 10.17.224.1 example.org example.net 192.168.45.29 192.168.45.29,foo.example.com 10.0.29.0 24 10.0.29.10 10.0.29.230 10.0.29.1 Author's Address Randy Presuhn (editor) Retired Email: randy_presuhn@mindspring.com Presuhn Expires August 18, 2008 [Page 32] Internet-Draft Data Modeling Language Requirements February 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 18, 2008 [Page 33]