Internet DRAFT - draft-alexan-datamod

draft-alexan-datamod






Network Working Group                                       M. Alexander
Internet-Draft                                                   WU-Wien
Intended status: Standards Track                          March 22, 2007
Expires: September 23, 2007


            NE/Facilities/Lines/Protocols/Services Modeling
                      draft-alexan-datamod-00.txt

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 September 23, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Alexander              Expires September 23, 2007               [Page 1]

Internet-Draft                Data Modeling                   March 2007


Abstract

   This draft presents a framework document for modeling network
   elements (NE), facilities, lines, protocols and services for
   substantially easing development and operation of element manager
   systems (EMS), network management systems (NMS) and operations
   support systems (OSS).  The framework is independent of the access
   method used, including SNMP, CLI, Netconf, Corba, CMIP, XML-RPC,
   etc.)  It covers configuration, alarms, current-historical
   performance, accounting management and security.  The frameworks
   builds on and reuses the existing base of MIBs.  The documents
   presents a light-weight, structured and very simplified framework and
   method to data modeling for defining and maintaining meta models,
   device etc. models, and device etc. descriptors.


Table of Contents

   1.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Backward Compatibility . . . . . . . . . . . . . . . . . . . .  9
   5.  Independence from Access Methods . . . . . . . . . . . . . . . 10
   6.  Core Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Secondary Scope  . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Items NOT in Scope . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Dependencies-Requirements on Others  . . . . . . . . . . . . . 15
   10. Process-Cycle Time . . . . . . . . . . . . . . . . . . . . . . 16
   11. Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   14. Normative References . . . . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

















Alexander              Expires September 23, 2007               [Page 2]

Internet-Draft                Data Modeling                   March 2007


1.  Requirements Notation

   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].














































Alexander              Expires September 23, 2007               [Page 3]

Internet-Draft                Data Modeling                   March 2007


2.  Problem Statement

   Network Management (NM) standards have traditionally been focused on
   protocols, such as pertaining to configuration management and
   discovery.  Yet, all areas of Network Management, ranging from
   Element Management (EM) to Network Management Systems (NMS) and
   Service Management Systems have in common that they critically rely
   on underlying data structures describing devices and services being
   managed.  Network elements (NE) frequently spawn ten thousands of
   managed objects, such as for a multiservice switch.

   In a common fallacy, programmatic access methods towards an NE such
   as operations on attributes via SNMP, CLI or XML-Netconf etc. are
   frequently taken as equating to 'network management'.  Yet, in order
   for a Craft Terminal/EMS/NMS/Service Management System to provide
   sensible services to either a GUI operator or a mechanized interface,
   the device data of an NE has to be in a structured model.  Managed
   objects alone - but in rare cases - do not allow to provision a
   subscriber, retrieve an alarm, examine a performance metric etc.
   From e.g. an NMS viewpoint, they tend to be 'flat' data structures
   which need to be put into a defined structure the NMS can understand
   so to perform any logical flow of actions on them.  That is, a "flat"
   device attribute list does not enable an operator or mechanized
   interface to manage an NE.  Unfortunately, there is little
   commonality in data models, respectively managed objects exposed by
   NEs to their northbound interfaces.  Even worse, the plethora of NMS/
   Service Managers each have their own models, leading to the present-
   day situation in which a large set of management systems with
   different models map to a large set of NEs with - differing models,
   both of which ever changing.

   The following comparison highlights the problem from an
   implementation-effort perspective: It takes an experienced NM person
   about a year to understand a medium-complexity carrier device's data
   model in its entirety.  This familiarity is necessary to build EMSs/
   NMSs/Service Management Systems with human-operable GUIs, or machine-
   to-machine interfaces for high-level operations (enable a service/
   disable a service etc.).  To adapt a given NMS's model for only one
   NM constituent, such as configuration management, the effort to
   initially map and then maintain the NE's to the NMS's data model is
   vast.  For example, only to cover configuration management of a
   single service of a multi-service switch man-years of effort may be
   necessary to match the two models.

   Yet in contrast, the effort to effect an attribute value change with
   SNMP, CLI or XML- Netconf etc. even with little prior knowledge of a
   device's functionality, model and behavior is comparatively
   minuscule.  Setting a given NE attribute via a prompted CLI may take



