Network Working Group Sandeep Adwankar Internet-Draft Motorola, Inc. Expires: January 12, 2005 July 12 2004 NetConf Data Model draft-adwankar-netconf-datamodel-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. "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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" Abstract The NetConf protocol needs a way to represent the managed data on a device. This document provides a data model representation along with concrete realizations of system and interface managed objects. Adwankar Expires January 12, 2005 [Page 1] Internet Draft NetConf Data Model July 12, 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 2. The NetConf Managed Object Representation . . . . . . . . 3 3. The NetConf Data Model Features. . . . 6 4. Examples . . . . . . . . . . . . . 9 Appendix A. Data Model Survey 11 Appendix B. NetConf Data Model Schema 21 Appendix C. System Schema 26 Appendix D. Interfaces Schema 32 Adwankar Expires January 12, 2005 [Page 2] Internet Draft NetConf Data Model July 12, 2004 1. Introduction The NetConf protocol provides RPC-based mechanism for management operations using XML encoding. This document defines NetConf data model schema that is common across all NetConf implementations and provide constructs to represent managed objects. Each managed object definition will extend and use the NetConf data model schema. The NetConf data model schema is based on the XML Schema specification. Appendix A provides a brief survey of data models of few management protocols. Based on the survey, it can be concluded that the NetConf Data Model should provide a representation standard for defining XML documents that describe managed data on a device. Such a representation mechanism should support strong type as well as constraints checking. It should allow use of regular expressions to set constraints. It should support reusable types and should allow one to create new types using inheritance. It should allow grouping elements to control the recurrence of managed data elements. The data model should allow support for partitioning managed data into multiple spaces, and should able to reference those. It should able specify content as being unique within a region. It should define types that can represent complex managed objects and its hierarchies. It should define constructs for describing access control associated with each managed object. It should allow referencing of complex managed objects. It should allow easy translation from NetConf representation of managed objects to any other standard or proprietary XML form. It should specify naming mechanism so that a managed object or collection of managed objects can be addressed. NetConf Data Model should allow easy migration from exising management system. 2 The NetConf Managed Object Representation The managed object tree provides a hierarchical tree structure to organize all available management objects in the device. Each managed object is represented by a node or collection of nodes. The NetConf Data Model Schema is provided in Appendix B. The managed object tree is represented as XML schema element as given below. Adwankar Expires January 12, 2005 [Page 3] Internet Draft NetConf Data Model July 12, 2004 The model Identity provides identity information such as last update, version number, organization, contact, description and revision history. The contact and revision information can occur multiple times in a model identity. A model identity element must occur only once in a managed object tree and must provide name and path of the root. All the nodes in the managed object tree must be addressed from the name or the path specified in the model identity. The MOTree is composed of one to unbounded number of node elements. Each node is represented by a recursive Node type that allows zero to unbounded number of nodes as its children. Each node must specify name and can optionally specify path from its parent node. Each node can specify information such as access control list, title, last update information and version number as shown below. A managed object must extend a NodeType to define a node. The extension of a NodeType allows specifying the type for the managed object value. This allows type and constraints checking of the managed object value. The extension of NodeType also allows specifying parent name, maximum access allowed on the managed object, status of the object and its description. Appendix B provides an example of data model that represents system. An example of a managed object element "sysDescr" representation is as below. Adwankar Expires January 12, 2005 [Page 4] Internet Draft NetConf Data Model July 12, 2004 The "sysDescr" managed object element extends NodeType defined in the "nc" namespace. This managed object must contain a value of type "DisplayString" defined in the "nc" namespace and is shown below. The managed object value cannot exceed 255 characters in length. The managed object has "system" as its parent. This is a fixed value indicating that if the element has a value, its value must be equivalent to the fixed value. The ParentName type as shown below does not allow empty or whitespace-only parent name. The "sysDescr" maximum access is limited to ReadAccess which is defined as set of five netconf protocol commands as shown below. The status of the "sysDescr" definition is current where status is defined as simple type with enumerated values of "current", Adwankar Expires January 12, 2005 [Page 5] Internet Draft NetConf Data Model July 12, 2004 "deprecated" or "obsolete" as shown below. The description of the "sysDescr" managed object is of type Description defined as below. 3. The NetConf Data Model Features ACL: Example of ACL with get access provided to everyone. SystemDescription /netconf/system/sysDescr * System Description 2004-07-12T09:30:47-05:00 1 system Adwankar Expires January 12, 2005 [Page 6] Internet Draft NetConf Data Model July 12, 2004 current Example of ACL with get access provided to everyone and replace operation to manager http://example.com/manager SystemContact /netconf/system/sysContact * http://example.com/manager System Contact 2004-07-12T09:30:47-05:00 1 system current Object Grouping: Adwankar Expires January 12, 2005 [Page 7] Internet Draft NetConf Data Model July 12, 2004 Compliance: Keys: 4. Examples NetConf Request: //if:ifTable/if:ifEntry[if:ifIndex/@if:value='1'] Adwankar Expires January 12, 2005 [Page 8] Internet Draft NetConf Data Model July 12, 2004 NetConf Reply: NetConf Request: //sys:system[sys:sysName/@sys:value="MyName"] NetConf Reply: Adwankar Expires January 12, 2005 [Page 9] Internet Draft NetConf Data Model July 12, 2004 References [1] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 59, RFC 2579, April 1999. [3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 60, RFC 2580, April 1999. [4] 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. [5] Distributed Management Task Force standards (DMTF) http://www.dmtf.org/standards [6] The SyncML Device Management Tree and Description Version 1.1.2 Open Mobile Alliance Ltd. December 2003 [7] OASIS Web Services Distributed Management (WSDM) http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm Author's Address Sandeep Adwankar Motorola 1301 East Algonquin Rd, MS IL02-2240, Schaumburg, IL 60196 USA EMail: sandeep.adwankar@motorola.com Adwankar Expires January 12, 2005 [Page 10] Internet Draft NetConf Data Model July 12, 2004 Appendix A. Data Model Survey Structure of Management Information (SMI) The Structure of Management Information (version 2 is the current version), [1] [2] [3] is a specification for creating a management information base (MIB). The SMI identifies the permissible data types and spells out the rules for naming and identifying MIB components. It defines the structure of the SNMP naming mechanism. The SNMP SMI uses a subset of Abstract Syntax Notation One (ASN.1) and can represent simple data types such as scalars and two-dimensional arrays of scalars. Encoding Objects in the MIB are encoded using the basic encoding rules (BER) associated with ASN.1. A typical BER encoding is based on the use of a type-length-value structure. Addressing All managed objects are arranged in hierarchical or tree structure and associated with each type of object is a unique identifier of type OBJECT IDENTIFIER (OID). E.g. OID of internet node is defined as internet OBJECT IDENTIFIER ::={iso(1) org(3) dod(6) 1} MACRO SMI defines ASN.1 MACRO definitions that allows describing container for managed objects, object definitions and notification definitions. Module Identity Object Definitions: Each object is defined using an OBJECT-TYPE an ASN.1 MACRO shown in syntax that specifies the data type of the object, its allowable forms and value ranges and its relationship with other objects within MIB. SMI also defines new macros for defining object groups, traps, compliance characteristics and capability characteristics SMI defines application wide scaler types such as IpAddress, Counter32, Gauge32, Unsigned32, TimeTicks, Opaque, Counter64. It defines BIT construct, which represents an enumeration of named bits. SMI allows definition of a tabular structure on an ordered collection of objects within the MIB using SEQUENCE OF . refers to the SEQUENCE type of its subordinate conceptual row. Textual Conventions The TEXTUAL-CONVENTION macro allows defining new types that are available to all MIB modules. They provide precise semantics and convenience for human-readability. Type Representation DisplayString Textual information PhysAddress Media- or physical-level addresses MacAddress 802 MAC address Adwankar Expires January 12, 2005 [Page 11] Internet Draft NetConf Data Model July 12, 2004 TruthValue Boolean Value TestAndIncr Integer-valued information used for atomic operations value supplied via the management protocol is tested before incrementing by one AutonomousType Extensible type identification InstancePointer Pointer to either a specific instance of a MIB object or a conceptual row of a MIB table VariablePointer A pointer to a specific object instance RowPointer A pointer to a conceptual row RowStatus Status of a conceptual row e.g. active, notInService, createAndGo, destroy TimeStamp Time since a specific occurrence happened. TimeInterval Period of time DateAndTime A date-time specification StorageType memory realization of a conceptual row e.g. volatile, nonVolatile, permanent, readOnly TDomain kind of transport service TAddress Transport service address Compliance The MODULE-COMPLIANCE macro is used to convey a minimum set of requirements with respect to implementation of one or more MIB modules. It uses OBJECT-GROUP macro that defines a collection of related managed objects. Agent Capabilities The Agent Capabilities macro allows defining set of capabilities present in an agent. The example below shows that the SNMP Agent supports SNMPv2 MIB and implements MIB groups identified in the INCLUDES clause. snmpAgent AGENT-CAPABILITIES PRODUCT-RELEASE "SNMP Agent V2.4" STATUS current DESCRIPTION "SNMP Agent" SUPPORTS SNMPv2-MIB INCLUDES { systemGroup, snmpGroup, snmpSetGroup, snmpBasicNotificationsGroup } Notification Notification Macro is used to define the information contained within an unsolicited transmission of management information. The OBJECTS clause in Notification Macro defines an ordered sequence of MIB object types. Every instance of the notification should contain only one object instance for each occurrence of each object type in the specified order. An example of System group that provides general information about the managed system is shown below system OBJECT IDENTIFIER ::= { mib-2 1 } sysDescr OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-only Adwankar Expires January 12, 2005 [Page 12] Internet Draft NetConf Data Model July 12, 2004 STATUS current DESCRIPTION "A textual description of the entity. This value should include the full name and version identification of the system's hardware type, software operating-system, and networking software." ::= { system 1 } 2 Structure of Policy Provisioning Information (SPPI) The Structure of Policy Provisioning Information (SPPI) [4] defines the adapted subset of Structure of Management Information (SMI) used to specify policy information. The policy information can be exchanged from policy servers (Policy Decision Point or PDP) to network devices (Policy Enforcement Points or PEPs) using Common Open Policy Service protocol for policy provisioning (COPS-PR). The SPPI is used to write Policy Information Base (PIB) modules. The SPPI uses the term Provisioning Class (PRC) for the managed object table and row definitions, and Provisioning Instance (PRI) for an instantiation of a row definition. For a columnar object of a table definition, the SPPI uses the term "attribute" of a Provisioning Class. The SPPI does not support the equivalent of the SMI's scalar objects. The PIB name space is common to both the PEP and the PDP and data instances within this space are unique within the scope of a given Client-Type and Request-State per TCP connection between a PEP and PDP. If a device implements multiple COPS Client-Types, a unique instance space is to be provided for each separate Client-Type. There is no sharing of instance data across the Client-Types implemented by a PEP, even if the classes being instantiated are of the same type and share the same instance identifier. The SPPI extends SMI's MODULE-IDENTITY macro to convey the semantics of a PIB module. The SUBJECT-CATEGORIES clause identifies one or more categories of provisioning data for which this PIB module defines provisioning information. The SPPI uses SMI's modified OBJECT-TYPE macro to convey the syntax and semantics of PRCs and their attributes. It uses SMI's OBJECT-GROUP and MODULE-COMPLIANCE macros to specify acceptable lower-bounds of implementation of the attributes of PRCs. The SPPI uses SMI's TEXTUAL CONVENTION macro to define following additional data types that are common to several attributes of one of more PRCs. Type Representation InstanceId Instance-identifying index of a PRC ReferenceId Reference an instance of a particular PRC Prid Pointer to a PRI TagId Tag value. All instances of a particular PRC Adwankar Expires January 12, 2005 [Page 13] Internet Draft NetConf Data Model July 12, 2004 having the same tag value form a tag list TagReferenceId Reference to a tag list of instances of a particular PRC The SPPI defines types Integer64, Unsigned64 that are not defined in SMI. The SPPI does not use SMI's notification definitions. The SPPI does not define MAX-ACCESS clause as part of its OBJECT-TYPE macro and instead mandates that PIB-ACCESS clause must be present for a PRC's table definition. The PIB-ACCESS clause defines what kind of access is appropriate for the PRC. Thus the value "install" as shown in example below indicates that a PDP can install the particular PRC in the PEP as provisioning information. qosIfDscpAssignTable OBJECT-TYPE SYNTAX SEQUENCE OF QosIfDscpAssignEntry PIB-ACCESS install STATUS current DESCRIPTION " " ::= { qosIfParameters 9 } The value "notify" indicates a PRC for which the PEP must notify the PDP of all its instances and attribute values of that PRC. The PIB-INDEX clause defines identification information for instances of the PRC. The PIB-INDEX clause includes exactly one descriptor. This descriptor specifies an attribute, which is used to identify an instance of that PRC. The syntax of this attribute is InstanceId. The OBJECT IDENTIFIER, which identifies an instance of a PRC is formed by appending one sub-identifier to the OID which identifies that PRC's row definition. The value of the additional sub-identifier is that instance's value of the attribute specified in the INDEX clause. The UNIQUENESS clause lists a set of zero or more of the PRC's attributes, for which no two instances of the PRC can have the same set of values as shown in example below. qosIfDscpAssignEntry OBJECT-TYPE SYNTAX QosIfDscpAssignEntry STATUS current DESCRIPTION "An instance of the qosIfDscpAssign class." PIB-INDEX { qosIfDscpAssignPrid } UNIQUENESS { qosIfDscpAssignName, qosIfDscpAssignRoles } ::= { qosIfDscpAssignTable 1 } The PIB-TAG clause is used to indicate that this attribute references a "tag list" of instances of another PRC. Such a tag list is formed by all instances of the other PRC which have the same (tag) value of a particular attribute of that other PRC. Adwankar Expires January 12, 2005 [Page 14] Internet Draft NetConf Data Model July 12, 2004 3 Common Information Model The Common Information Model (CIM) [5] specification is the language and methodology for describing management data. The CIM is based on an object-oriented model. A Schema is composed of group of classes with a single owner. Each CIM class is a blueprint for a type of managed element. Classes contain properties, which describe the data of the class, and methods, which describe the behavior of the class. The schema in which it belongs scopes a class. A class must belong to only one schema and the class name must be unique for that schema. The CIM schema is combination of core and common models, where the core model captures notions that are applicable to all areas of management. The Common Models are information models that capture notions that are common to particular management areas, but independent of any particular technology or implementation. Examples of common models include systems, applications, networks and devices. Extension schemas represent technology-specific extensions of the common models. The Meta Schema is a formal definition of the model. The Unified Modeling Language (UML) is used to define the structure of the meta schema. The graphical forms use UML diagrams and are not normative. The textual forms are normative and written in a language based on the Interface Definition Language called the "Managed Object Format" (MOF). Example of CIM_ManagedElement class in MOF language is shown below. [Abstract, Version ("2.7.0"), Description ( "ManagedElement is an abstract class that provides a common "superclass (or top of the inheritance tree) for the" "non-association classes in the CIM Schema.") ] class CIM_ManagedElement { [MaxLen (64), Description ( "The Caption property is a short textual description (one-" "line string) of the object.") ] string Caption; [Description ( "The Description property provides a textual description of " "the object.") ] string Description; [Description ( " A user-friendly name for the object. ..") ] string ElementName; }; Each declaration in the MOF can be preceded by metadata enclosed in brackets. The CIM_ManagedElement class declaration is preceded by metadata enclosed in bracket that indicates that the managed element class is abstract and provides a description of the class. Adwankar Expires January 12, 2005 [Page 15] Internet Draft NetConf Data Model July 12, 2004 Different qualifiers can be declared for different data types and declarations. Thus the MaxLen qualifier for caption CIM_ManagedElement will limit the length to 64 characters. Encoding The xmlCIM Encoding Specification defines XML elements, written in Document Type Definition (DTD), which can be used to represent CIM classes and instances. The DTD fragment of Object definition elements is as below. ... CIM messages are encoded in XML such that each CIM message is described completely in XML. CIM Clients, CIM Servers or CIM Listeners are not required to validate received CIM Message Response or CIM Message Request. The encapsulation exposes key CIM message information in headers to allow efficient firewall/proxy handling. The information is limited to that which is considered essential, in order not to have significant impact on the size of the Header. No CIM-specific information appears in a Header that does not also appear within the CIM message. Addressing Instances of a class are addressed by designating one or more properties with the reserved qualifier "key" provide instance identification. For example, as shown in Figure 13 the class has one property (Volume) which serves as its' key. Thus instances of Drive are distinguished using the Volume property, which acts as the key for the class. Compound keys are supported and are designated by marking each of the required properties with the key qualifier. Adwankar Expires January 12, 2005 [Page 16] Internet Draft NetConf Data Model July 12, 2004 class Acme_Drive { [key] string Volume; string FileSystem; sint32 Capacity; }; A CIM object manager (CIMOM) is a database for instances of CIM classes. CIMOMs represent the central point for accessing management resources. 4 Device Description Framework (DDF) The SyncML DM specifies device description framework (DDF) [6] that prescribes a way for device vendors to describe their devices. The DDF root element is management tree root node having one or more nodes, where each node element is recursive i.e. it make contain one or more node. Each management tree node has name, path URI to the node, default value, run time properties and description framework properties. Description Framework Properties The description framework properties as shown below are not explicit at run-time in a device. Property Explanation Read/Write Device support AccessType Specifies which commands Read MUST are allowed on the node. DefaultValue The node value used in Read MAY a device unless specifically set to a different value. Description The human readable Read MAY description of the node. DFFormat The data format of the Read MUST described node. Occurrence Specifies the number of Read MAY instances Scope Specifies whether this is Read MAY a permanent or dynamic node. DFTitle The human readable name of Read MAY the node. DFType For leaf nodes, the MIME type Read MUST of the node value.For interior nodes, a DDF document name or empty The node description property scope defines whether the node is permanent or dynamic. A management server cannot create or delete permanent nodes at runtime while dynamic nodes can be created and deleted at runtime. The AccessType DF property can be used to protect dynamic nodes from deletion. The node will be deleted even if the AccessType DF property excludes Delete if the node is part of subtree that is being deleted. A DDF description of "Man" Adwankar Expires January 12, 2005 [Page 17] Internet Draft NetConf Data Model July 12, 2004 (Manufacturer Name) management tree node is shown below. 1.1.2 Man ExampleCompany A Unique Example Company The name of the device manufacturer. text/plain ... RunTime Properties The run time properties as shown below can change at run-time and are optional within its parent element node. Property Explanation Read/Write Device support ACL Access Control List Read & Write MUST Format Specifies how node Read MUST values should be interpreted Name The name of the node Read & Write MUST in the tree Size Size of the node Read MUST for leaf value in bytes nodes MUST NOT for interior nodes Title Human readable name Read & Write MAY TStamp Time stamp, date and Read MAY time of last change Type The MIME type of Read MUST the node's value VerNo Version number, Read MAY automatically incremented at each modification Each node is associated with a MIME type that determines the kind of management actions that can be performed on the node. A node with runtime format property set to "node" is Interior node and it Adwankar Expires January 12, 2005 [Page 18] Internet Draft NetConf Data Model July 12, 2004 has zero or more children. Nodes that are not interior nodes are leaf nodes. Each item in a management command is associated with Meta information containing format and type that correspond directly to data content in the node. The management command Add can be performed on interior nodes only. Access Control The Access Control List (ACL) runtime property is the only property that inherits ACL from parent nodes if it not explicitly specified. Example of ACL that allows changing node value to server identifier ACME and allows getting value to all other management servers is "Replace=www.ACME.com&Get=*" . A server identifier having Replace access rights according to node ACL can change the ACL value for interior nodes but same is not true for leaf nodes. A server identifier with sufficient access to parent node can change ACL of child node. Addressing Mechanism The SyncML DM defines a management tree of nodes and a unique full device URI addresses each node. Traversal Management servers can traverse through device management tree using GET commands. The Get on an interior node will return a list of all child node names. The properties of each node can be accessed by appending ?prop= to the node's URI. Thus ACL for node xyxInc can be accessed with following URI ./SyncML/DMAccounts/xyzInc?prop=ACL 5 Web Services Distributed Management (WSDM) WSDM [7] is in the process of defining web services architecture and technology to manage distributed resources and the model of a web service as a manageable resource. Managers establish the endpoint that provides manageability for a given Web service endpoint and manage the web service endpoint. The manager can retrieve metadata such as display Name, Metrics/Counters of requests/replies/faults, service state information such as UP/DOWN and time since last state change. It can request configuration control and has startup/shutdown capability. The manager can also get notifications against service state and notifications against request processing. Addressing Addressing is to reference the web services of a manageability provider, or, to reference a manageable resource. The data structure as shown below holds sufficient information for a manageability consumer to locate the Web service and to exchange messages with the Web service. xs:anyURI ... ? Adwankar Expires January 12, 2005 [Page 19] Internet Draft NetConf Data Model July 12, 2004 xs:QName ? xs:QName ? ... * Capabilities Many manageability capabilities of a manageable service concern the resource the manager is able to query and set. This information is modeled as a set of properties as shown in example below. By using a property schema, it is possible to find, to read, and to write a property. A property is part of the advertised manageability interface for a resource. For manageability, a property can represent configuration values, metrics, identifiers etc. Notification Notification provides mechanism for manageable resources to convey information to the managers. In certain cases, it is unreasonable for the manager to explicitly poll (request) the information, and it has to be sent to the manager by the manageable resource. The manageable resource for the service may have to notify the manager when the event occurs. The manageable resource needs to know which manager is interested in which information and the address (es) of Adwankar Expires January 12, 2005 [Page 20] Internet Draft NetConf Data Model July 12, 2004 the manager in order to send a notification message whenever an event occurs. A NotificationProducer can send the Notify message as shown in Figure 19 to the NotificationConsumer in order to deliver one or more NotificationMessage(s). {any} ? wsa:EndpointReference xsd:any + Appendix B. NetConf Data Model Schema The NetConf Data Model definition Adwankar Expires January 12, 2005 [Page 21] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 22] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 23] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 24] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 25] Internet Draft NetConf Data Model July 12, 2004 Appendix C. System Schema Adwankar Expires January 12, 2005 [Page 26] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 27] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 28] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 29] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 30] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 31] Internet Draft NetConf Data Model July 12, 2004 Appendix C. Interfaces Schema Adwankar Expires January 12, 2005 [Page 32] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 33] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 34] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 35] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 37] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 39] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 40] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 41] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 42] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 43] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 44] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 45] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 46] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 47] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 49] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 51] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 52] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 53] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 54] Internet Draft NetConf Data Model July 12, 2004 Adwankar Expires January 12, 2005 [Page 55] Internet Draft NetConf Data Model July 12, 2004 "Copyright (C) The Internet Society (year). 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 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." Adwankar Expires January 12, 2005 [Page 56]