Internet Draft D. Petrie Doc: draft-petrie-sipping-ua-prof-framewk-reqs-00.txt Pingtel Corp. 24 June 2002 C. Jennings Expires: December 2002 Cisco Systems Requirements for SIP User Agent Profile Delivery Framework Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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. 1 Abstract This document attempts to identify the requirements for a protocol framework to provide SIP user and device profiles to SIP user agents. The objective is not to invent new special purpose protocols, but to identify the requirements such that a rational decision can be made as to what existing protocol(s) should be used to solve the problem of providing user and device profiles to SIP user agents. This document also contains an evaluation of a set of applicable protocols. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" this document are to be interpreted as described in RFC-2119 [RFC2119]. Petrie/Mahy Exp: Dec. 2002 [Page 1] xxxxx Table of Contents 1 Abstract.......................................................1 2 Conventions used in this document..............................1 3 Overview.......................................................3 3.1 Background.....................................................3 3.2 Functional Groups..............................................3 3.3 Terminology....................................................4 4 Requirements...................................................4 4.1 General........................................................4 4.1.1 Roaming......................................................4 4.1.2 Open and Extensible for Vendor...............................5 4.1.3 NAT/Firewall Support.........................................5 4.1.4 Availability of Development Tools............................6 4.2 Discovery......................................................6 4.3 Enrollment.....................................................6 4.4 Profile Retrieval..............................................8 4.5 Change Notification............................................8 4.6 Profile Upload.................................................8 4.7 Security.......................................................9 4.8 Data Container.................................................9 5 Protocol Evaluation...........................................10 5.1 Evaluation Criteria...........................................10 5.2 SNMP..........................................................11 5.3 LDAP..........................................................12 5.4 ACAP..........................................................12 5.5 SLP...........................................................13 5.6 SIP Events....................................................14 5.7 HTTP..........................................................15 5.8 DHCP Options..................................................16 5.9 DNS...........................................................16 5.10 XML..........................................................16 5.11 RFC 822......................................................16 6 Security Considerations.......................................16 7 Conclusion....................................................16 8 References....................................................18 9 Acknowledgments...............................................19 10 Author's Addresses............................................19 Petrie/Mahy Exp: Dec. 2002 [Page 2] xxxxx 3 Overview 3.1 Background There is a general need to standardize methods for adding, enabling, and maintaining user and device profiles used by SIP user agents within a VoIP system. When one considers the effort needed to set up systems with hundreds or thousands of users and user agents, the need for reducing set up time is obvious. After a system is set up, ongoing maintenance in the form of changing the user and device profiles on a large population of user agents, is likely to be necessary and requires a similar administrative effort. In addition to these scaling problems, it is likely that the population of user agents in any given VoIP system will be heterogeneous: the configuration strategy must be flexible enough to accommodate different needs for different users. Consequently, for VoIP system administration sanity and cost practicality, a multi- vendor profile delivery standard is needed. This requirements document and protocol evaluation is a more formalized update to previous work in progress (e.g. expired draft draft-petrie-sip-config-framewk-reqs-00.txt) and evaluation performed by the authors. 3.2 Functional Groups The requirements for the configuration of a SIP user agent can be divided into the following high-level functions: ¸ Discovery ¸ Enrollment ¸ Profile Retrieval ¸ Change Notification ¸ Profile Upload ¸ Security ¸ Data Container These functional groups are intended only to provide a means to think about and organize the requirements. They are not required to be discrete steps, and they are not intended to dictate a specific model. Discovery û is the means by which a new SIP user agent can automatically discover how and where to enroll and retrieve desired device and user profile(s). Enrollment û is the means by which the user agent makes the profile server(s) aware of its presence and desire of specific users and/or device profiles. Petrie/Mahy Exp: Dec. 2002 [Page 3] xxxxx Profile Retrieval û is the means by which the user agent gets the desired profiles(s). Change Notification û is the means by which the profile server tells the user agent that profiles of interest have changed. Typically the intension would be for the user agent to get those changes or updated profiles. Profile Upload û this is the means by which the user agent or other entities in the network can update or propagate changes to a profile on the server. Security û primarily the focus is on protecting the profiles from unauthorized access or change as well as integrity. Data Container û the container or object model for the profile data during transport to and from the server. The primary issues are structure and hierarchy. Note: The specific content is considered out of scope in this document. The content requirements are addressed in [EP- CONFIG]. Ideally the container would be considered with the content requirements instead of the profile retrieval requirements. However as some of the protocols evaluated have an inherent data container the requirements are included in this document to keep the comparison on an apples-to-apples basis. 3.3 Terminology This document uses the following terminology: Server or Profile Server û the server(s) that provide the profile delivery framework functions defined above. User Agent or Device û the client wishing to get or update the user or device profile(s) as defined by the above functional framework. 4 Requirements The requirements are categorized by the functional groups defined in 3.2. In addition a general set requirements are defined up front. Each requirement is given a unique identifier for cross referencing. 4.1 General This section contains miscellaneous requirements across all functional groups. 4.1.1 Roaming GENRREQ-1: The profile delivery framework MUST support the ability for profiles to roam. Petrie/Mahy Exp: Dec. 2002 [Page 4] xxxxx That is, a user may go to another user agent within the serverÆs domain and with proper authorization, the user agent must be able to retrieve from the server and use the userÆs profile. 4.1.2 Open and Extensible for Vendor GENOREQ-10: The profile framework MUST allow vendor differentiation on both the server and user agent sides. This is largely an issue of how easy it is to make a more intelligent or active server or client without breaking the standard. GENOREQ-11: The profile server MUST be able to opaquely support vendor extensions to profiles. That is the server should be able to handle uploading of vendor specific data in a profile without requiring a new profile definition or schema. 4.1.3 NAT/Firewall Support There are two primary models in which VoIP systems are deployed: ¸ Hosted VoIP Services ("Centrex" Model) ¸ Locally Administered VoIP systems ("PBX" Model) In the extreme case of a hosted model, the only customer premises equipment is the LAN and user agents. In the locally administered model all equipment, servers, gateways and user agents are on the local premises. There is of course a spectrum of variations between. In addition there are multi-site enterprise deployments that in some aspects may appear more like the hosted model. The user agent in either model may be present in an commercial or in a residential environment. The primary issue relating to the profile delivery framework is the presence of NATs and/or firewalls between the profile server and the user agent. It is assumed that if NATs or firewalls are present (in between) the user agents are on the inside and the profile server is effectively on the outside (e.g. public Internet). GENNREQ-20: The user agent MUST be able to reach the profile server through a NAT or firewall to perform all of the functions in the delivery framework. GENNREQ-21: The firewall or NAT SHOULD not require any additional configuration to enable the profile delivery framework to work. It is assumed that certain protocols are typically enabled on the NAT or firewall by default (e.g. HTTP access to servers outside). It is assumed that SIP access in both directions is enabled or the user agent is not likely to be of much use. Petrie/Mahy Exp: Dec. 2002 [Page 5] xxxxx 4.1.4 Availability of Development Tools The platforms (server and user agent) upon which this profile delivery framework must be deployed are very different in capability. The user agents are largely embedded systems with limited resources for code and data size as well as CPU power (pure software based user agents are less constrained). The profile server is likely to run on general purpose servers and therefore not as resource constrained. For wide spread adoption of the profile delivery system, the tools protocol implementations required to build the profile server should be readily available. GENAREQ-30: The protocol stack implementations needed to build a profile server SHOULD be commercially and/or publicly available, preferably with reference or open-source implementations available. GENAREQ-31: There SHOULD be multiple implementations of the protocol stacks required in the profile server readily available. GENAREQ-32: There SHOULD be multiple implementations of the protocol stacks required in the user agent readily available. GENAREQ-33: There SHOULD be multiple implementations of the protocol stacks required in the user agent suitable for embedded systems. 4.2 Discovery The purpose of discovery is to provide the means by which zero or minimal user interaction is required when plugging in a user agent for the first time in a specific profile server domain. It is likely that there is no single protocol solution for discovery due to the wide variety of typical network configurations including but not limited to networks: not connected to the Internet with no DHCP server with no DNS SRV support with a non-configurable DNS server DISREQ-1: The user agent SHOULD be able to discover the profile server without human input. DISREQ-2: It MUST be possible to manually set the location of the profile server for a user agent. This is primarily a user agent implementation issue not a protocol issue. 4.3 Enrollment Petrie/Mahy Exp: Dec. 2002 [Page 6] xxxxx ENREQ-1: A user agent must be able to provide a unique identity to the profile server which does not change for the life of the UA. This allows user and device profiles to be associated with a particular user agent. ENREQ-2: A user agent requiring profiles SHOULD make itself known to the profile server. ENREQ-3: The user agent MUST identify profiles that it requires. ENREQ-4: The profile server MAY be provisioned to know what profiles a user agent needs by default. There are a number of reasons for the above requirements. In large scale deployments this may be important for load balancing purposes. This may be needed by the profile server so that it can understand which user agents are dependent upon which profiles. ENREQ-5: A user agent MAY request additional or different user profiles beyond the default provisioned for the user agent. This is primarily to support the notion of roaming. ENREQ-6: The user agent MUST provide specific information which may needed by the server to customize the profile(s) for the user agent. It may be necessary to provide different views of a profile based upon the specific configuration of the user agent. (for example, Vendor, Model number, Software or firmware version, serial number, MAC address, etc.). ENREQ-7: It SHOULD be possible for the profile server to deliver different views of a profile based upon characteristics of the user agent. Though the objective is to provide a standardized profile that has the same content for all vendors user agents, in reality there are changes or differences to work around. That is it may be desirable to put intelligence in the profile server to work around differences in user agent behavior or changes in the standardized profile content specification. ENREQ-8: It MUST be possible to reassigned device-specific profiles, stored in the server, to a different user agent. This is to facilitate hardware swap out. ENREQ-9: It MUST be possible for the profile server, over time, to change the location(s) from which configuration data is retrieved. The intension is to allow server handoff as the result of failure, administration changes, load balancing, etc. Petrie/Mahy Exp: Dec. 2002 [Page 7] xxxxx ENREQ-10: The user agent SHOULD re-enroll periodically. The user agent basically should check in periodically with the profile server in case a network problem prevented change notification from getting to the user agent. 4.4 Profile Retrieval PRREQ-1: It MUST be possible for the user agent to retrieve the profile(s) it requires on demand. PRREQ-2: It MUST be possible for the entire population of user agents to request and retrieve the required profiles in a short period of time. This is a scalability requirement: e.g. during a power outage tens or hundreds of thousands of user agents may power up at once. 4.5 Change Notification CNREQ-1: The profile server MUST be able to notify dependent user agents of profile changes. CNREQ-2: The user agent MUST be able to get the new updated profile. CNREQ-3: The server MAY specify in advance that a configuration change is to occur. That is the profile server may schedule changes. CNREQ-4: The user agent MAY defer making profile changes effective until it is safe to do so. Some profile changes may disrupt the operation of the user agent. The user agent should use discretion as to whether the change will disrupt critical operation (e.g. a call) of the user agent. [Should there be a means of specifying immediate or when safe?] 4.6 Profile Upload PUREQ-1: A user agent MUST be able to upload changes to a profile on the profile server. This is to facilitate changes made either via a user interface on the user agent which are desired to be permanent as well as a means by which a external interface (e.g. a rich GUI on a general purpose computer) may interface with the profile server. Petrie/Mahy Exp: Dec. 2002 [Page 8] xxxxx PUREQ-2: The profile server should provide an access control mechanism to constrain who can read, write, delete, or by notified about change to profile data. 4.7 Security User and device profiles may contain sensitive data such as passwords and identities. It MUST be possible to protect the profiles and information about the profiles. SECREQ-1: The profile server SHOULD not provide access to profile data without authentication and authorization. SECREQ-2: The profile server MUST not allow a user agent to update profile data without authentication and authorization. SECREQ-3: The profile data, when transmitted over the network, SHOULD be protected against man in the middle attacks and snooping. SECREQ-4: The profile server SHOULD not allow enrollment without authentication and authorization. SECREQ-5: The profile server SHOULD not provide change notification of profiles without authentication and authorization. SECREQ-6: The user agent SHOULD not interact with or trust any information from the profile server before authenticating the profile server. SECREQ-7: The information exchanged between the user agent and the profile server SHOULD be integrity protected. 4.8 Data Container DAREQ-1: The data container MUST support hierarchical and structured date. Note: for a better understanding of rational for this requirement see [EP-CONFIG] DAREQ-2: It MUST be possible to define a standardized set of profile data that all user agents SHOULD support. DAREQ-3: It MUST be possible for user agent vendors to add vendor specific data without breaking the standardized data set or requiring the creation of additional profiles. DAREQ-4: The data container MUST be flexible enough to contain additional data without breaking the profile server or the user agent. e.g. non-standard, vendor specific or standard updates DAREQ-5: The user agent must be able to determine the differences when a profile has changed. Petrie/Mahy Exp: Dec. 2002 [Page 9] xxxxx Note: this can be either by getting only the added, removed or changed data or by calculating the difference between two profiles. 5 Protocol Evaluation The following set of protocols are those that have been suggested for the purpose of SIP user agent profile delivery framework both on the SIP and SIPPING mailing lists as well as at past work group meetings. SNMP LDAP ACAP SLP SIP Events HTTP DHCP Options DNS XML RFC 822 This is of course not an exhaustive list of possible protocols, but a pragmatic list. 5.1 Evaluation Criteria The requirements defined in section 4 define a set of criteria for by which protocols may be evaluated for use in the profile delivery framework. The following table indicates the functional area for which the protocols are considered. This table indicates which requirements will be evaluated for each of the protocols. As no single protocol provides all of the functional areas, the objective is to find a small set of protocols that will best satisfy the requirements. All protocols are evaluated against the general requirements in section 4.1. SNMP LDAP ACAP SLP HTTP SIP XML 822 DHCP DNS Discovery X X X Enrollment X X X X Profile Retrieval X X X X Change Notification X X X Profile Upload X X X X Security X X X X X X Petrie/Mahy Exp: Dec. 2002 [Page 10] xxxxx Data Container X X X X X In each of the following subsections to section 5 a general over evaluation is made of the protocol. In addition the requirements which are NOT satisfied fully or as well as other protocols are explicitly listed or discussed. Those requirements that are satisfied are generally not explicitly called out or listed. 5.2 SNMP SNMPv3 [SNMP] is evaluated and referred to as SNMP in this document. SNMP has no discovery mechanism. General There are two aspects of the roaming requirement (GENRREQ-1), neither of which are solved very well by SNMP. - Physical relocation of a user agent in a different LAN - Users moving to a different user agent which subsequently requires a new user profile It is very difficult to support a user whose preferences are stored outside the local management domain. This physical relocation of a user agent (e.g. user agent on a laptop in a visited LAN) is a very desirable scenario. Because of its security model, SNMP does not work very well outside of its local domain. To support a user (one or more) temporarily using a user agent, the user agent would have to support the access of multiple, variable user profiles. MIBs do support the ability to have arrays or multiple instances of an object (typically leaf nodes). However MIBs do not support multiple instances of a hierarchy (e.g. multiple user profiles each with a hierarchy of content). It is difficult to make an active SNMP server. SNMP is primarily a push model. It is difficult to make an intelligent profile server where traps are not designed into the standard profile MIB (GENOREQ- 10). MIBs have a very rigid schema that makes it difficult to add vendor specific data without breaking the MIB or having to create a new MIB (GENOREQ-11). Supporting the vendor differentiation through MIBs would make management difficult. SNMP will not work through a NAT or firewall by default. It is also likely that a firewall administrator will have serious concerns letting SNMP traffic through their firewall. Enrollment ENREQ-5 has the same issues with multiple user profiles as described above for general requirement GENRREQ-1. Petrie/Mahy Exp: Dec. 2002 [Page 11] xxxxx ENREQ-7 has the same issues as GENOREQ-10 and GENOREQ-11 described above. Profile Retrieval As SNMP uses a push model, the user agent must throw a trap or inform to tell the server to push a profile to the user agent. In addition the issue with multiple user profiles, described above with GENRREQ-1, make it difficult to satisfy PRREQ-1. SNMP does not scale very well to individual dynamic nodes. It is difficult to build a system managing more than tens of thousands of users. User agents from some vendors do not have sufficient persistent memory to store a whole user or device profile. After a power outage tens or hundreds of thousands of user agents would all power up, throw traps requesting profiles. The push model of SNMP make it difficult to make changes from the user agent (PUREQ-2). A solution perhaps could be built using a trap. However this would not enable other entities (non-user agents) to set profile data. Change Notification There is no delayed setting of MIB data. A SNMP agent either accepts the change or rejects it immediately (CNREQ-3 and CNREQ-4). Data Container DAREQ-3 and DAREQ-4 are not well supported due to the rigid nature of MIBs described above relative to GENOREQ-11. 5.3 LDAP The authors did not have sufficient time to complete a thorough evaluation of LDAP. 5.4 ACAP General ACAP was not designed to be active on the server side. It has more of a database model. It is probably possible to make the data access active or intelligent, however this is make more difficult by the lack of implementations (GENOREQ-10). ACAP [ACAP] over TLS [ACAP-TLS] is evaluated to satisfy the security requirements. The authors were not able to find a commercially or publicly available version of ACAP written in C, C++ or Java (GENAREQ-30, GENAREQ-31, GENAREQ-32, GENAREQ-33). ACAP does not support any discovery mechanism and was not evaluated for this functional area. Petrie/Mahy Exp: Dec. 2002 [Page 12] xxxxx Enrollment Due to the difficulty of making the profile server active for Change Notification (as described above in the general requirements evaluation of ACAP), it is also difficult to provide different views of data based upon characteristics of the user agent (ENREQ-7). The different views would have to be designed into the schema requiring coordination on both the user agent and server sides. Without an event mechanism (see below) or a means to redirect profile data requests to another server it is difficult to re-assign a user agent to an alternative ACAP server (ENREQ-9). Change Notification ACAP does not support an event mechanism. It uses a polling model. This makes it difficult to make profile data changes effective immediately. A very short polling time must be used which does not scale well with large numbers of user agents. Alternatively with a longer pooling period, user agents will be slow to make the profile changes effective (CNREQ-1, CNREQ-2, CNREQ-3 and CNREQ-4). Profile Retrieval ACAP meets the requirements for profile retrieval. Profile Upload ACAP provides a means of updating the profile data with access control. Security Security is provided via TLS. Data Container ACAP does have a rich hierarchal structure for containing profile data. In addition it has a powerful means of describing access control and modification time stamping of data. 5.5 SLP SLP [SLP] is primarily a LAN based solution for discovery of services. It allows the discovery of URL or server and port for a well named service. SLP is not appropriate for profile retrieval, change notification or profile update. Nor does it provide a data container. General As SLP is primarily for LAN based discovery where roaming functionality is not applicable (GENRREQ-1). Likewise vendor Petrie/Mahy Exp: Dec. 2002 [Page 13] xxxxx differentiation in the server and user agent are less applicable (GENOREQ-10 and GENOREQ-11). It is difficult to make SLP work through NATs or firewalls (GENNREQ- 20, GENNREQ-21). Enrollment The ability to provision or create active responses to user agent request makes ENREQ-3, ENREQ-4, ENREQ-5 and ENREQ-6 more appropriately performed with protocols other than SLP. As SLP does not get involved with the profile retrieval, update or change notification enrollment requirements: ENREQ-7, ENREQ-8, ENREQ-9 and ENREQ-10 are not applicable to SLP. Security For the above reason security requirements: SECREQ-1, SECREQ-2, SECREQ-3 and SECREQ-5 are also not applicable. SLP does not authenticate or authorize the user agent. It assumes that is preformed by the server performing the profile retrieval, upload and change notification functions (SECREQ-4). 5.6 SIP Events The only appropriate use of SIP is for its event mechanism [SIP- EVENTS]. SIP is evaluated assuming SIPS and S/MIME [SIP] support for the security functionality. SIP provides a very powerful event framework through the SUBSCRIBE and NOTIFY messages. SIP is not appropriate for profile retrieval or upload. It is not a data transport protocol. Nor does SIP provide a data container. SIP does support multicast that could be used as a discovery mechanism. However it is not evaluated for discovery features. General The primary requirement for vendor differentiation is in the enrollment, profile retrieval, update and change notification. SIP does allow active server and client side components. However this is not considered necessary for this requirement (GENOREQ-10) and considered not applicable. As SIP is not consider appropriate for profile retrieval or upload it is consider not applicable to GENOREQ-11. Enrollment The SIP SUBSCRIBE mechanism of [SIP-EVENTS] satisfies all of the enrolloment functional requirements. Petrie/Mahy Exp: Dec. 2002 [Page 14] xxxxx Change Notification CNREQ-2 is not applicable to SIP. It is more related to the profile retrieval mechanism used. The deferral of making profile changes effective is a user agent implementation issue in the context of [SIP-EVENTS]. CNREQ-4 is considered to be not applicable to SIP. Security As SIP is not proposed as a data transport for profile data SECREQ-2 and SECREQ-3 are not applicable. The security capabilities of [SIP] are considered to satisfy the other security requirements. 5.7 HTTP HTTP [HTTP] is considered for the purpose of transporting the data profiles (profile retrieval and upload). To satisfy the security requirements [HTTPS] is assumed. General As HTTP is used primarily for transport GENOREQ-11 is consider to be non-applicable. However active HTTP pages could be used to help support this requirement. Enrollment Enrollment is considered to be mostly not applicable to the proposed use of HTTP. However ENREQ-7 can be satisfied as part of profile retrieval. This would require active pages on the profile server. Profile Retrieval HTTP satisfies all of the profile retrieval requirements. Change Notification Enrollment is considered to be mostly not applicable to the proposed use of HTTP. However CNREQ-2 can be satisfied as profile retrieval. Profile Upload HTTP provides gross level access control of profile. However to get atomic level access control on elements of the profile data requires the development of active pages on the profile server (PUREQ-2). Security Petrie/Mahy Exp: Dec. 2002 [Page 15] xxxxx The security capabilities of [HTTPS] are considered to satisfy the security requirements. 5.8 DHCP Options [SIP-DHCP] General Discovery 5.9 DNS [DNS] [DNSSRV] General Discovery 5.10 XML General Data Container 5.11 RFC 822 General Data Container 6 Security Considerations Security considerations are covered in section 4.7. 7 Conclusion The following tables rate the protocols according the the requirements. The rating indcates how well the protocol satisfies the requirment. The notation used is defined as follows: No : No support of requirement L : Low suppport of requirement H : High support of requirement - : Not applicable to requirement SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS GENRREQ-1 No H - H H - - - - GENOREQ-10 L L - H - - - - - GENOREQ-11 L H - - - H M - - GENNREQ-20 L H L H H - - - H GENNREQ-21 No H L H H - - - H GENAREQ-30 H L L H H H H H H GENAREQ-31 H L L H H H H H H Petrie/Mahy Exp: Dec. 2002 [Page 16] xxxxx GENAREQ-32 H L L H H H H H H GENAREQ-33 L L L H H H H H H DISREQ-1 H H H DISREQ-2 - - - ENREQ-1 H H H H ENREQ-2 H H H H ENREQ-3 H H L H ENREQ-4 H H L H ENREQ-5 L H L H ENREQ-6 H H No H ENREQ-7 L L - H*1 H ENREQ-8 H H - H ENREQ-9 H No - H ENREQ-10 H H - H *1 Note: this capability could be provided either as part of enrollment or profile retrieval. Therefore HTTP is evaluated here as providing ENREQ-7 as part of profile retrieval. SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS PRREQ-1 L H H PRREQ-2 L L H CNREQ-1 H No H CNREQ-2 H No H*2 - CNREQ-3 No No H CNREQ-4 L No - *2 Note: this capability could be provided either as part of change notification or profile retrieval. Therefore HTTP is evaluated here as providing CNREQ-2 as part of profile retrieval. SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS PUREQ-1 H H H PUREQ-2 L H L SECREQ-1 H H - H H SECREQ-2 H H - H - SECREQ-3 H H - H - SECREQ-4 H H No H H SECREQ-5 H - - H H SECREQ-6 H H H H H SECREQ-7 H H H H H DAREQ-1 H H H L DAREQ-2 - - - - DAREQ-3 L H H H DAREQ-4 L H H H DAREQ-5 H H H H Petrie/Mahy Exp: Dec. 2002 [Page 17] xxxxx The discovery solution is best addressed separately. Due to the varied nature of most network environments, there is no single solution that will work everywhere. It is probably necessary to support multiple protocols. Due to the widespread deployment and use of DHCP and DNS they are the best two candidates for discovery, although SLP can be used in network that already support it. The data container requirements are equally satisfied by XML and ACAP largely due to their ability to support an extensible, hierarchal schema. XML seems to have an advantage as well based on the wide spread availability of development tools that operate on XML. Both ACAP and HTTP address the profile retrieval and upload requirements, although the relative maturity of XML over HTTP is very attractive. SIP is the only protocol that addressed all the relevant enrollment and change control requirements.There was no single protocol that satisfied all of the requirements in the other functional areas. However a combination of HTTP and SIP satisfies all of the remaining requirements to a high degree. In addition the large number of implementations and development tools make this combination the most attractive solution. The development as well as end user (e.g. administrator) skill sets are much more readily available for these protocols as well. As a second choice ACAP and SIP seems to be the only other reasonable combination. 8 References [SIP] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session Initiation Protocol", RFC2543, Internet Engineering Task Force, Nov 1998. [SIP] draft-ietf-sip-rfc2543bis-09.txt [RFC2026] S Bradner, "The Internet Standards Process -- Revision 3", RFC2026 (BCP), IETF, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels," Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, Mar. 1997. [HTTP] R. Fielding et al, ôHypertext Transfer Protocol -- HTTP/1.1ö, Request for Comments (Standards Track) 2616, Internet Engineering Task Force, June 1999 [HTTPS] E. Rescorla, ôHTTP Over TLSö, Request for Comments 2818, Internet Engineering Task Force, May 2000 [TLS] T. Dierks, C. Allen, ôThe TLS Protocol Version 1.0ö, Request for Comments 2246, Internet Engineering Task Force, Jan. 1999 Petrie/Mahy Exp: Dec. 2002 [Page 18] xxxxx [EP-CONFIG] draft-stredicke-sipping-ep-config-00.txt [SNMP] Request for Comments 2570-2576, Internet Engineering Task Force [ACAP] Request for Comments 2244, Internet Engineering Task Force [ACAP-TLS] Request for Comments 2595, Internet Engineering Task Force [SLP] Request for Comments 2608, Internet Engineering Task Force [SIP-EVENTS] A. Roach, ôEvent Notification in SIPö, , IETF; February 2002, Work in progress. [DHCP] S. Alexander and R. Droms, "DHCP options and BOOTP vendor extensions," Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, Mar. 1997. [SIP-DHCP] G.Nair, H.Schulzrinne , ôDHCP Option for SIP Serversö, , IETF; March 1, 2002, Work in progress. [DNSSRV] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) DNS resource record," Request for Comments 2915, Internet Engineering Task Force, Sept. 2000. [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, October 2000, [RFC822] D. Crocker, ôSTANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGESö, Request for Comments 822, Internet Engineering Task Force, Aug. 1982 [UA-PROF-FRAMEWORK] draft-petrie-sipping-config-framework-00.txt 9 Acknowledgments Thanks to Henry Sinnreich and Henning Schulzrinne for their input and review of this document. 10 Author's Addresses Daniel G. Petrie Pingtel Corp. 400 W. Cummings Park Suite 2200 Woburn, MA 01801 USA Phone: +1 781 938 5306 Email: dpetrie@pingtel.com Petrie/Mahy Exp: Dec. 2002 [Page 19] xxxxx Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/3 San Jose, CA 95134 USA Phone: +1 408 527-9132 EMail: fluffy@cisco.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Petrie/Mahy Exp: Dec. 2002 [Page 20]