Alexander              Expires September 23, 2007               [Page 4]

Internet-Draft                Data Modeling                   March 2007


   an NM-person with only rudimentary knowledge of a given device
   minutes; SNMP, depending on the design of the MIB takes longer,
   similarly for XML or CORBA etc.  Comparing the discrepancy in the
   distribution of efforts again: the implementation of one leg of NM
   tends to be measured in man-years, the second leg of device access
   may range from man-hours to man-weeks.  Logically, one might suppose
   that standards development would match this distribution.

   Traditionally, standardization of access-methods (protocols),
   discovery, etc. have received most attention, while the more
   heterogeneous data models and data modeling per saw comparatively
   less.  As there are real possibilities to standardize underlying and
   universal commonalities in EMS/NMS/Service Management Systems on the
   one side and managed attributes of NEs, protocols, transmission
   facilities, lines and services on the other, the two distributions
   should be closer aligned.  Despite the complexity, it is possible to
   identify and define frameworks and meta models of each constituent
   and their relation to each other, that would substantially ease the
   management of present and future devices, networks and services.

   The problem was recognized early, but it took time until technologies
   such as markup languages, with their key property of being human
   readable, reached the mainstream and ubiquity: "Although some
   positive sentiment was expressed for defining a kind of "super SMI"
   metalanguage to aid in the definition of a general API, it was not
   clear whether the current crop of supporting protocols had sufficient
   semantic commonality to be used in this way.  The matter remains open
   for investigation."  [Vince Cerf, RFC 1109]























Alexander              Expires September 23, 2007               [Page 5]

Internet-Draft                Data Modeling                   March 2007


3.  Use Cases

   The framework addresses the following use cases:

   o  Design and Implementation of EMSs

   o  Design and Implementation of NMSs

   o  Design and Implementation of OSSs

   o  Design and Implementation of Northbound and Southbound Interfaces

   EMSs and NMSs are composed of the following main components: access
   to NEs, data model and database (a special case being '"MIB-less"
   managers with limited modeling and no database), NE-logic to augment
   NE methods or define new ones using entities from the NE's exposed
   management functionality, application logic, presentation logic,
   besides security and system functions at al.

   Over the mission-life of an EMS/NMS/OSS/SMS, the component that
   consumes a majority of design and development resources is the data
   models and their implementation.  This applies to single - NE/Service
   managers as well as multi NE-type or service managers where the
   efforts to initially define and stay current with the respective NE/
   service versions increases non-linearly.  In some cases point-of-
   diminishing returns in multi-NE EMSs, at large due to NE model
   differences.  They result in more and more device- specific
   adaptations and shortcuts to the EMS's own meta model or in the
   manager's application logic leading to eventually highly complex and
   time-consuming coverage of additional devices and releases.

   EMS/NMS are the more usable the more depth the NEs models have.  In a
   polar extreme, an EMS with a GUI that only offers a human operator a
   flat representation of an NE data structure, requires a fair amount
   of device/device model/device behavior knowledge on part of this
   human operator.  If, however, the device model is detailed, an EMS
   can e.g. give the human operator a detailed view of the node, being
   able to drill down from e.g. a shelf view down to management
   information of given protocol running on a given port.

   Covering a new NE with e.g. 2000 managed objects based on an
   "average" MIB model in an existing EMS with pre-existing related
   coverage takes -- depending on the granularity scope -- on the lower-
   end several manyears.  People doing the device integration have to
   build a well-structured, multi-level model of the device in the EMS
   so for the EMS to be easy to use for a human operator.

   If the device MIB does not adequately convey the NE behavior, the



Alexander              Expires September 23, 2007               [Page 6]

