[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

Network Working Group                                        S. Chisholm
Internet-Draft                                                    Nortel
Expires: April 26, 2006                                      S. Adwankar
                                                                Motorola
                                                        October 23, 2005


                     Framework for Netconf Content
                  draft-chisholm-netconf-model-04.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 April 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This memo defines a framework for defining content for Netconf.  It
   defines requirements to enable interoperability, extensibility, easy
   parsing, usability and predictable modelling.







Chisholm & Adwankar      Expires April 26, 2006                 [Page 1]


Internet-Draft        Framework for Netconf Content         October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1   Definition of Terms  . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.1   Data Modelling Language  . . . . . . . . . . . . . . . . .  5
     2.2   Conformance  . . . . . . . . . . . . . . . . . . . . . . .  5
       2.2.1   Fine Grain Conformance . . . . . . . . . . . . . . . .  5
       2.2.2   Operations on Data . . . . . . . . . . . . . . . . . .  5
       2.2.3   Element Status . . . . . . . . . . . . . . . . . . . .  6
       2.2.4   Additional Conformance Information . . . . . . . . . .  6
       2.2.5   Backwards Compatibility  . . . . . . . . . . . . . . .  7
     2.3   Versioning . . . . . . . . . . . . . . . . . . . . . . . .  7
     2.4   Keys . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     2.5   Defining Relationships . . . . . . . . . . . . . . . . . .  8
       2.5.1   Associations Relationship  . . . . . . . . . . . . . .  9
     2.6   Defining Event Messages  . . . . . . . . . . . . . . . . . 10
     2.7   Considerations for Parse-ability . . . . . . . . . . . . . 11
       2.7.1   Well-formed XML  . . . . . . . . . . . . . . . . . . . 11
       2.7.2   No DTDs  . . . . . . . . . . . . . . . . . . . . . . . 11
     2.8   Use an Explicit Namespace on Attributes  . . . . . . . . . 12
     2.9   Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     2.10  Error Messages . . . . . . . . . . . . . . . . . . . . . . 12
     2.11  Schema Documentation . . . . . . . . . . . . . . . . . . . 13
     2.12  Specifying Statistics, Status and Configuration
           Information  . . . . . . . . . . . . . . . . . . . . . . . 13
     2.13  Schema Identity Information  . . . . . . . . . . . . . . . 13
   3.  Modeling Considerations  . . . . . . . . . . . . . . . . . . . 15
     3.1   Data Types . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.2   Elements and Attributes  . . . . . . . . . . . . . . . . . 15
     3.3   Use Container Elements for Lists . . . . . . . . . . . . . 15
     3.4   Naming implications of using XPATH . . . . . . . . . . . . 16
       3.4.1   Proper Tag Names . . . . . . . . . . . . . . . . . . . 17
     3.5   Granularity of Data Model  . . . . . . . . . . . . . . . . 17
     3.6   Avoid Mixed Content  . . . . . . . . . . . . . . . . . . . 17
   4.  Summary and Example  . . . . . . . . . . . . . . . . . . . . . 19
     4.1   Summary of Netconf Appinfo Elements & Attributes . . . . . 19
     4.2   XML Schema for Identity appInfo  . . . . . . . . . . . . . 20
     4.3   XML Schema for per element appInfo . . . . . . . . . . . . 20
     4.4   Managed Object Example . . . . . . . . . . . . . . . . . . 22
   5.  Relationship to Netconf Protocol . . . . . . . . . . . . . . . 26
     5.1   Merge Operation  . . . . . . . . . . . . . . . . . . . . . 26
     5.2   Replace Operation  . . . . . . . . . . . . . . . . . . . . 27
     5.3   Delete Operation . . . . . . . . . . . . . . . . . . . . . 28
     5.4   Create Operation . . . . . . . . . . . . . . . . . . . . . 29
     5.5   Get Operation  . . . . . . . . . . . . . . . . . . . . . . 30
     5.6   Get Operation with subtree filtering . . . . . . . . . . . 31
     5.7   Get All Operation  . . . . . . . . . . . . . . . . . . . . 31



Chisholm & Adwankar      Expires April 26, 2006                 [Page 2]


Internet-Draft        Framework for Netconf Content         October 2005


   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34
   A.  Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     A.1   Access Control . . . . . . . . . . . . . . . . . . . . . . 36
       A.1.1   Overview . . . . . . . . . . . . . . . . . . . . . . . 36
       A.1.2   Proposed Solution  . . . . . . . . . . . . . . . . . . 36
       Intellectual Property and Copyright Statements . . . . . . . . 38










































Chisholm & Adwankar      Expires April 26, 2006                 [Page 3]


Internet-Draft        Framework for Netconf Content         October 2005


1.  Introduction

   NETCONF [NETCONF-PROTO] can be conceptually partitioned into four
   layers:

                Layer                      Example
            +-------------+      +-----------------------------+
            |   Content   |      |     Configuration data      |
            +-------------+      +-----------------------------+
                   |                           |
            +-------------+      +-----------------------------+
            | Operations  |      | <get-config>, <edit-config> |
            +-------------+      +-----------------------------+
                   |                           |
            +-------------+      +-----------------------------+
            |     RPC     |      |    <rpc>, <rpc-reply>       |
            +-------------+      +-----------------------------+
                   |                           |
            +-------------+      +-----------------------------+
            | Application |      |   BEEP, SSH, SSL, console   |
            |   Protocol  |      |                             |
            +-------------+      +-----------------------------+

   This document defines a framework for Netconf content.  This
   framework is intended to provide guidance for the creation of Netconf
   content for the purposes of enabling interoperability, extensibility,
   parse-ability and usability.

                                 Figure 1


1.1  Definition of Terms

   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 RFC 2119 [3].

   Element: An XML Element[XML].

   Managed Entity: A node, which supports netconf[NETCONF] and has
      access to management instrumentation.  This is also referred to as
      the netconf server.

   Managed Object: A collection of one of more Elements that define an
      abstract thing of interest.






Chisholm & Adwankar      Expires April 26, 2006                 [Page 4]


Internet-Draft        Framework for Netconf Content         October 2005


2.  Requirements

   This section describes some restrictions on Netconf content and the
   specifications that describe this content, which will increase
   interoperability between implementations and between different
   versions of a given implementation.

2.1  Data Modelling Language

   XML Schema should be used to define the XML-formatted data that will
   be transported via Netconf.

2.2  Conformance

   When defining netconf content, it is also necessary to define
   machine-readable conformance for that content.  The following are the
   requirements that have been identified for the conformance and
   compliance aspects of Netconf data models.  This conformance is
   defined for both the individual elements with the Schema, and' also
   for the entire schema.

   Conformance specifies not only whether to object must be supported,
   but also the level of access, read versus write for example that is
   minimally required

2.2.1  Fine Grain Conformance

   When defining elements, the "minOccurs" and "maxOccurs" tags MUST be
   used to specify whether that object is required to have a compliant
   schema.  When defining an attribute, the "use" tag must be used to
   define whether the attribute is required.

2.2.2  Operations on Data

   Operations that can be performed on data fall into one of the
   following equivalence classes: "Create", "Delete","Read", "Write",
   and "Execute".

   A value of "create" means it is possible to create new instances of
   this element using commands like the netconf <edit-config> or <copy-
   config> commands.  A value of "delete" means it is possible to
   destroy instances of this element using commands like the netconf
   <edit-config> , <copy-config> or <delete-config>  operations.  A
   value of "read" means that it is possible to view values of this
   element using commands like the  <get-config>, <get> or <event>
   operations.  A value of "write" means it is possible to modify an
   instance of this element using commands like the netconf <edit-
   config> or <copy-config>  commands.  A value of "execute" means that



Chisholm & Adwankar      Expires April 26, 2006                 [Page 5]


Internet-Draft        Framework for Netconf Content         October 2005


   there is a side effect execution such as rebooting that is
   permissible as a result of commands like the netconf  <edit-config>
   or a <copy-config> command or the ability to execute a commands like
   the  <lock>, <unlock> or <kill-session>  command.

   This memo introduces the appinfo element of "minAccess" and an
   optional one of "maxAccess" which contain a non-empty list of values.
   The "minAccess" element defines the set of operations that must be
   supported in order to claim compliance to this schema.  The
   "maxAccess" element contains the full set of operations that make
   operational sense for this object.  If not present, it assumes the
   same value as the minAccess tag.

   For example, a status object might have a "minAccess" of "read" but a
   "maxAccess" of "read write" to indicate that it must be possible to
   perform a get operation the status, but implementations could also
   allow configuration operations on it as well.  In the case of a
   statistic, both the "minAccess" and "maxAccess" might have values of
   "read".


         <nm:minAcces> <nm:read/> </nm:minAccess>
         <nm:maxAcces> <nm:read/> <nm:write/> </nm:maxAccess>



2.2.3  Element Status

   As a schema evolves, certain elements may become obsolete.  Simply
   deleting these from the Schema may be acceptable for elements that
   did not see implementation, but others will require a strategy to
   allow implementers to migrate away from the old elements.

   An optional appinfo element called "status" SHOULD be used to provide
   the status of the element.  When not present, it will assume a value
   of "current".  The other value of this object is "obsolete" which
   indicates that implementations should consider migrating away from
   this object and that its implementation is no longer required to be
   considered conformant.  Obsolete content is never removed from the
   document and its element name can never be re-used

           For example
           <nm:status> current </nm:status>


2.2.4  Additional Conformance Information

   Additional information about conformance should be specified using a



Chisholm & Adwankar      Expires April 26, 2006                 [Page 6]


Internet-Draft        Framework for Netconf Content         October 2005


   documentation tag.

   Examples of additional conformance information that may be useful to
   provide includes how implementations can specify specific exceptions
   to required conformance, dependencies between elements (in order to
   do A, you need to first do B) and conditional conformance (if BGP,
   then ...).

2.2.4.1  Schema Level Conformance

   In order to claim compliant Netconf content, all elements MUST
   conform to their given minOCcurs and maxOccurs definitions and all
   elements with a status of "current" and with a minOccurs greater than
   or equal to one MUST be supported.  In addition, all of the
   operations listed by the minAccess attribute MUST be supported.

2.2.5  Backwards Compatibility

   Backwards compatibility means that new versions of an XML Schema that
   defines Netconf Content can be rolled out in a way that does not
   break existing supporters.

   Changes introduced as a result of an update to an existing
   specification of Netconf content fall into three categories: new
   concept are added; existing concepts are changed; or existing
   concepts are obsoleted.  Adding new optional content or adding
   optional new content to the content of a component, such as a new
   enumeration in a list, are changes that maintain backwards
   compatibility.  Changing the meaning or semantics of existing
   content, restricting the content of an existing component, or adding
   or removing required components are changes that do not maintain
   backwards compatibility.  [Editor's Note: I think there is a way
   around that last one.  Stay tuned].

   If an update to an XML Schema is backwards compatibility, then it
   must use the same element name.  A new element name must be used when
   backwards compatibility is not possible.

2.3  Versioning

   Each version of a schema needs to be complete, not a delta from the
   previous version.









Chisholm & Adwankar      Expires April 26, 2006                 [Page 7]


Internet-Draft        Framework for Netconf Content         October 2005


   The XML Schema version attribute will be used to signify version

         For example:

   <?xml version="1.0" encoding="UTF-8"?>
      <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
               version="3.1">
           <xs:element name="Foo">
          </xs:element>
     </xs:schema>

   This allows applications to be aware of XML Schema versions, and
   changes to XML Schema version, without forcing instance documents to
   change to a new schema if the new schema is backwards compatible.

2.4  Keys

   Keys are an optional construct for specifying the element or set of
   element that uniquely identifies an instance of a managed object.
   The XML Schema 'key' construct is used to specify keys.

   [Editor's Note: we may also want to define an attribute called keys
   so it can be sent over the wire in the instance document.]


     <example to come>


   Note that being able to query on arbitrary pieces of information
   provides for multiple views of the data, and the optional definition
   of keys does not preclude this.

2.5  Defining Relationships

   Relationships between elements come in three forms: associations,
   extensions and specializations.

   An extension to existing element defines information about the same
   managed object, but just does it in a separate piece of Schema.  For
   example, if a common Schema define information about interfaces, a
   particular product might define an extension to define information
   for that interface that is only applicable to that product.  To
   return to our book example, a particular publisher may wish the
   extend the general book definition to include information specific to
   their own books, such as the name of the animal depicted on the
   cover.

   A specialization of an existing element is an extension that only



Chisholm & Adwankar      Expires April 26, 2006                 [Page 8]


Internet-Draft        Framework for Netconf Content         October 2005


   applies to a subset of the instances of the managed object that the
   original definition applied to.  For example, the original element
   may define information about interfaces, with a specialization being
   defined that is information only applicable to ATM interfaces.  With
   our book example, a specialization of children's books might be
   defined that defines information such as suggested age of reader.

   An association exists between two different managed objects.  For
   example, a port is associated with an interface or a book within a
   bookshelf.

   It is important to be able to learn the relationships between the
   managed objects that are represented in the XML Schema in order to be
   able to take full advantage of information provided.  In addition to
   this, it is also important to be able to understand these
   relationships to help predict the behaviour of the system.  When a
   configuration command causes the creation of a managed object
   represented by a piece of XML schema, it causes the creation of all
   other bits of XML Schema that represent that managed object as well
   as any applicable specializations of that object.

   Relationships need to be understood in general as well as the
   specific run-time instances.  The general relationship needs to be
   understood when reading the schema or when designing tools and
   scripts to use the Schema.  For example, interfaces are associated
   with ports and there is a specific method of learning more about this
   relationship.  The run-time instance relationship, for example that
   port 3 is associated with interface number 324, or that the
   Encyclopaedia is on shelf 3 is learned using the general method
   learned while learning about the generalized relationships.

2.5.1  Associations Relationship

   The easiest way to define an association relationship is using
   containment.  A book is on a bookshelf, so the following XML makes
   this relationship obvious and unambiguous


     <bookShelf>
       <self>
         <book/>
       </shelf>
     </bookShelf>

   It is not always possible or desirable to model all associations via
   containment.  Managed objects are often associated with more than one
   other managed object and containment within both might cause
   confusion and certainly causes extra XML to be generated.  In



Chisholm & Adwankar      Expires April 26, 2006                 [Page 9]


Internet-Draft        Framework for Netconf Content         October 2005


   addition, in some associations, it might not be obvious to decide
   which objects is contained in which object.  And finally, it may be
   more workable to break the definition of managed objects into
   smaller, related pieces of XML Schema.

   The XML Schema 'keyref' construct will be used to define
   relationships between managed objects.

   [Editor's Note: ensure 'keyref' can be used to point at elements not
   within the same scope.  If not, define a similar construct that can
   be.]


     <example to come>



2.6  Defining Event Messages

   An event is something that happens which may be of interest.  A
   fault, a change in status, crossing a threshold, or an external input
   to the system, for example [RFC3877].  Often this results in an
   asynchronous message, sometimes referred to as a notification or
   event message, being sent out to interested parties to notify them
   that this event has occurred.  Event messages will be defined in XML
   Schema with an appinfo of 'eventClasses' used to both identify which
   bits of XML Schema define event messages but also what type of event.
   An event belongs to one or more classes.

   The initial set of classes is fault, information, state, audit,
   configuration, data, maintenance, metrics, security and heartbeat.  A
   fault event message is generated when a fault condition (error or
   warning) occurs.  An Information event is something that happens of
   interest which is within the expected operational behaviour and not
   otherwise covered by another class.  A state event indicates a change
   from one state to another, where a state is a condition or stage in
   the existence of a managed entity.  Audit events provide notification
   of very specific actions within a managed device.  In isolation an
   audit event provides very limited data.  A collection of audit
   information forms an audit trail.  A configuration event,
   alternatively known as an inventory event, is used to notify that
   hardware, software, or a service has been added/changed/removed.  A
   data dump event is an asynchronous event containing information about
   a system, its configuration, state, etc.  A maintenance event signals
   the beginning, process or end of  an action either  generated by a
   manual or automated  maintenance action.  A metrics event contains a
   metric or a collection of metrics.  This includes performance
   metrics.  A heart beat event is sent periodically to enable testing



Chisholm & Adwankar      Expires April 26, 2006                [Page 10]


Internet-Draft        Framework for Netconf Content         October 2005


   that the communications channel is still functional.

   Note that it may make operational sense to set the minAccess or
   maxAccess of an element with element classes defined against it to be
   a null list to indicate that this information can not be read or
   configured using other commands.







       <nm:eventClasses><configuration/><audit/>
                                          </nm:eventClasses>



2.7  Considerations for Parse-ability

   Netconf content can affect the efficiency and robustness of parsing
   routines in two ways.  The first has to do with whether anything
   within the Netconf content could be confused with any aspect of the
   operations, RPC or application protocol layers.  If this is possible,
   then more careful routines need to be written.  In particular, it
   might be difficult to separate out an implementation into separate
   methods to parse these different layers if it is necessary to parse
   the Netconf content and match open and close brackets rather than
   just looking for an appropriate close tag.

   Another aspect where the content will affect performance of the
   parsing routines is on the assumptions that the parsing routine can
   make.  The following section outlines some restrictions on the
   Netconf content that will positively impact the performance of
   parsing routines with minimum impact on the usability of the
   solution.

2.7.1  Well-formed XML

   All XML used within a Netconf solution needs to be well formed [XML]
   and conform to an XML Schema specification that conforms to the
   guidelines in this document.

2.7.2  No DTDs

   Document type declarations (DTDs) are not permitted to appear in
   NETCONF content




Chisholm & Adwankar      Expires April 26, 2006                [Page 11]


Internet-Draft        Framework for Netconf Content         October 2005


2.8  Use an Explicit Namespace on Attributes

   All attributes should be prefixed so that they belong to a specific
   namespace.  This encourages meaningful definitions that are free of
   collisions.


          <valid xmlns="http://valid/" xmlns:v="http://valid/"
                                                        v:foo="cool" />
          <not-valid xmlns="http://not-valid/" foo="not-cool" />



2.9  Naming

   All NetMod base elements SHOULD be defined in the namespace
   urn:ietf:params:xml:ns:netmod:base:1.0

   All NetMod defined datatypes SHOULD be defined in the namespace

   urn:ietf:params:xml:ns:netmod:datatypes:1.0

   The name of an element SHOULD be unique in a given namespace and
   should be addressed in a reference to a given namespace.

2.10  Error Messages

   Within Netconf, the  <error-app-tag> element is used to provide
   application-level error codes.  If implementations don't understand
   the application-level specific error codes, they still have the
   generic one to go by, but the application-level specific error codes
   can provide information about the specific problem that has happened.
   A non-exhaustive set of error messages that may get generated by the
   application as a result of performing netconf operations against that
   data model is included within the XML Schema that defines the Netconf
   content.

   An optional appinfo called 'errorMessages' is used to specify these
   application-level error messages.


     <nm:appErrors>
       <nm:appError>
         Book is in language you do not understand.
       </nm:appError>
     </nm>appErrors>





Chisholm & Adwankar      Expires April 26, 2006                [Page 12]


Internet-Draft        Framework for Netconf Content         October 2005


   These are applicable to any element.

   [Editor's Note: How closely tied are these to the known set of
   operations that can be performed on the data?  How is this
   determined?]

2.11  Schema Documentation

   The "documentation" tag must be used to provide all addition
   information to implementers and users of a schema that can not be
   modelled within the schema itself or using the appinfo defined within
   this memo.  This includes further restrictions and additional
   complexities as well as any information that will be helpful in
   understanding the element.

   Note that other means of documenting, including the  <!-- -->
   construct are not as easily associated within specific elements and
   not necessarily understood by all tools.

2.12  Specifying Statistics, Status and Configuration Information

   [Editors Note: What about historical performance statistics?]

   There may be potential value in being able to easily distinguish
   between configuration, status and statistical information within a
   data model.  This would allow better understanding of nature of each
   piece of information without requiring specific knowledge of the
   context.

   Propose adding an optional appinfo called dataType which takes a
   value of 'configuration', 'statistics', or 'status'.

   [Editor's Note: rework these examples to use appinfo]

   For example


        <nm:dataType>configuration</nm:dataType>


   [Editor's Note: Test on existing data models?]

2.13  Schema Identity Information

   Replacing the following with something from Dublin Core
   (http://dublincore.org) is for further study.

   A schema must contain a schema Identity annotation as part of the



Chisholm & Adwankar      Expires April 26, 2006                [Page 13]


Internet-Draft        Framework for Netconf Content         October 2005


   appinfo on the highest level schema element.  The Identity provides
   schema information such as last update of this schema, organization,
   contact, description and revision history.  The contact and revision
   information can occur multiple times in a schema identity.

   An example of identity element is as given below


      <xs:appinfo>
     <nm:Identity xmlns:n="urn:ietf:params:xml:ns:netmod:base:1.0">
      <nm:Name>NetConf State Schema</nm:Name>
      <nm:LastUpdated>2001-12-17T09:30:47-05:00
                                           </nm:LastUpdated>
      <nm:Organization>Example.com</nm:Organization>
      <nm:Contact>
       <nm:Name>ExampleName</nm:Name>
       <nm:Postal>ExampleAddress</nm:Postal>
       <nm:EMail>http://www.example.com</nm:EMail>
       <nm:Phone>0000000</nm:Phone>
       <nm:otherInfo>Any other Info</nm:otherInfo>
      </nm:Contact>
      <nm:Description>The Description of NetConf State Schema
      </nm:Description>
      <nm:RevisionHistory>
       <nm:Revision>2004-12-17T09:30:47-05:00</nm:Revision>
       <nm:Description>The first version of the schema
                                            </nm:Description>
      </nm:RevisionHistory>
     </nm:identity>
     </appinfo>





















Chisholm & Adwankar      Expires April 26, 2006                [Page 14]


Internet-Draft        Framework for Netconf Content         October 2005


3.  Modeling Considerations

3.1  Data Types

   XML Schema has 44 built in data types [XML-SCHEMA-2].  Potentially
   reusable data types should be declared as simple or complex type,
   rather than element.

   Emphasis should be replaced on creating reusable application-level
   data types such as IP addresses, DateAndTime or OSI states, rather
   than developing 20 different flavours of integers.

3.2  Elements and Attributes

   When designing encoding rules for NETCONF content, the following
   guidelines should be used to determine when use of elements is
   appropriate and when is use of attributes.

   Attributes should contain metadata about the element, not true data.
   Therefore, information about the managed entity should not be encoded
   in attributes.

   In addition, attributes are unordered, can appear only once, and can
   have no children.  When modelling data in an XML Schema, it is
   important to leave room for future expansion - in future
   specifications or future software releases.  This is another reason
   to only use attributes fro metadata.

3.3  Use Container Elements for Lists

   A distinct container should be used when encoding lists with multiple
   instances (maxOccurs > 1), use a distinct container element.
   Sometimes this will be the plural form of the instance element, but
   often there is a more natural container available.

   In this example, the element 'book' is contained within the "books"
   element.



            <books>
              <book>....</book>
              <book>....</book>
              <book>....</book>
            </books>

            <bookshelf>
              <book>....</book>



Chisholm & Adwankar      Expires April 26, 2006                [Page 15]


Internet-Draft        Framework for Netconf Content         October 2005


              <book>....</book>
              <book>....</book>
            </bookshelf>


   Use of container elements allows simpler manipulation of lists and
   list members.

3.4  Naming implications of using XPATH

   XPath [XPATH] can be used to locate managed objects in a given
   namespace.  XPATH based addressing can also be used to select a set
   of managed objects based on a set of criteria's, select content that
   is combination of different managed object values and to create
   simple expressions of managed objects.

   Examples of XPATH based addressing are shown below:

   1.  Provide all book titles in a . //bk:book/bk:bookTitle/@bk:value

   2.  Provide ACL information of the . /bk:/ACL

   3.  Determine book title for a book whose ISBN number is 0596002923
   //bk:book[bk:ISBN/@bk:value="0596002923"]/bk:bookTitle/@bk:value

   4.  List all book names where the average review rating is greater
   than 4. //bk:book[bk:AverageReview/@bk:value>4]/
   bk:bookTitle/@bk:value //if:ifEntry[if:ifMtu/@if:value>'500']

   5.  Select all books that have "NetMod" in their description and
   average review rating is greater than 4. //bk:book[(contains(bk:
   bookTitle/@bk:value,'NetMod')) and (bk:AverageReview/@bk:value>'4')]

   6.  Find number of books whose publication year is greater than 2003.
   count(//bk:book[bk:PublicationYear/@bk:value>'2003'])
















Chisholm & Adwankar      Expires April 26, 2006                [Page 16]


Internet-Draft        Framework for Netconf Content         October 2005


3.4.1  Proper Tag Names

   When choosing element names, they should:

      o  use ASCII (7-bit). [Editor's Note: is this just for IETF
      specifications, or in general?]

      o  be lower camel, a method of writing compound words or phrases
      where the words are joined without spaces, and each word is
      capitalized within the compound. The first letter of the compound
      is lower case. An example would be lowerCamel.

      o  Whenever possible, use full words.  There are some well-known
      abbreviations and short forms, such as "config" that would be
      considered  acceptable
           o  Should be consistent with existing vocabularies

   These are guidelines only and should be considered secondary to the
   need for consistency with existing vocabularies.  For example, when
   encoding SNMP MIB variables names in NETCONF, use the existing names
   (ifAddr) instead of shifting to these guidelines (ifAddress).  These
   guidelines are valuable when no common vocabulary exists, because
   they help to avoid the scenario in which a dozen developers choose a
   dozen names that differ in ways that lead to frustrating
   inconsistencies, such as ifaddr, if-addr, if-address, interface-
   address, intf-addr, iaddr, and iface-addr.

3.5  Granularity of Data Model

   Ideally, it should be possible to make a small change to the data
   model and have it trigger a big change in the managed entity.

3.6  Avoid Mixed Content

   Mixed content is defined as elements that can contain both data and
   other elements.  Elements in NETCONF can contain either data or
   additional elements only.

   This greatly simplifies the complexity of parsing XML, especially in
   the area of significant whitespace.  Whitespace inside data elements
   is significant.  Whitespace outside data elements is not.










Chisholm & Adwankar      Expires April 26, 2006                [Page 17]


Internet-Draft        Framework for Netconf Content         October 2005


          <valid>
            <element>data</element>
            <more>data</more>
          </valid>

          <not-valid>
            <element>data<more>data</more>maybe some</element>
          </not-valid>











































Chisholm & Adwankar      Expires April 26, 2006                [Page 18]


Internet-Draft        Framework for Netconf Content         October 2005


4.  Summary and Example

4.1  Summary of Netconf Appinfo Elements & Attributes

   The following table summarizes the XML Schema appinfo introduced in
   this memo When these appinfo are used in the definition of XML Schema
   for use with netconf, they are applicable to all instances of that
   Schema.

     --------------------------------------
     |  appinfo item    | | Compliance    |
     --------------------------------------
     | minAccess        | |  Mandatory    |
     | maxAccess        | |  Optional     |
     | status           | |  Optional     |
     | appErrors        | |  Recommended  |
     | identity         | |  Mandatory    |
     | eventClass       | |  Optional     |
     | dataType         | |  Optional     |
     --------------------------------------

                                 Figure 17





























Chisholm & Adwankar      Expires April 26, 2006                [Page 19]


Internet-Draft        Framework for Netconf Content         October 2005


4.2  XML Schema for Identity appInfo


      <xs:complexType name="IdentityType">
      <xs:sequence>
       <xs:element name="Name" type="xs:string"/>
       <xs:element name="LastUpdated" type="xs:dateTime"/>
       <xs:element name="Organization" type="xs:string"/>
       <xs:element name="Contact" type="ContactType"
                                             maxOccurs="unbounded" />
       <xs:element name="Description" type="Description" minOccurs="0"/>
       <xs:element name="RevisionHistory" type="RevisionType"
                                               maxOccurs="unbounded"/>
      </xs:sequence>
     </xs:complexType>

     <xs:complexType name="RevisionType">
      <xs:sequence>
       <xs:element name="Revision" type="xs:dateTime"/>
       <xs:element name="Description" type="xs:string"/>
      </xs:sequence>
     </xs:complexType>

     <xs:complexType name="ContactType">
      <xs:sequence>
       <xs:element name="Name" type="xs:string"/>
       <xs:element name="Postal" type="xs:string" minOccurs="0"/>
       <xs:element name="EMail" type="xs:anyURI"/>
       <xs:element name="Phone" type="xs:string" minOccurs="0"/>
       <xs:element name="otherInfo" type="xs:string" minOccurs="0"/>
      </xs:sequence>
     </xs:complexType>



4.3  XML Schema for per element appInfo


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       xmlns="urn:ietf:params:xml:ns:netmod:base:1.0"
       targetNamespace="urn:ietf:params:xml:ns:netmod:base:1.0"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified"    version="0.1" >


     <xs:complexType name="AppInfo">



Chisholm & Adwankar      Expires April 26, 2006                [Page 20]


Internet-Draft        Framework for Netconf Content         October 2005


       <xs:annotation>
         <xs:documentation>
         This is a set of information that can be applied to any
         element.
         </xs:documentation>
       </xs:annotation>
       <xs:sequence>
          <xs:element  name="minAccess" type="AccessList"/>
          <xs:element  name="maxAccess" type="AccessList"/>
          <xs:element  name="status" type="Status" minOccurs="0"/>
          <xs:element  name="appErrors" type="AppErrors" minOccurs="0"/>
          <xs:element  name="eventClasses" type="EventClasses"
                                                        minOccurs="0" />
       </xs:sequence>
   </xs:complexType>

      <xs:element  name="appInfo" type="AppInfo"/>

       <xs:simpleType name="Status">
           <xs:restriction base="xs:string">
                   <xs:enumeration value="current"/>
                   <xs:enumeration value="obsolete"/>
           </xs:restriction>
        </xs:simpleType>

       <xs:complexType name="AccessList">
           <xs:sequence>
              <xs:element name="access"
                            type="AccessType" maxOccurs="unbounded" />
           </xs:sequence>
       </xs:complexType>


        <xs:complexType name="AccessType"/>
        <xs:element name="Access"
                    type="AccessType" abstract="true"/>
        <xs:element name="read" type="AccessType"
                    substitutionGroup="Access"/>
        <xs:element name="write" type="AccessType"
                    substitutionGroup="Access"/>
        <xs:element name="create" type="AccessType"
                    substitutionGroup="Access"/>
        <xs:element name="delete" type="AccessType"
                    substitutionGroup="Access"/>
        <xs:element name="execute" type="AccessType"
                    substitutionGroup="Access"/>

       <xs:complexType name="AppErrors">



Chisholm & Adwankar      Expires April 26, 2006                [Page 21]


Internet-Draft        Framework for Netconf Content         October 2005


           <xs:sequence>
              <xs:element name="appError"
                            type="xs:string" maxOccurs="unbounded" />
           </xs:sequence>
       </xs:complexType>

        <xs:complexType name="EventClassType"/>
        <xs:element name="EventClass"
                    type="EventClassType" abstract="true"/>
        <xs:element name="fault" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="information" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="state" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="configuration" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="data" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="maintenace" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="metrics" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="security" type="EventClassType"
                    substitutionGroup="EventClass"/>
        <xs:element name="heartbeat" type="EventClassType"
                    substitutionGroup="EventClass"/>

           <xs:complexType name="EventClasses">
           <xs:sequence>
             <xs:element name="class" type="EventClassType"
                                          maxOccurs="unbounded"/>
           </xs:sequence>
         </xs:complexType>

   </xs:schema>



4.4  Managed Object Example

   An example of a node that describes a system description is shown
   below. .


   <?xml version="1.0" encoding="UTF-8"?>

   <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"



Chisholm & Adwankar      Expires April 26, 2006                [Page 22]


Internet-Draft        Framework for Netconf Content         October 2005


     xmlns:nm="urn:ietf:params:xml:ns:netmod:base:1.0"
     xmlns:book="urn:ietf:params:xml:ns:netmod:data:book:1.0"
     targetNamespace="urn:ietf:params:xml:ns:netmod:data:book:1.0"
     elementFormDefault="qualified" attributeFormDefault="unqualified"
     version="0.1">

   <xs:element name="book">
    <xs:complexType>
     <xs:complexContent>
            <xs:annotation>
            <xs:documentation xml:lang="en">
                   This element defines information about books
            </xs:documentation>
             <xs:appinfo>
                 <nm:appinfo>
                 <nm:minAccess> <nm:read/> </nm:minAccess>
                 <nm:maxAccess> <nm:read/> <nm:write/>
                                            </nm:maxAccess>
                 <nm:status> current </nm:status>
                 <nm:appErrors>
                   <nm:appError>Book lent out</nm:appError>
                   <nm:appError>Book not interesting
                                                 </nm:appError>
                   <nm:appError>Book in language you don't know
                                                 </nm:appError>
                   <nm:appError>Book eaten by book worm
                                                  </nm:appError>
                 </nm:appErrors>
              </nm:appinfo>
             </xs:appinfo>

            </xs:annotation>
            <xs:sequence>
             <xs:element ref="bk:bookTitle"/>
                   <xs:element name="ISBN" type="xs:string" >
                     <xs:annotation>
                       <xs:documentation>
                       The ISBN for this book.
                       </xs:documentation>
                       <xs:appinfo>
                         <nm:appinfo>
                          <nm:minAccess> <nm:read/> </nm:minAccess>
                          <nm:maxAccess> <nm:read/> <nm:create/>
                            <nm:delete/> <nm:write/> </nm:maxAccess>
                          <nm:status> current </nm:status>
                         </nm:appinfo>
                       </xs:appinfo>
                     </xs:annotation>



Chisholm & Adwankar      Expires April 26, 2006                [Page 23]


Internet-Draft        Framework for Netconf Content         October 2005


                   </xs:element>
                   <xs:element name="Author" type="xs:string" >
                      <xs:annotation>
                                       <xs:documentation>
                       The author of this book.
                       </xs:documentation>
                       <xs:appinfo>
                         <nm:appinfo>
                          <nm:minAccess> <nm:read/> </nm:minAccess>
                          <nm:maxAccess> <nm:read/> <nm:create/>
                            <nm:delete/> <nm:write/> </nm:maxAccess>
                          <nm:status> current </nm:status>
                         </nm:appinfo>
                       </xs:appinfo>
                     </xs:annotation>
                     </xs:element>
                   <xs:element name="PublicationYear" type="xs:string" >
                     <xs:annotation>
                       <xs:documentation>
                       The year this book was published
                       </xs:documentation>
                       <xs:appinfo>
                         <nm:appinfo>
                          <nm:minAccess> <nm:read/> </nm:minAccess>
                          <nm:maxAccess> <nm:read/> <nm:create/>
                            <nm:delete/> <nm:write/> </nm:maxAccess>
                          <nm:status> current </nm:status>
                         </nm:appinfo>
                       </xs:appinfo>
                     </xs:annotation>
                     </xs:element>
                   <xs:element name="LastIssueDate" type="xs:string" >
                     <xs:annotation>
                      <xs:documentation>
                       The last issue date for this book.
                       </xs:documentation>
                       <xs:appinfo>
                         <nm:appinfo>
                          <nm:minAccess> <nm:read/> </nm:minAccess>
                          <nm:maxAccess> <nm:read/> <nm:create/>
                            <nm:delete/> <nm:write/> </nm:maxAccess>
                          <nm:status> current </nm:status>
                         </nm:appinfo>
                       </xs:appinfo>
                     </xs:annotation>
                     </xs:element>
                   <xs:element name="AverageReview" type="xs:string" >
                     <xs:annotation>



Chisholm & Adwankar      Expires April 26, 2006                [Page 24]


Internet-Draft        Framework for Netconf Content         October 2005


                       <xs:documentation>
                       The average review for this book.
                       </xs:documentation>
                       <xs:appinfo>
                         <nm:appinfo>
                          <nm:minAccess> <nm:read/> </nm:minAccess>
                          <nm:maxAccess> <nm:read/> <nm:create/>
                            <nm:delete/> <nm:write/> </nm:maxAccess>
                          <nm:status> current </nm:status>
                         </nm:appinfo>
                       </xs:appinfo>
                     </xs:annotation>
                   </xs:element>
            </xs:sequence>
     </xs:complexContent>
    </xs:complexType>
      </xs:element>
      </xs:schema>

   An example of an instance of a book node is


     <book xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
           <bookTitle>XYZ</bookTitle>
           <ISBN>0000000123</ISBN>
           <Author>ABC</Author>
           <PublicationYear/>2005</PublicationYear>
           <LastIssueDate>2005-02-02</LastIssueDate>
           <AverageReview>5</AverageReview>
     </book>





















Chisholm & Adwankar      Expires April 26, 2006                [Page 25]


Internet-Draft        Framework for Netconf Content         October 2005


5.  Relationship to Netconf Protocol

   The Netconf architecture supports a clear separation between content
   and protocol.  This is an important architectural separation that
   should be maintained.  That having been said, there are major
   advantages to ensuring that the content of Netconf is well behaved
   and predictable

   Whether a Netconf implementation can be said to be compliant without
   also being compliant to the guidelines within this memo is an area of
   further study.

   The following examples illustrate the netconf protocol commands being
   executed against netmod compliant Schemas.

5.1  Merge Operation


   RPC Request :
      <nc:rpc message-id="101"
                     xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:edit-config>
           <nc:target>
               <nc:running/>
           </nc:target>
           <nc:default-operation>replace</nc:default-operation>
           <nc:config nc:operation="merge">
              <book xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
                   <bookTitle>NetMod for Dummies: Part2</bookTitle>
                   <ISBN>0596002923</ISBN>
                   <Author>NetMod Experts</Author>
                   <PublicationYear>2003</PublicationYear>
                   <LastIssueDate>2003-10-15</LastIssueDate>
                   <AverageReview>1</AverageReview>
               <book>
           </nc:config>
       </nc:edit-config>
   </nc:rpc>

   RPC Reply :
   <nc:rpc-reply message-id="101"
                  xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:ok/>
   </nc:rpc-reply>







Chisholm & Adwankar      Expires April 26, 2006                [Page 26]


Internet-Draft        Framework for Netconf Content         October 2005


5.2  Replace Operation


   RPC Request :
   <nc:rpc message-id="101"
            xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:edit-config>
           <nc:target>
               <nc:running/>
           </nc:target>
           <nc:default-operation>replace</nc:default-operation>
           <nc:config nc:operation="replace">
              <book xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
                   <bookTitle>NetMod for Dummies: Part2</bookTitle>
                   <ISBN>0596002924</ISBN>
                   <Author>NetMod Experts</Author>
                   <PublicationYear>2003</PublicationYear>
                   <LastIssueDate>2003-10-15</LastIssueDate>
                   <AverageReview>1</AverageReview>
               </book>
           </nc:config>
       </nc:edit-config>
   </nc:rpc>


   RPC Reply :
   <nc:rpc-reply message-id="101"
                   xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:ok/>
   </nc:rpc-reply>





















Chisholm & Adwankar      Expires April 26, 2006                [Page 27]


Internet-Draft        Framework for Netconf Content         October 2005


5.3  Delete Operation


   RPC Request :
   <nc:rpc message-id="101"
                  xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:delete-config>
           <nc:target>
               <nc:running/>
           </nc:target>
       </nc:delete-config>
   </nc:rpc>

   RPC Reply :
   <nc:rpc-reply message-id="101"
                   xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:ok/>
   </nc:rpc-reply>

































Chisholm & Adwankar      Expires April 26, 2006                [Page 28]


Internet-Draft        Framework for Netconf Content         October 2005


5.4  Create Operation


   RPC Request :

   <nc:rpc message-id="101"
                  xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:edit-config>
           <nc:target>
               <nc:running/>
           </nc:target>
           <nc:default-operation>replace</nc:default-operation>
           <nc:config nc:operation="create">
              <book xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
                   <bookTitle>NetMod for Dummies: Part6</bookTitle>
                   <ISBN>0596002</ISBN>
                   <Author>NetMod Experts</Author>
                   <PublicationYear>2003</PublicationYear>
                   <LastIssueDate>2003-10-15</LastIssueDate>
                   <AverageReview>1</AverageReview>
               </book>
           </nc:config>
       </nc:edit-config>
   </nc:rpc>

   RPC Reply :
   <nc:rpc-reply message-id="101"
                 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:ok/>
   </nc:rpc-reply>





















Chisholm & Adwankar      Expires April 26, 2006                [Page 29]


Internet-Draft        Framework for Netconf Content         October 2005


5.5  Get Operation



   RPC Request :
   <nc:rpc message-id="101"
                 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:get-config>
           <nc:source>
               <nc:running/>
           </nc:source>
       </nc:get-config>
   </nc:rpc>

   RPC Reply :
   <nc:rpc-reply message-id="101"
                 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:data>
          <book xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
               <bookTitle>NetMod for Dummies: Part2</bookTitle>
               <ISBN>0596002923</ISBN>
               <Author>NetMod Experts</Author>
               <PublicationYear>2003</PublicationYear>
               <LastIssueDate>2003-10-15</LastIssueDate>
               <AverageReview>1</AverageReview>
          </book>
          <book xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
               <bookTitle>NetMod for Dummies: Part2</bookTitle>
               <ISBN>0596002924</ISBN>
               <Author>NetMod Experts</Author>
               <PublicationYear>2003</PublicationYear>
               <LastIssueDate>2003-10-15</LastIssueDate>
               <AverageReview>1</AverageReview>
           </book>
       </nc:data>
   </nc:rpc-reply>















Chisholm & Adwankar      Expires April 26, 2006                [Page 30]


Internet-Draft        Framework for Netconf Content         October 2005


5.6  Get Operation with subtree filtering


   RPC Request :
   <nc:rpc message-id="101"
                  xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:get-config>
           <nc:source>
               <nc:running/>
           </nc:source>
           <nc:filter type="xpath">//bk:ISBN</nc:filter>
       </nc:get-config>
   </nc:rpc>

   RPC Reply :
   <nc:rpc-reply message-id="101"
                 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:data>
              <ISBN
               xmlns:bk="urn:ietf:params:xml:ns:netmod:data:book:1.0">
               0596002924
               <ISBN>
       </nc:data>
   </nc:rpc-reply>





5.7  Get All Operation


   RPC Request :
   <nc:rpc message-id="101"
                  xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:get/>
   </nc:rpc>

   RPC Reply :
   <nc:rpc-reply message-id="101"
                 xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
       <nc:data>
           <configs xmlns="urn:ietf:params:xml:ns:netconf:state:1.0">
               <config>
                   <lock-status>
                       <lock-state>locked</lock-state>
                       <locked-by>7</locked-by>
                   </lock-status>



Chisholm & Adwankar      Expires April 26, 2006                [Page 31]


Internet-Draft        Framework for Netconf Content         October 2005


                   <config-name>
                       <startup/>
                   </config-name>
               </config>
               <config>
                   <lock-status>
                       <lock-state>unlocked</lock-state>
                       <locked-by/>
                   </lock-status>
                   <config-name>
                       <candidate/>
                   </config-name>
               </config>
               <config>
                   <lock-status>
                       <lock-state>unlocked</lock-state>
                       <locked-by/>
                   </lock-status>
                   <config-name>
                       <startup/>
                   </config-name>
               </config>
           </configs>
           <state xmlns="urn:ietf:params:xml:ns:netconf:state:1.0">
               <sessions>
                   <session>
                       <session-id>6</session-id>
                       <userName>Bob</userName>
                       <login-time>2:56:01 PM</login-time>
                   </session>
               </sessions>
           </state>
           <nc:config>
              <book xmlns="urn:ietf:params:xml:ns:netmod:data:book:1.0">
                   <bookTitle>NetMod for Dummies: Part2</bookTitle>
                   <ISBN>0596002924</ISBN>
                   <Author>NetMod Experts</Author>
                   <PublicationYear>2003</PublicationYear>
                   <LastIssueDate>2003-10-15</LastIssueDate>
                   <AverageReview>1</AverageReview>
              </book>
           </nc:config>
       </nc:data>
   </nc:rpc-reply>







Chisholm & Adwankar      Expires April 26, 2006                [Page 32]


Internet-Draft        Framework for Netconf Content         October 2005


6.  Security Considerations

   To be determined once specific aspects of this solution are better
   understood.  In particular, the access control framework and the
   choice of transport will have a major impact on the security of the
   solution













































Chisholm & Adwankar      Expires April 26, 2006                [Page 33]


Internet-Draft        Framework for Netconf Content         October 2005


7.  Acknowledgements

   This document is a result of discussions at IETF 59 and 60, as well
   as on the mailing list by the following people: Sharon Chisholm,
   David Harrington, Ray Atarashi, Yoshifumi Atarashi, Bert Wijnen, Dan
   Romascanu, Andy Bierman, Randy Presuhn, Chris Lonvick, Eliot Lear,
   Avri Doria, Juergen Schoenwaelder, Rob Ennes, Faye Ly, and Andre
   Westerinen.

8.  References

   [NETCONF]  Enns, R., "NETCONF Configuration Protocol",
              ID draft-ietf-netconf-prot-06, April 2005.

   [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.

   [XML]      World Wide Web Consortium, "Extensible Markup Language
              (XML) 1.0", W3C XML, February 1998,
              <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [refs.RFC2026]
              Bradner, S., "The Internet Standards Process -- Revision
              3", RFC 2026, BCP 9, October 1996.

   [refs.RFC2119]
              Bradner, s., "Key words for RFCs to Indicate Requirements
              Levels", RFC 2119, March 1997.

   [refs.RFC2223]
              Postel, J. and J. Reynolds, "Instructions to RFC Authors",
              RFC 2223, October 1997.


Authors' Addresses

   Sharon Chisholm
   Nortel
   3500 Carling Ave
   Nepean, Ontario  K2H 8E9
   Canada

   Email: schishol@nortelcom







Chisholm & Adwankar      Expires April 26, 2006                [Page 34]


Internet-Draft        Framework for Netconf Content         October 2005


   Sandeep Admankar
   Motorola
   1301 East Algonquin Road
   MS IL02-2240
   Schaumburg, Il  60196
   USA

   Email: sandeep.adwankar@motorola.com











































Chisholm & Adwankar      Expires April 26, 2006                [Page 35]


Internet-Draft        Framework for Netconf Content         October 2005


Appendix A.  Appendix

A.1  Access Control

A.1.1  Overview

   For discussing access control, we shall use the same equivalence
   classes for operations on data: "Create", "Delete", "Read", "Write",
   and "Execute".

   Access control is defined only for the node it is associated with.
   It does not cascade throughout a containment hierarchy.

   There are four classes of access control that can possibly be
   defined:

   1.  Resource Category: High Level like BGP or DNS, similar to syslog
   concept

   2.  Resource Type: Lowest level before instance

   3.  Resource Instance

   4.  Operation Type

   There is a fifth class that enables access control within an instance
   to specific values.  This level of control is beyond the scope of
   this specification.

   [Editor's Note: What about permission to traverse through a
   hierarchy?  This naturally imparts information about the hierarchy
   that might allow a user to gleam things they should not.

   The two main use cases for consideration are single customer and
   multiple customers on a single box.  Note that the concept of a
   virtual router has been successful in solving the latter problem in
   SNMP and CLI.

   Ideally the security model used in netconf is integratable with well-
   deployed solutions like RADIUS and TACACS+.

   Netconf may only need a mechanism to report information about access
   control and an API to enable easy integration to an existing
   solution.

A.1.2  Proposed Solution

   [Editors Note: This area is for further study.  Which bits belong in



Chisholm & Adwankar      Expires April 26, 2006                [Page 36]


Internet-Draft        Framework for Netconf Content         October 2005


   the data model and which in the protocol?  Can define a simple
   security model that modelled on what CLIs do and integrate with
   radius?  What impacts would this have on the data model?  Do we want
   to a fully exposed and described model or just the ability to answer
   the question "Is user A allows to run this command?".  How do we
   identify users, or do we need to (is it out of scope?)?  The
   requirement is to identify it so it can be deployed in deployed
   security infrastructure.]

   A solution will need to identify the type off access that is
   permitted, profile an identifier for this instance of access
   permissions and potentially identify a timeframe that this access is
   good for.  This access would then need to be associated with
   particular class and instance data, as described above.


                 <xs:complexType name="ACLEntryType">
             <xs:sequence>
               <xs:element name="access" type="AccessType"/>
               <xs:element name="Identifier" type="IdentifierType"/>
               <xs:element name="accessDuration"
                                   type="xs:duration" minOccurs="0"/>
             </xs:sequence>
           </xs:complexType>



























Chisholm & Adwankar      Expires April 26, 2006                [Page 37]


Internet-Draft        Framework for Netconf Content         October 2005


Intellectual Property Statement

   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.

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.


Disclaimer of Validity

   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.


Copyright Statement

   Copyright (C) The Internet Society (2005).  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.





Chisholm & Adwankar      Expires April 26, 2006                [Page 38]


Internet-Draft        Framework for Netconf Content         October 2005


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.















































Chisholm & Adwankar      Expires April 26, 2006                [Page 39]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/