From: http://www.ietf.org/internet-drafts/draft-nair-simple-xcap-acl-00.txt Title: Specifying Access controls for XCAP data models Reference: IETF Working Group, Internet-Draft 'draft-nair-simple-xcap-acl-00' Date: une 18, 2006 See also: http://xml.coverpages.org/xacml.html Extensible Access Control Markup Language (XACML) http://www.ietf.org/html.charters/simple-charter.html SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) WG ======================================================================== SIMPLE H. Nair Internet-Draft C-cor Solutions Intended status: Standards Track S. Channabasappa, Ed. Expires: December 20, 2006 CableLabs June 18, 2006 Specifying Access controls for XCAP data models draft-nair-simple-xcap-acl-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 20, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 1] Internet-Draft Access controls for XCAP data models June 2006 Abstract This document presents the need, and a proposal for defining access control definitions for data elements, defined using XML Schemas for use with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case for access control definitions . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Defining access controls . . . . . . . . . . . . . . . . . . . 7 4.1. Basic access permissions . . . . . . . . . . . . . . . . . 7 4.2. Pre-defined access controls: access levels . . . . . . . . 9 5. XML Schema for access controls . . . . . . . . . . . . . . . . 12 5.1. XML Schema definition . . . . . . . . . . . . . . . . . . 12 5.2. Explanation . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.1. Types . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.2. Attributes . . . . . . . . . . . . . . . . . . . . . . 19 5.2.3. Elements . . . . . . . . . . . . . . . . . . . . . . . 19 6. Specifying access controls . . . . . . . . . . . . . . . . . . 22 6.1. Referencing access control definitions . . . . . . . . . . 22 6.2. Inline access specification . . . . . . . . . . . . . . . 22 6.3. Default access levels . . . . . . . . . . . . . . . . . . 22 7. Enforcing access controls . . . . . . . . . . . . . . . . . . 24 8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Intellectual Property and Copyright Statements . . . . . . . . . . 31 Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 2] Internet-Draft Access controls for XCAP data models June 2006 1. Introduction XCAP ([ID-XCAP]) is a protocol specification presented in the IETF that can be used to manipulate per-user data in SIP User Agents (UAs). It is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources Usage of XML in XCAP raises requirements beyond the scope of the actual protocol - like access control - the focus of this document. As a clarification, the focus of this document is purely element level access controls. Standards such as the OASIS eXtensible Access Control Markup Language (XACML) specifications focus on authorization of requests and decision information (and for those reasonse, considered too abstract and complex for element level access controls. ACL definitions need to be clear, concise, and easy to specify, comprehend. Further, to accommodate existing XML Schema definitions, it may be necessary to specify ACL definitions that can be used with minimal modifications to such XML Schemas, if any. However, newly defined schemas could utilize optimized ACL definitions, also specified in this document. This document presents multiple options for defining access controls that can be employed by XML Schema ([XMLSchemaI] and [XMLSchemaII]) based data models used by XCAP deployments. Further, this document utilizes XPATH ( [XPath]) to identify specific elements within an XML document, when required. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 3] Internet-Draft Access controls for XCAP data models June 2006 2. Use Case for access control definitions Note: This use case is derived in part from "Use Case 2: Access Control Definitions and XML-based configuration methodologies" as illustrated in [ID-SIPUA-CFG-MGMT] Access control definitions allow data model designers to choose access rights and restrictions for the defined data elements. Most everyone is familiar with the UNIX ACL management associated with the file system: each file has read/write/execute access rights for the owner, group, and others. The View-based Access Control Model (VACM) for SNMP is also a good reference as it is applied to configuration ([RFC3415]). In this use case, we look at the change in data ownership that is introduced by XML-based configuration models used with XCAP and illustrate that access control definitions are a necessity. Use case description: A SIP client is configured using the SIPPING configuration framework and XCAP. Changes in the configuration data elements may occur at multiple levels (write access): based on end-user settings on the SIP device, remote configuration changes (end-user accessing a web-based interface to change settings or a service operator updating the config), or other means (software updates from device manufacturer changing some default configuration parameters, etc.). Furthermore, the presentation of some configuration data (read access) may also have to be controlled: not all users of a client may be allowed to change the settings, some settings may be hidden by the protocol stacks, device manufacturers or service providers so that end-users may not misconfigure the device and disrupt the service. Note that the mechanism by which the configuration change is not a factor in this use case: a configuration change may be operated via a custom user interface on the SIP device or application, an end-user or operator controlled CLI, or remote web-based applications used by Customer Service Representatives (CSRs). Problem statement: How does the designer of the XML schema specify access rights (read, write, update, delete) for each data element and for each actor (end- user, client, network elements) in an interoperable manner? This is illustrated in Figure 1. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 4] Internet-Draft Access controls for XCAP data models June 2006 --------- ------------- | Network | | Application | | Element | | Server | --------- ------------- | | | | | | | | | | ----- | ________ | |(CSR)| | / \ | ----- | | XCAP | | | | | SERVER | | | | | | | | \ | -------- | / V ---> ||<>||<--- ------------ | -------- |<----------------- | Application| \________/ ------------ ^ ^ | | --- --- | | V | ------ ------ |SIP UA| |WEB-UI| ------ ------ \ / -------- |END-USER| -------- Figure 1: Illustration of an XCAP usage and the need for access controls There are no currently known access control specifications for XCAP. Thus, there is a need to propose access control definitions, keeping in mind various possible actors. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 5] Internet-Draft Access controls for XCAP data models June 2006 3. Terminology 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 [RFC2119]. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 6] Internet-Draft Access controls for XCAP data models June 2006 4. Defining access controls 4.1. Basic access permissions This document defines the following basic access permissions that MUST be supported by all complying data models: o Create: Actor has the ability to create the element o Read: Actor has the ability to read the contents of an existing element o Update: Actor has the ability to modify the contents of an existing element o Delete: Actor has the ability to delete an existing element As illustrated in the Use Case, there may be various actors, each with varying 'access control permissions'. The following are assumed in this document: o Given that actors may be specific to data models and supported architectures, this document neither defines nor constrains the definition of actors outside of an 'XCAPServer'. It is assumed that each actor specified refers to one or more 'entities' which have some characteristics and are defined in an external schema or document. o The actor termed as 'XCAPServer', in the context of this document is an actor representing an XCAP Server which, by default, has all possible access permissions and is the governing body enforcing the defined access controls The following example illustrates a sample definition of the basic access controls for actors defined by another XML Schema (http://www.todo.org/ns/xcap/acl.xsd) Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 7] Internet-Draft Access controls for XCAP data models June 2006 1. 2. 3. 4. 5. /ns1:Node1/ns1:Node2 7. 9. 11 13 15 17 18 19 .... 20 Figure 2: Sample access control definitions An explanation of the access specification is as follows: o Line 1 identifies the file as an XML 1.0 document using the UTF-8 character encoding. o Line 2 contains the top level element of the document and its namespace - it identifies the document as being an access declarations document. o Line 3 begins the access specifications for a particular document. It identifies the document referenced by a URL o Line 4 begins an access specification for the document referenced in line 3. o Lines 5, 6 define the part of the document that this access specification applies to. The contents of the 'acl:node' element is an XPath reference to the target node within the referenced document. o Lines 7, 8 define one permission for the node referenced in Line 6. It uses assigns the predefined 'read' permission to the predefined actor 'User'. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 8] Internet-Draft Access controls for XCAP data models June 2006 o Lines 9, 10 assign the predefined 'create' permission to the predefined actor 'UE'. o Lines 9-16 define more permissions. o Lines 17, 18 close the access and document elements respectively. This example only specifies one access definition for this document. o Line 20 closes the access specification document. 4.2. Pre-defined access controls: access levels While the basic access permissions are the building blocks for defining access controls, it is usually a combination of those permissions for any given actor and element. E.g. o An element such as 'Node1', for the actor 'UserA', may have access permissions for 'create' and 'read' o An element such as 'Node2', for the actor 'NetworkElementA', may have access permissions for 'create', 'read', 'update' and 'delete' Additionally, in most scenarios, multiple actors may have the same permissions. For e.g: o 'UserA', 'UserB' and 'UserC' subscribe to the same service 'S1' and hence belong to the category 'XYZUsers' o 'ApplicationServer1' and 'ApplicationServer2' provide the same service 'S1' and hence belong to the category 'AppServersS1' Further, there may be a need to take the above requirements (<single actor, multiple permissions> and <multiple actors, same permissions>) and combine them (< multiple actors, multiple permissions>) for a more effective access control definition. For e.g. o For certain elements of service 'S1', actors 'ApplicationServer1' and 'ApplicationServer2' have 'create' and 'read' permission when 'ApplicationServer3' and 'ApplicationServer4' have only 'read' and 'update' permission o For service 'S2', all actors of the category 'users' are treated equal with only 'read' permissions and all actors of the category 'network elements' are treated equal with 'read' and 'update' permissions Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 9] Internet-Draft Access controls for XCAP data models June 2006 Allowing for such categories which combine multiple 'actors' and 'basic permissions' may not only be beneficial for data modeling, but also make access control definitions simpler to comprehend and enforce. This document allows for this by allowing for pre-defined access controls termed 'access levels' o For the purpose of this document, an access level is defined as a named collection of permissions. An access level may specify permissions for multiple operations and multiple actors. An example of such an aggregation is as defined in the example shown below. 1 2 3 5 7 9 11 13 15 16. Figure 3: Example of access levels Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 10] Internet-Draft Access controls for XCAP data models June 2006 The example defines a new access level termed 'S1NetworkElementACLS' which specifies access permissions for multiple network elements (A, B and C). Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 11] Internet-Draft Access controls for XCAP data models June 2006 5. XML Schema for access controls 5.1. XML Schema definition Type of pricipal that an ACL applies to. Base type for actor entries Standard actor names Type of operation Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 12] Internet-Draft Access controls for XCAP data models June 2006 Base type for operations Standard operations Standard / predefined access levels. The value must be either an absolute URL or a URN. The semantics of the access level identified by a given URI are defined by the naming authority identified by the URI Access level for the containing element Attributes used in a permission definition The actor this access level specification applies to. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 13] Internet-Draft Access controls for XCAP data models June 2006 The operation that is allowed. Each element describes the access allowed for a particular actor NetworkWriteable Access level declarations for a given node within the current document Node is an XPath reference to a node within the current document. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 14] Internet-Draft Access controls for XCAP data models June 2006 A reference to a predefined set of permissions. Schema complex type for a collection of access specifications Access level declarations for a given node within the current document The access control element specifies one of either an inline access control specification for the container document, or a reference to an external document. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 15] Internet-Draft Access controls for XCAP data models June 2006 Top level element for an external access specification document Access definitions for a document Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 16] Internet-Draft Access controls for XCAP data models June 2006 http://www.todo.org/ns/xcap/acl.xsd#NetworkWriteable Top level element for en external access level specification document Identifies the access level. This ID is to be used as fragment identifier for external references. Figure 4: Access Control XML Schema definition for XCAP data models Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 17] Internet-Draft Access controls for XCAP data models June 2006 5.2. Explanation 5.2.1. Types This section describes the major types defined by this schema and their semantics. 5.2.1.1. accessLevelType The XML Schema simple type accessLevelType denotes a URI that identified a predefined access level. It has a schema type of anyURI. The URI value used as an access level MUST be either an absolute URL or a URN. The semantics of a given URI value is defined by the naming authority identified by the URI. 5.2.1.2. baseOperationType The XML Schema simple type baseOperationType denotes a URI that identifies an operation. . It has a schema type of anyURI. The URI value used to identify an operation MUST be either an absolute URL or a URN. The semantics of a given URI value is defined by the naming authority identified by the URI. 5.2.1.3. stdOperationsType The XML Schema simple type stdOperationsType is an extension of the baseOperationType that enumerates some predefined operations. The defined values that each consist of the namespace for this schema suffixed with a fragment identifier of one of #create, #read, #update, #delete identify an operation that creates a new node, reads a node, updates an existing node, or deletes a node respectively. 5.2.1.4. operationsType The XML Schema type operationsType is a union of baseOperationType and stdOperationsType. I.e. it is an 'open enumeration' of URI values with certain predefined values, but open to other values defined elsewhere. 5.2.1.5. baseActorType The XML Schema simple type baseActorType denotes a URI that identifies an actor. It has a schema type of anyURI. The URI value used to identify an actor MUST be either an absolute URL or a URN. The semantics of a given URI value is defined by the naming authority identified by the URI. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 18] Internet-Draft Access controls for XCAP data models June 2006 5.2.1.6. stdActorsType The XML Schema simple type stdActorsType is an extension of the baseActorType that enumerates some predefined operations. The defined values that each consist of the namespace for this schema suffixed with a fragment identifier of one of #Network, #UE, #User identify an the Network / service provider, the User equipment, and the end user respectively. 5.2.1.7. actorType The XML Schema type actorType is a union of baseActorType and stdActorsType. I.e. it is an 'open enumeration' of URI values with certain predefined values, but open to other values defined elsewhere. 5.2.1.8. documentAclType The XML Schema complex type documentAclType defines the common content of access control specifications within and external to the target documents. It consists of a sequence of 'access' elements that define the access for various nodes within that document. 5.2.2. Attributes 5.2.2.1. my-access-level The attribute my-access-level is an attribute of type accessLevel. It is used to specify access levels of elements from this same schema used for access control specifications. Since elements from this schema can be used inline in other XML Schemas, or can be exposed via XCAP when used as standalone access control documents, this element provides a means to unambiguously specify the access controls on the access control specifications itself. 5.2.3. Elements 5.2.3.1. access The XML Schema element access describes the access permissions on a particular node. The node is identified through an XPath expression. The allowed permissions are specified by a combination of an access level reference an element 'access-level-ref' of type accessLevelType and a collection of 'permission' elements. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 19] Internet-Draft Access controls for XCAP data models June 2006 5.2.3.2. access-control The access-control element is the container element for inline access control specifications in other schemas. Schemas may include this element within their top level elements to provide a location to specify access control within the document. This element may also be used to provide an inline reference to an external access control specification document. This is done using the source attribute of this element. The source attribute is a URL that identifies the external document that contains the access control specifications. When used with XCAP, the source attribute SHOULD be a relative URL. If the value of this attribute is a relative URL it MUST be treated as relative to the XCAP ROOT of the document that contains it. The source attribute and the access elements within the access- control element are mutually exclusive. Document SHOULD NOT contain both of these. Implementations MUST ignore the source attribute if the access-control element contains access elements. 5.2.3.3. access-declarations The access-declarations element is the top level element for a standalone access control specification document. It consists of multiple 'document' elements each of which identifies a document and the access restrictions that apply to it. The document element has a 'source' attribute that identifies the document to which the contained access specifications apply. This source attribute is mandatory. An access-declarations document MUST NOT contain multiple 'document' elements that refer to the same document. 5.2.3.4. access-level-declarationa The element access-level-declarations is the top level element for a standalone access level definition document. This element contains multiple access-level elements, each of which have an ID attribute and contain permission elements. The access-level-declarations element may be used to define access level URL values. For this use, the access-level-declarations document must be available at a URL accessible to all actors involved. Based on such a document accessLevel URL values may be constructed consisting of an absolute URL for the definition document and a fragment identifier that corresponds to the 'id' attribute of an access level specified within that document. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 20] Internet-Draft Access controls for XCAP data models June 2006 5.2.3.5. permission The permission element is used to specify a single permission. It has two attributes, an actor attribute of type actorType that identifies the actor for which an access for an operation is granted, and an operation attribute of type operationType that identifies the operation that is permitted. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 21] Internet-Draft Access controls for XCAP data models June 2006 6. Specifying access controls 6.1. Referencing access control definitions A data model designer, as part of the resulting XML Schema can define access controls conformant to the XML Schema specified in this document and: o explicitly include the access control specification within the document o include it via a reference to an external access control document The XML schema defined in this document provides the <acl:access- control> element that can be included in other XML Schemas. XML Schemas that include this element SHOULD include it as a single optional second level (i.e. immediate child element of the top level element of the document) The <acl:access-control> element contains multiple <acl:access> elements. Each access element references a node within that containing document and specifies permissions as was indicated in the example provided earlier 6.2. Inline access specification To allow inline access specifications, this document permits predefined access levels to be referenced directly in the element it applies to. This is done by including the acl:access-level attribute in the element it applies to. Note that utilizing this facility requires the schema to allow such an attribute. Many standard XML Schema definitions allow arbitrary attributes from other namespaces to be included in an element. 6.3. Default access levels XML Schema authors wishing to support access control MAY specify suggested default values for access. This can be done by including <acl:permission> elements in the <appinfo> element of a declaration in XML Schema. The following XML Schema snippet illustrates this. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 22] Internet-Draft Access controls for XCAP data models June 2006 ... ... ... Figure 5: Specifying default access levels Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 23] Internet-Draft Access controls for XCAP data models June 2006 7. Enforcing access controls As described earlier, permissions for a node in a document may be specified in several ways It may be specified inline through the acl: access-level attribute on an element, may be specified through inline permissions in an access-control element in the same document, or it may be specified externally in an access control specification document. In addition the schema of the document may itself recommend a default access level for its elements. Further it is useful to allow the permissions defined on an element to also apply to its contents as it simplifies the specification of access by aggregation. It is therefore likely that multiple, potentially conflicting permissions may apply from these sources to a given node. For the purpose of this discussion, permissions specified in the XML schema for a document are called 'default permissions' and permissions defined through other means are called 'explicit permissions'. The node on which an operation is being performed is called 'the node in question'. This document recommends the following policy for combining multiple access specifications. The explicit permissions defined for a node is derived from each of the sources in the following order: 1. Access specified by an inline acl:access-level attribute has the highest precedence and is considered first. 2. If one is not found, then the document is checked for an inline acl:access-control element that specifies access control for the node in question. 3. If no such element is found, then the external access specification document is checked for an access specification that applies to the current document and the node in question. Note: the search among the various sources is for the presence of an explicit access control specification, not for a specific permission. This is because, the format is based on a default policy of deny with explicit permissions. Therefore the absence of permission implies denial. The permission that apply to an operation are then determined as follows. 1. If the node in question has explicit permissions, those permissions apply. 2. Otherwise, the effective explicit permissions that apply to a node are the permissions defined to apply on the node closest to Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 24] Internet-Draft Access controls for XCAP data models June 2006 the node in question on the 'parent' axis starting from the node in question. If no explicit permission is found to apply to the node in question then the default permissions defined by its Schema is used. Here again, the permission that is defined for the node that is closest along the parent axis, to the node in question is used. Irrespective of the access specified, the server MAY deny an attempt to create modify or delete the access control elements or attributes in a document through XCAP for some or all clients. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 25] Internet-Draft Access controls for XCAP data models June 2006 8. Open Issues The following items are yet to be finished to complete this draft proposal: o verify the XML Schema and examples for completeness o obtain feedback on default, inline and external specification methods and list the pros and cons o obtain feedback from the XCAP community for constraints not considered by this version o revisit the security considerations Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 26] Internet-Draft Access controls for XCAP data models June 2006 9. Acknowledgments The authors of this draft wish to thank members of the CableLabs PacketCable focus teams and various other IETF participants who contributed directly or indirectly to the content presented in this draft. Specifically, the following individuals are recognized (in alphabetical order): Jean-Francois Mule, Josh Littlefield and Thomas Clack. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 27] Internet-Draft Access controls for XCAP data models June 2006 10. Security Considerations This document specifies a way to define access control for XML Schema data elements for use with XCAP. Since the access controls are also defined using XML, and can be part of an external document (as a Schema), or part of the actual document whose access controls it defines, there is a need to ensure that only authorized elements can modify the access controls themselves. This can be accomplished by enforcing configured access controls on the XCAP Server or by specifying access controls for the access control elements. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 28] Internet-Draft Access controls for XCAP data models June 2006 11. References 11.1. Normative References [ID-XCAP] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", May 2006. [XMLSchemaI] W3C Recommendation, "XML Schema Part 1: Structures Second Edition", Oct 2004. [XMLSchemaII] W3C Recommendation, "XML Schema Part 2: Datatypes Second Edition", Oct 2004. [XPath] W3C Recommendation, "XML Schema Part 1: Structures Second Edition", Oct 2004. 11.2. Informative References [ID-SIPUA-CFG-MGMT] Channabasappa, S. and J-F. Mule, "Use Cases and Considerations for SIP Client Configuration and Management", Feb 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 29] Internet-Draft Access controls for XCAP data models June 2006 Authors' Addresses Harindranath P R Nair C-cor Solutions 1825 NW 167th Place Beaverton, OR 97006 USA Email: hnair@c-cor.com Sumanth Channabasappa (Editor) CableLabs 858 Coal Creek Circle Louisville, Co 80027 USA Email: sumanth@cablelabs.com Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 30] Internet-Draft Access controls for XCAP data models June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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). Nair & Channabasappa, Ed. Expires December 20, 2006 [Page 31]