Internet-Draft                Data Modeling                   March 2007


   facility hierarchy and interrelation of objects and their attributes,
   the effort can be substantially higher.  The modeler(s) adding
   support for a particular device to an EMS may have to (re) model the
   equipment's hierarchy and discover its behavior through (lengthy)
   series of experiments.

   If, in contrast, if there is data model than conveys managed objects
   in a normative way and there is a normative namespace/meta model,
   then the task becomes substantially easier.  If, in addition, the
   device model specifies rules and equipment behavior in at least a
   semi-normative way, then high-depth support for the particular device
   becomes attainable in a fraction of the time than having to go from
   plain MIBs.

   Similarly, if the task were to build a prompted CLI for the device,
   the main effort would be create a definition file that specifies the
   CLI hierarchy levels and which operations would be permissible at a
   given level -- a formidable task for a large MIB.  In contrast, if
   there is a namespace/meta model in conjunction with a device data
   model that is based on a device class model, then the prompted CLI
   (but of the application logic) could to a large extend be derived or
   generated from the models.

   The same goes for building NMSs, which allow for drilling down into
   lines and devices.  Yet, NMSs in addition require alarm templates.
   Creating alarm templates involves in depth knowledge of the
   equipment's behavior, if it has not been properly abstracted.
   Creating alarm templates for root-cause analysis involving multiple
   devices without pre-existing models is highly time and resource
   intensive, possibly involving multiple testing cycles.  The proposed
   approach for simplifying alarm modeling is: an alarm meta model as
   part of the namespace/meta model and an alarm template class model as
   part of the device/service/protocol class model.

   Not a use case per se is the necessity to uniquely locate equipment,
   facilities, lines and their termination points in a network.  If a
   large number of network elements are involved, then they should be
   put into inventory using a schema which incorporates at least a
   unique serial, a unique product ID bound to the vendor partnumber,
   vendor partnumber, the container equipment (for e.g. cards), the
   organization's location classification (such as country/city/
   location/room), a unique serial and dating.  There needs to be a meta
   model for inventory codes and schemata for the individual types of
   inventory.  The binding between the equipment type categories and the
   unique serial could be done based on a normative registry, similar to
   the binding between domains and IP address in DNS.

   Implementing EMSs/NMSs/CLIs and OSS interfaces are different use



Alexander              Expires September 23, 2007               [Page 7]

Internet-Draft                Data Modeling                   March 2007


   cases from the creation of device models.  Provided a namespace/and
   class-type meta models for the device exist, individual vendors can
   model their own devices or charter 3rd parties to do so, thereby
   allowing a wide range of NMS/OSS software to recognize and manage
   their devices.  They could be cataloged and put into a repository,
   and be bound against the various (vendor dependent) unique serials
   from the last paragraph.












































Alexander              Expires September 23, 2007               [Page 8]

Internet-Draft                Data Modeling                   March 2007


4.  Backward Compatibility

   MIBs are the most common data structure for internal device data
   representation.  MIBs are also the most common non-proprietary EMS/
   NMS/OSS data representations.  The investment in them is vast, hence
   it should be preserved.  Therefore, backward compatibility with MIBs
   SHALL be preserved.  Existing MIBs need to be covertable ("import")
   into the new set of DM models.  This can be done in two ways: (a) the
   could be converted into an applicable regular namespace, or (b) into
   a free form variant not having the property of a direct line to a
   common root.  Reverse imports of DM Models into MIBs is not feasible.
   MIB conversion does not have to use a generative approach.  While it
   may be possible to write converters that do not take manual
   intervention, in order to produce (b), or a converter that takes
   conversion directives embedded or references in the MIB source, this
   approach will not yield well-structured models for (a).  In order to
   convert existing MIBs into the new namespaces and models derived from
   the new meta models, partially automated/facilitated/tools supported
   manual conversion will be necessary.
































Alexander              Expires September 23, 2007               [Page 9]

Internet-Draft                Data Modeling                   March 2007


5.  Independence from Access Methods

   Data Models need to be independent of access methods; Talking to a
   device via SNMP, a CLI, Netconf, CORBA, XML-RPC, Batch Config
   Transfer, etc. is relatively insignificant in time/resources relative
   to designing-implementing-maintaining data models.  For example, a
   clean data model of a 5000 managed objects device can be talked to in
   ANY of the above access methods provides the device has an agent that
   exposes the objects.

   The ratio of efforts between adapting an EMS/NMS/OSS to talk to a
   particular device access method protocol agent to refining an
   "average" MIB data model approaches 0 the more complex a devices is.






































Alexander              Expires September 23, 2007              [Page 10]

Internet-Draft                Data Modeling                   March 2007


6.  Core Scope

   The core initial focus includes a set of meta models, an initial
   network type focus, and service focus.  Prior to that, a set of
   initial namespaces such as for the ones below is necessary:

   o  Base equipment hierarchy (rack::power::supplies::shelf::slot::
      port::facility::protocols ::services

   o  Base network types: IP, SDH SONET, ATM, Ethernet

   The proposed initial network type focus is: IP-Routing, Ethernet,
   SDH/SONET and ATM.  The proposed initial services to model are:
   barebones SIP, Ethernet VLANs, DiffServ (as a service in the models).

   Prerequisite to model network types or services are a set of meta
   models shown in Figure 1 below:

   The respective layers are explained in the following.

   +-----------+------------------------------------------------------+
   | Layer VII |   Device/Line/Service/Protocol Instance              |
   +-----------+------------------------------------------------------+
   | Layer VI  |   Device/Line/Service/Protocol Model                 |
   +-----------+------------------------------------------------------+
   | Layer V   |   Device/Line/Service/Protocol Type Meta Model       |
   |           |     Derived from class model                         |
   |           |     Captures behavior, rules                         |
   +-----------+------------------------------------------------------+
   | Layer IV  |   Device/Line/Service/Protocol Class Meta Model      |
   |           |     Alarm template class model                       |
   +-----------+------------------------------------------------------+
   | Layer III |   Namespaces/Meta Model                              |
   |           |     Derived from existing CLI (option?),from scratch |
   |           |     Constructs etc.                                  |
   |           |     Alarm template meta model                        |
   +-----------+------------------------------------------------------+
   | Layer II  |   Object Model                                       |
   |           |     Prototype methods-operations, data types         |
   +-----------+------------------------------------------------------+
   | Layer I   |   Access Method                                      |
   |           |     SNMP, CLI, Netconf, CMIP, CORBA, XML-RPC, SOAP .. |
   +-----------+-----------------------------------------------------+

                                 Figure 1

   Layer I (Access Method) is the protocol used to talk to the NE.  As
   emphasized before, in the existing status-quo given different data



Alexander              Expires September 23, 2007              [Page 11]

Internet-Draft                Data Modeling                   March 2007


   models on the device and on the manager, the effort to code the NE
   communication with a given protocol is relatively low compared to
   refining the respective manager models to match that of the device.
   I.e. is the access methods offers sufficient operations to act on a
   given managed object, the choice of protocol may be a matter of other
   criteria.

   Layer II (Object Model) defines the base primitives including
   operations that can effect managed objects.  A superset of data types
   should also be defined in this layer.

   Layer III (Namespaces/Meta Model) is (a) concerned with the naming
   hierarchies (namespaces) for devices/lines/services and protocols.
   For example, part of the base equipment hierarchy from before (rack::
   power::supplies::shelf::slot::port::facility) would form a namespace.
   The meta model is (b) the prototype model for the higher layer
   device/line/service/protocol {Class Meta Model, Type Meta Model,
   Model and Instance}.  That is, it integrates the object model and the
   namespaces and provides a framework model for the higher layers and
   defines constructs, language they can utilize.  In addition, a meta
   model for alarm templates needs to be defined at this layer.

   Layer IV (Device/Line/Service/Protocol Class Meta Model) defines meta
   models for classes of e.g. devices.  An example for classes of
   devices are Routers, Ethernet switches, or ATM switches.  In the same
   layer, alarm template class models (deriving from the alarm template
   model on Layer III) need to be defined in order to support root-cause
   alarming with a high degree of accuracy.

   Layer V (Device/Line/Service/Protocol Class Type Model) extends the
   Layer IV Class Meta Model.  It defines types of device-line/service/
   protocols further.  For example, the class routers might branch into
   routing switches, pure IP routers, multi-protocol routers, access
   routers, edge routers, core routers, etc.  Furthermore, the layer
   suits defintions of rules and attributes describing the equipment
   type's behavior.

   Layer VI (Device/Line/Service/Protocol Model) extends the type meta
   model with information that is particular to a specific device/line/
   service/protocol.  For devices, this might be a specific product or
   product range in case of an equipment vendor.  For services, it might
   be a service as deployed by a specific operator.

   Layer VII (Device/Line/Service/Protocol Instance) is the actual
   instance of the e.g. device model which could be a data model for a
   particular vendor's device at a given release level.





Alexander              Expires September 23, 2007              [Page 12]

Internet-Draft                Data Modeling                   March 2007


7.  Secondary Scope

   The secondary scope follows in sequence after the initial scope,
   largely because of dependencies.  It includes:

   o  Unique equipment/line locators

   o  Alarm template registries

   o  Protection, failover modeling (1+1, 1:n, 1:1, etc.)

   o  Device/service/protocol models to be defined in the respective
      areas/WGs

   Unique equipment/line locators have been discussed before as a use
   case.  As indicated, a schema which incorporates at least a unique
   serial, a unique product ID bound to the vendor partnumber, vendor
   partnumber, the container equipment, the organization's location
   classification (such as country/city/location/room), a unique serial
   and dating is necessary.  This needs to be in conjunction with a meta
   model for inventory codes and schemata for the individual types of
   inventory.  The binding between the equipment type categories and the
   unique serial could be kept in a public database similar to a
   registry.

   Along the same lines, (a) registry(ies) could be formed for alarm
   templates.  The secondary scope also includes protection, failover
   modeling (1+1, 1:n, 1:1, etc.), which involves a revision of all
   metamodels.  At the 2nd stage in the effort, it could also be trialed
   that individual areas/ working groups define their device/service/
   protocol models independently, based on the underlying meta models.




















Alexander              Expires September 23, 2007              [Page 13]

Internet-Draft                Data Modeling                   March 2007


8.  Items NOT in Scope

   The data model SHALL NOT include support for Business Support Systems
   (BSS) and workflow in general.  It is SHALL NOT attempt to cover all
   aspects of enterprise and carrier network operations.














































Alexander              Expires September 23, 2007              [Page 14]

Internet-Draft                Data Modeling                   March 2007


9.  Dependencies-Requirements on Others

   There are no hard requirements on other efforts.  One item, for which
   there exists a workaround, would be good to have at the earliest
   point though is a Netconf RPC call in-line with the DM object model
   (layer II): Netconf 1.0 presently allows for free-form RPC calls.
   The DM effort and anybody involved in EMS/NMS/OSS modeling would in
   general greatly benefit if devices were to expose more high-level
   functions/methods.  For example, instead of having to set a large
   number of attributes in order to provision a customer on a given
   port, a method provision_customer() exposed by the NE, described in
   the data model and called by the EMS/NMS/OSS would greatly reduce
   complexity.  Having a formalized method call which is congruent with
   the object model might induce more vendors to expose simplified
   methods in their devices.

   Elegant integration of management information into protocol
   specifications natural gets much easier for protocol designers if
   Protocol Class Meta Model is available.  Once this is the case,
   individual working groups outside the OPS area should be able to
   define their own protocol models.  Hence, there is a depency from
   them on the availability of the meta models.





























Alexander              Expires September 23, 2007              [Page 15]

Internet-Draft                Data Modeling                   March 2007


10.  Process-Cycle Time

   The complexity for DM is significantly higher than for many protocols
   (e.g. not TCP though).  A high initial rate of changes in the
   specifications is expected until steady-state is reached.  Still,
   even in steady-state a comparatively large number of changes per
   revision is expected to be occuring in the regular update cycle.

   Branches of the models outside the main modeling effort will need to
   be allowed.  Here, the process might become to fold normative schema
   extensions into main as much as possible, allowing of private
   branches and allowing specialization without folding.

   The target time for the first iteration of the initial scope is one
   year.  The projected cycle times are:

   o  Device/Line/Service/Protocol Instances: on discretion of
      equipment/nm vendors

   o  Device/Line/Service/Protocol Model: initial: 6 months, steady-
      state 6 months, synced with protocols

   o  All meta models: initial: 6 months, steady-state 8-9 months

   o  Object model and data types: initial: 6 months, steady-state 3-4
      years or longer

























Alexander              Expires September 23, 2007              [Page 16]

Internet-Draft                Data Modeling                   March 2007


11.  Open Issues

   Three issues are not addressed in the present draft: Rules language,
   metamodel language and the issue of state model inclusion and
   language.

   While good data modeling uses overspecification (which facilitates
   device modeling), the immediate benefit from the inclusion of a state
   model and a state model specification language is lower than for the
   core namespaces and metamodels.  Once at least the primary scope has
   completed, the addition of state model information would aid the EMS/
   NMS/OSS modeler in further codifying the equipment's behavior,
   facilitating tasks such as deciding on the sequence when to issue
   operations and with timing issues in general.

   Similarly, rules could be specified in a separate rules language,
   which could be added at a later point.  The issue is different,
   however, for a metamodel language.  Having a full language for it
   would greatly increase expressivity.  Introducing a metamodel
   language at a different time than from the onset is not a good option
   though.






























Alexander              Expires September 23, 2007              [Page 17]

Internet-Draft                Data Modeling                   March 2007


12.  Security Considerations

   The framework goes beyond assuming both the management stations and
   the NEs being in secure networks.  The Meta models SHALL include both
   authentication and multi-level authorization which to be defined in
   separate drafts.  The frameworks covers both, manging of NEs
   providing security functionality, and the authentication and
   authorization of the NEs per se.











































Alexander              Expires September 23, 2007              [Page 18]

Internet-Draft                Data Modeling                   March 2007


13.  Acknowledgements

   The author would like to acknowledge inputs in the form of drafts,
   comments, discussions etc. from the following people: David Appel,
   Ray Atarashi, Jan Bergkvis, Andy Bierman, Ron Bonica, Sharon
   Chisholm, David Harrington, Robert Natale, Hideki Okita, Amy
   Pendleton, Dan Romascanu, Juergen Schoewaelder, Henning Schulzrinne,
   Thomas Stolz, Iijima Tomoyuki and Margot Wasserman.











































Alexander              Expires September 23, 2007              [Page 19]

Internet-Draft                Data Modeling                   March 2007


14.  Normative References

   [RFC1109]  Cerf, V., "Report of the second Ad Hoc Network Management
              Review Group", RFC 1109, August 1989.

   [RFC1155]  Rose, M. and K. McCloghrie, "Structure and identification
              of management information for TCP/IP-based internets",
              STD 16, RFC 1155, May 1990.

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,
              "Simple Network Management Protocol (SNMP)", STD 15,
              RFC 1157, May 1990.

   [RFC1212]  Rose, M. and K. McCloghrie, "Concise MIB definitions",
              STD 16, RFC 1212, March 1991.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
              December 2006.



























Alexander              Expires September 23, 2007              [Page 20]

Internet-Draft                Data Modeling                   March 2007


Author's Address

   Michael Alexander
   Wirtschaftsuniversitaet Wien
   Augasse 2-6
   Vienna  1090
   Austria

   Phone: +43.1.31336.4467
   Email: malexand@wu-wien.ac.at









































Alexander              Expires September 23, 2007              [Page 21]

Internet-Draft                Data Modeling                   March 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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).





Alexander              Expires September 23, 2007              [Page 22]