idnits 2.17.1 draft-petrie-sipping-ua-prof-framewk-reqs-00.txt: ** The Abstract section seems to be numbered -(147): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(955): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(971): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 28 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 3) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: GENNREQ-21: The firewall or NAT SHOULD not require any additional configuration to enable the profile delivery framework to work. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SECREQ-1: The profile server SHOULD not provide access to profile data without authentication and authorization. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: SECREQ-2: The profile server MUST not allow a user agent to update profile data without authentication and authorization. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SECREQ-4: The profile server SHOULD not allow enrollment without authentication and authorization. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SECREQ-5: The profile server SHOULD not provide change notification of profiles without authentication and authorization. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: SECREQ-6: The user agent SHOULD not interact with or trust any information from the profile server before authenticating the profile server. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DNS' is mentioned on line 812, but not defined == Unused Reference: 'TLS' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'DHCP' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 985, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'UA-PROF-FRAMEWORK' is defined on line 994, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (ref. 'HTTPS') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Possible downref: Normative reference to a draft: ref. 'EP-CONFIG' ** Obsolete normative reference: RFC 2570 (ref. 'SNMP') (Obsoleted by RFC 3410) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIP-EVENTS' -- Possible downref: Non-RFC (?) normative reference: ref. 'SIP-DHCP' ** Obsolete normative reference: RFC 2915 (ref. 'DNSSRV') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) -- Possible downref: Normative reference to a draft: ref. 'UA-PROF-FRAMEWORK' Summary: 13 errors (**), 0 flaws (~~), 16 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft D. Petrie 3 Doc: draft-petrie-sipping-ua-prof-framewk-reqs-00.txt Pingtel Corp. 4 24 June 2002 C. Jennings 5 Expires: December 2002 Cisco Systems 7 Requirements for SIP User Agent Profile Delivery Framework 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- Drafts 20 as reference material or to cite them other than as "work in 21 progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1 Abstract 29 This document attempts to identify the requirements for a protocol 30 framework to provide SIP user and device profiles to SIP user 31 agents. The objective is not to invent new special purpose 32 protocols, but to identify the requirements such that a rational 33 decision can be made as to what existing protocol(s) should be used 34 to solve the problem of providing user and device profiles to SIP 35 user agents. This document also contains an evaluation of a set of 36 applicable protocols. 38 2 Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" this 42 document are to be interpreted as described in RFC-2119 [RFC2119]. 44 xxxxx 46 Table of Contents 47 1 Abstract.......................................................1 48 2 Conventions used in this document..............................1 49 3 Overview.......................................................3 50 3.1 Background.....................................................3 51 3.2 Functional Groups..............................................3 52 3.3 Terminology....................................................4 53 4 Requirements...................................................4 54 4.1 General........................................................4 55 4.1.1 Roaming......................................................4 56 4.1.2 Open and Extensible for Vendor...............................5 57 4.1.3 NAT/Firewall Support.........................................5 58 4.1.4 Availability of Development Tools............................6 59 4.2 Discovery......................................................6 60 4.3 Enrollment.....................................................6 61 4.4 Profile Retrieval..............................................8 62 4.5 Change Notification............................................8 63 4.6 Profile Upload.................................................8 64 4.7 Security.......................................................9 65 4.8 Data Container.................................................9 66 5 Protocol Evaluation...........................................10 67 5.1 Evaluation Criteria...........................................10 68 5.2 SNMP..........................................................11 69 5.3 LDAP..........................................................12 70 5.4 ACAP..........................................................12 71 5.5 SLP...........................................................13 72 5.6 SIP Events....................................................14 73 5.7 HTTP..........................................................15 74 5.8 DHCP Options..................................................16 75 5.9 DNS...........................................................16 76 5.10 XML..........................................................16 77 5.11 RFC 822......................................................16 78 6 Security Considerations.......................................16 79 7 Conclusion....................................................16 80 8 References....................................................18 81 9 Acknowledgments...............................................19 82 10 Author's Addresses............................................19 83 xxxxx 85 3 Overview 87 3.1 Background 89 There is a general need to standardize methods for adding, enabling, 90 and maintaining user and device profiles used by SIP user agents 91 within a VoIP system. When one considers the effort needed to set up 92 systems with hundreds or thousands of users and user agents, the 93 need for reducing set up time is obvious. After a system is set up, 94 ongoing maintenance in the form of changing the user and device 95 profiles on a large population of user agents, is likely to be 96 necessary and requires a similar administrative effort. 98 In addition to these scaling problems, it is likely that the 99 population of user agents in any given VoIP system will be 100 heterogeneous: the configuration strategy must be flexible enough to 101 accommodate different needs for different users. Consequently, for 102 VoIP system administration sanity and cost practicality, a multi- 103 vendor profile delivery standard is needed. 104 This requirements document and protocol evaluation is a more 105 formalized update to previous work in progress (e.g. expired draft 106 draft-petrie-sip-config-framewk-reqs-00.txt) and evaluation 107 performed by the authors. 109 3.2 Functional Groups 111 The requirements for the configuration of a SIP user agent can be 112 divided into the following high-level functions: 114 � 115 Discovery 116 � 117 Enrollment 118 � 119 Profile Retrieval 120 � 121 Change Notification 122 � 123 Profile Upload 124 � 125 Security 126 � 127 Data Container 129 These functional groups are intended only to provide a means to 130 think about and organize the requirements. They are not required to 131 be discrete steps, and they are not intended to dictate a specific 132 model. 134 Discovery � is the means by which a new SIP user agent can 135 automatically discover how and where to enroll and retrieve desired 136 device and user profile(s). 138 Enrollment � is the means by which the user agent makes the profile 139 server(s) aware of its presence and desire of specific users and/or 140 device profiles. 142 xxxxx 144 Profile Retrieval � is the means by which the user agent gets the 145 desired profiles(s). 147 Change Notification � is the means by which the profile server tells 148 the user agent that profiles of interest have changed. Typically 149 the intension would be for the user agent to get those changes or 150 updated profiles. 152 Profile Upload � this is the means by which the user agent or other 153 entities in the network can update or propagate changes to a profile 154 on the server. 156 Security � primarily the focus is on protecting the profiles from 157 unauthorized access or change as well as integrity. 159 Data Container � the container or object model for the profile data 160 during transport to and from the server. The primary issues are 161 structure and hierarchy. 163 Note: The specific content is considered out of scope in this 164 document. The content requirements are addressed in [EP- 165 CONFIG]. Ideally the container would be considered with the 166 content requirements instead of the profile retrieval 167 requirements. However as some of the protocols evaluated have 168 an inherent data container the requirements are included in this 169 document to keep the comparison on an apples-to-apples basis. 171 3.3 Terminology 173 This document uses the following terminology: 175 Server or Profile Server � the server(s) that provide the profile 176 delivery framework functions defined above. 178 User Agent or Device � the client wishing to get or update the user 179 or device profile(s) as defined by the above functional framework. 181 4 Requirements 183 The requirements are categorized by the functional groups defined in 184 3.2. In addition a general set requirements are defined up front. 185 Each requirement is given a unique identifier for cross referencing. 187 4.1 General 189 This section contains miscellaneous requirements across all 190 functional groups. 191 4.1.1 Roaming 193 GENRREQ-1: The profile delivery framework MUST support the ability 194 for profiles to roam. 196 xxxxx 198 That is, a user may go to another user agent within the server�s 199 domain and with proper authorization, the user agent must be able to 200 retrieve from the server and use the user�s profile. 202 4.1.2 Open and Extensible for Vendor 204 GENOREQ-10: The profile framework MUST allow vendor differentiation 205 on both the server and user agent sides. 207 This is largely an issue of how easy it is to make a more 208 intelligent or active server or client without breaking the 209 standard. 211 GENOREQ-11: The profile server MUST be able to opaquely support 212 vendor extensions to profiles. 214 That is the server should be able to handle uploading of vendor 215 specific data in a profile without requiring a new profile 216 definition or schema. 218 4.1.3 NAT/Firewall Support 220 There are two primary models in which VoIP systems are deployed: 222 � 223 Hosted VoIP Services ("Centrex" Model) 224 � 225 Locally Administered VoIP systems ("PBX" Model) 227 In the extreme case of a hosted model, the only customer premises 228 equipment is the LAN and user agents. In the locally administered 229 model all equipment, servers, gateways and user agents are on the 230 local premises. There is of course a spectrum of variations 231 between. In addition there are multi-site enterprise deployments 232 that in some aspects may appear more like the hosted model. The 233 user agent in either model may be present in an commercial or in a 234 residential environment. 236 The primary issue relating to the profile delivery framework is the 237 presence of NATs and/or firewalls between the profile server and the 238 user agent. It is assumed that if NATs or firewalls are present (in 239 between) the user agents are on the inside and the profile server is 240 effectively on the outside (e.g. public Internet). 242 GENNREQ-20: The user agent MUST be able to reach the profile server 243 through a NAT or firewall to perform all of the functions in the 244 delivery framework. 246 GENNREQ-21: The firewall or NAT SHOULD not require any additional 247 configuration to enable the profile delivery framework to work. 249 It is assumed that certain protocols are typically enabled on 250 the NAT or firewall by default (e.g. HTTP access to servers 251 outside). It is assumed that SIP access in both directions is 252 enabled or the user agent is not likely to be of much use. 254 xxxxx 256 4.1.4 Availability of Development Tools 258 The platforms (server and user agent) upon which this profile 259 delivery framework must be deployed are very different in 260 capability. The user agents are largely embedded systems with 261 limited resources for code and data size as well as CPU power (pure 262 software based user agents are less constrained). The profile 263 server is likely to run on general purpose servers and therefore not 264 as resource constrained. 266 For wide spread adoption of the profile delivery system, the tools 267 protocol implementations required to build the profile server should 268 be readily available. 270 GENAREQ-30: The protocol stack implementations needed to build a 271 profile server SHOULD be commercially and/or publicly available, 272 preferably with reference or open-source implementations available. 274 GENAREQ-31: There SHOULD be multiple implementations of the protocol 275 stacks required in the profile server readily available. 277 GENAREQ-32: There SHOULD be multiple implementations of the protocol 278 stacks required in the user agent readily available. 280 GENAREQ-33: There SHOULD be multiple implementations of the protocol 281 stacks required in the user agent suitable for embedded systems. 283 4.2 Discovery 285 The purpose of discovery is to provide the means by which zero or 286 minimal user interaction is required when plugging in a user agent 287 for the first time in a specific profile server domain. It is 288 likely that there is no single protocol solution for discovery due 289 to the wide variety of typical network configurations including but 290 not limited to networks: 291 not connected to the Internet 292 with no DHCP server 293 with no DNS SRV support 294 with a non-configurable DNS server 296 DISREQ-1: The user agent SHOULD be able to discover the profile 297 server without human input. 299 DISREQ-2: It MUST be possible to manually set the location of the 300 profile server for a user agent. 302 This is primarily a user agent implementation issue not a 303 protocol issue. 305 4.3 Enrollment 306 xxxxx 308 ENREQ-1: A user agent must be able to provide a unique identity to 309 the profile server which does not change for the life of the UA. 311 This allows user and device profiles to be associated with a 312 particular user agent. 314 ENREQ-2: A user agent requiring profiles SHOULD make itself known to 315 the profile server. 317 ENREQ-3: The user agent MUST identify profiles that it requires. 319 ENREQ-4: The profile server MAY be provisioned to know what profiles 320 a user agent needs by default. 322 There are a number of reasons for the above requirements. In 323 large scale deployments this may be important for load balancing 324 purposes. This may be needed by the profile server so that it 325 can understand which user agents are dependent upon which 326 profiles. 328 ENREQ-5: A user agent MAY request additional or different user 329 profiles beyond the default provisioned for the user agent. 331 This is primarily to support the notion of roaming. 333 ENREQ-6: The user agent MUST provide specific information which may 334 needed by the server to customize the profile(s) for the user agent. 336 It may be necessary to provide different views of a profile 337 based upon the specific configuration of the user agent. (for 338 example, Vendor, Model number, Software or firmware version, 339 serial number, MAC address, etc.). 341 ENREQ-7: It SHOULD be possible for the profile server to deliver 342 different views of a profile based upon characteristics of the user 343 agent. 345 Though the objective is to provide a standardized profile that 346 has the same content for all vendors user agents, in reality 347 there are changes or differences to work around. That is it may 348 be desirable to put intelligence in the profile server to work 349 around differences in user agent behavior or changes in the 350 standardized profile content specification. 352 ENREQ-8: It MUST be possible to reassigned device-specific profiles, 353 stored in the server, to a different user agent. 355 This is to facilitate hardware swap out. 357 ENREQ-9: It MUST be possible for the profile server, over time, to 358 change the location(s) from which configuration data is retrieved. 360 The intension is to allow server handoff as the result of 361 failure, administration changes, load balancing, etc. 363 xxxxx 365 ENREQ-10: The user agent SHOULD re-enroll periodically. 367 The user agent basically should check in periodically with the 368 profile server in case a network problem prevented change 369 notification from getting to the user agent. 371 4.4 Profile Retrieval 373 PRREQ-1: It MUST be possible for the user agent to retrieve the 374 profile(s) it requires on demand. 376 PRREQ-2: It MUST be possible for the entire population of user 377 agents to request and retrieve the required profiles in a short 378 period of time. 380 This is a scalability requirement: e.g. during a power outage 381 tens or hundreds of thousands of user agents may power up at 382 once. 384 4.5 Change Notification 386 CNREQ-1: The profile server MUST be able to notify dependent user 387 agents of profile changes. 389 CNREQ-2: The user agent MUST be able to get the new updated profile. 391 CNREQ-3: The server MAY specify in advance that a configuration 392 change is to occur. 394 That is the profile server may schedule changes. 396 CNREQ-4: The user agent MAY defer making profile changes effective 397 until it is safe to do so. 399 Some profile changes may disrupt the operation of the user 400 agent. The user agent should use discretion as to whether the 401 change will disrupt critical operation (e.g. a call) of the user 402 agent. [Should there be a means of specifying immediate or when 403 safe?] 405 4.6 Profile Upload 407 PUREQ-1: A user agent MUST be able to upload changes to a profile on 408 the profile server. 410 This is to facilitate changes made either via a user interface 411 on the user agent which are desired to be permanent as well as a 412 means by which a external interface (e.g. a rich GUI on a 413 general purpose computer) may interface with the profile 414 server. 416 xxxxx 418 PUREQ-2: The profile server should provide an access control 419 mechanism to constrain who can read, write, delete, or by 420 notified about change to profile data. 422 4.7 Security 424 User and device profiles may contain sensitive data such as 425 passwords and identities. It MUST be possible to protect the 426 profiles and information about the profiles. 428 SECREQ-1: The profile server SHOULD not provide access to profile 429 data without authentication and authorization. 431 SECREQ-2: The profile server MUST not allow a user agent to update 432 profile data without authentication and authorization. 434 SECREQ-3: The profile data, when transmitted over the network, 435 SHOULD be protected against man in the middle attacks and snooping. 437 SECREQ-4: The profile server SHOULD not allow enrollment without 438 authentication and authorization. 440 SECREQ-5: The profile server SHOULD not provide change notification 441 of profiles without authentication and authorization. 443 SECREQ-6: The user agent SHOULD not interact with or trust any 444 information from the profile server before authenticating the 445 profile server. 447 SECREQ-7: The information exchanged between the user agent and the 448 profile server SHOULD be integrity protected. 450 4.8 Data Container 452 DAREQ-1: The data container MUST support hierarchical and structured 453 date. Note: for a better understanding of rational for this 454 requirement see [EP-CONFIG] 456 DAREQ-2: It MUST be possible to define a standardized set of profile 457 data that all user agents SHOULD support. 459 DAREQ-3: It MUST be possible for user agent vendors to add vendor 460 specific data without breaking the standardized data set or 461 requiring the creation of additional profiles. 463 DAREQ-4: The data container MUST be flexible enough to contain 464 additional data without breaking the profile server or the user 465 agent. 467 e.g. non-standard, vendor specific or standard updates 469 DAREQ-5: The user agent must be able to determine the differences 470 when a profile has changed. 472 xxxxx 474 Note: this can be either by getting only the added, removed or 475 changed data or by calculating the difference between two 476 profiles. 478 5 Protocol Evaluation 480 The following set of protocols are those that have been suggested 481 for the purpose of SIP user agent profile delivery framework both on 482 the SIP and SIPPING mailing lists as well as at past work group 483 meetings. 485 SNMP 486 LDAP 487 ACAP 488 SLP 489 SIP Events 490 HTTP 491 DHCP Options 492 DNS 493 XML 494 RFC 822 496 This is of course not an exhaustive list of possible protocols, but 497 a pragmatic list. 499 5.1 Evaluation Criteria 501 The requirements defined in section 4 define a set of criteria for 502 by which protocols may be evaluated for use in the profile delivery 503 framework. 505 The following table indicates the functional area for which the 506 protocols are considered. This table indicates which requirements 507 will be evaluated for each of the protocols. As no single protocol 508 provides all of the functional areas, the objective is to find a 509 small set of protocols that will best satisfy the requirements. All 510 protocols are evaluated against the general requirements in section 511 4.1. 513 SNMP LDAP ACAP SLP HTTP SIP XML 822 DHCP DNS 514 Discovery X X X 516 Enrollment X X X X 518 Profile Retrieval X X X X 520 Change Notification X X X 522 Profile Upload X X X X 524 Security X X X X X X 525 xxxxx 527 Data Container X X X X X 529 In each of the following subsections to section 5 a general over 530 evaluation is made of the protocol. In addition the requirements 531 which are NOT satisfied fully or as well as other protocols are 532 explicitly listed or discussed. Those requirements that are 533 satisfied are generally not explicitly called out or listed. 535 5.2 SNMP 537 SNMPv3 [SNMP] is evaluated and referred to as SNMP in this document. 538 SNMP has no discovery mechanism. 540 General 542 There are two aspects of the roaming requirement (GENRREQ-1), 543 neither of which are solved very well by SNMP. 544 - Physical relocation of a user agent in a different LAN 545 - Users moving to a different user agent which subsequently 546 requires a new user profile 548 It is very difficult to support a user whose preferences are stored 549 outside the local management domain. This physical relocation of a 550 user agent (e.g. user agent on a laptop in a visited LAN) is a very 551 desirable scenario. Because of its security model, SNMP does not 552 work very well outside of its local domain. 554 To support a user (one or more) temporarily using a user agent, the 555 user agent would have to support the access of multiple, variable 556 user profiles. MIBs do support the ability to have arrays or 557 multiple instances of an object (typically leaf nodes). However 558 MIBs do not support multiple instances of a hierarchy (e.g. multiple 559 user profiles each with a hierarchy of content). 561 It is difficult to make an active SNMP server. SNMP is primarily a 562 push model. It is difficult to make an intelligent profile server 563 where traps are not designed into the standard profile MIB (GENOREQ- 564 10). 566 MIBs have a very rigid schema that makes it difficult to add vendor 567 specific data without breaking the MIB or having to create a new MIB 568 (GENOREQ-11). Supporting the vendor differentiation through MIBs 569 would make management difficult. 571 SNMP will not work through a NAT or firewall by default. It is also 572 likely that a firewall administrator will have serious concerns 573 letting SNMP traffic through their firewall. 575 Enrollment 577 ENREQ-5 has the same issues with multiple user profiles as described 578 above for general requirement GENRREQ-1. 580 xxxxx 582 ENREQ-7 has the same issues as GENOREQ-10 and GENOREQ-11 described 583 above. 585 Profile Retrieval 587 As SNMP uses a push model, the user agent must throw a trap or 588 inform to tell the server to push a profile to the user agent. In 589 addition the issue with multiple user profiles, described above with 590 GENRREQ-1, make it difficult to satisfy PRREQ-1. 592 SNMP does not scale very well to individual dynamic nodes. It is 593 difficult to build a system managing more than tens of thousands of 594 users. User agents from some vendors do not have sufficient 595 persistent memory to store a whole user or device profile. After a 596 power outage tens or hundreds of thousands of user agents would all 597 power up, throw traps requesting profiles. 599 The push model of SNMP make it difficult to make changes from the 600 user agent (PUREQ-2). A solution perhaps could be built using a 601 trap. However this would not enable other entities (non-user 602 agents) to set profile data. 604 Change Notification 606 There is no delayed setting of MIB data. A SNMP agent either 607 accepts the change or rejects it immediately (CNREQ-3 and CNREQ-4). 609 Data Container 610 DAREQ-3 and DAREQ-4 are not well supported due to the rigid nature 611 of MIBs described above relative to GENOREQ-11. 613 5.3 LDAP 615 The authors did not have sufficient time to complete a thorough 616 evaluation of LDAP. 618 5.4 ACAP 620 General 622 ACAP was not designed to be active on the server side. It has more 623 of a database model. It is probably possible to make the data 624 access active or intelligent, however this is make more difficult by 625 the lack of implementations (GENOREQ-10). 627 ACAP [ACAP] over TLS [ACAP-TLS] is evaluated to satisfy the security 628 requirements. The authors were not able to find a commercially or 629 publicly available version of ACAP written in C, C++ or Java 630 (GENAREQ-30, GENAREQ-31, GENAREQ-32, GENAREQ-33). 632 ACAP does not support any discovery mechanism and was not evaluated 633 for this functional area. 635 xxxxx 637 Enrollment 639 Due to the difficulty of making the profile server active for 640 Change Notification (as described above in the general requirements 641 evaluation of ACAP), it is also difficult to provide different views 642 of data based upon characteristics of the user agent (ENREQ-7). The 643 different views would have to be designed into the schema requiring 644 coordination on both the user agent and server sides. 646 Without an event mechanism (see below) or a means to redirect 647 profile data requests to another server it is difficult to re-assign 648 a user agent to an alternative ACAP server (ENREQ-9). 650 Change Notification 652 ACAP does not support an event mechanism. It uses a polling model. 653 This makes it difficult to make profile data changes effective 654 immediately. A very short polling time must be used which does not 655 scale well with large numbers of user agents. Alternatively with a 656 longer pooling period, user agents will be slow to make the profile 657 changes effective (CNREQ-1, CNREQ-2, CNREQ-3 and CNREQ-4). 659 Profile Retrieval 661 ACAP meets the requirements for profile retrieval. 663 Profile Upload 665 ACAP provides a means of updating the profile data with access 666 control. 668 Security 670 Security is provided via TLS. 672 Data Container 674 ACAP does have a rich hierarchal structure for containing profile 675 data. In addition it has a powerful means of describing access 676 control and modification time stamping of data. 678 5.5 SLP 680 SLP [SLP] is primarily a LAN based solution for discovery of 681 services. It allows the discovery of URL or server and port for a 682 well named service. SLP is not appropriate for profile retrieval, 683 change notification or profile update. Nor does it provide a data 684 container. 686 General 688 As SLP is primarily for LAN based discovery where roaming 689 functionality is not applicable (GENRREQ-1). Likewise vendor 690 xxxxx 692 differentiation in the server and user agent are less applicable 693 (GENOREQ-10 and GENOREQ-11). 695 It is difficult to make SLP work through NATs or firewalls (GENNREQ- 696 20, GENNREQ-21). 698 Enrollment 700 The ability to provision or create active responses to user agent 701 request makes ENREQ-3, ENREQ-4, ENREQ-5 and ENREQ-6 more 702 appropriately performed with protocols other than SLP. 704 As SLP does not get involved with the profile retrieval, update or 705 change notification enrollment requirements: ENREQ-7, ENREQ-8, 706 ENREQ-9 and ENREQ-10 are not applicable to SLP. 708 Security 710 For the above reason security requirements: SECREQ-1, SECREQ-2, 711 SECREQ-3 and SECREQ-5 are also not applicable. 713 SLP does not authenticate or authorize the user agent. It assumes 714 that is preformed by the server performing the profile retrieval, 715 upload and change notification functions (SECREQ-4). 717 5.6 SIP Events 719 The only appropriate use of SIP is for its event mechanism [SIP- 720 EVENTS]. SIP is evaluated assuming SIPS and S/MIME [SIP] support 721 for the security functionality. SIP provides a very powerful event 722 framework through the SUBSCRIBE and NOTIFY messages. 724 SIP is not appropriate for profile retrieval or upload. It is not a 725 data transport protocol. Nor does SIP provide a data container. 726 SIP does support multicast that could be used as a discovery 727 mechanism. However it is not evaluated for discovery features. 729 General 731 The primary requirement for vendor differentiation is in the 732 enrollment, profile retrieval, update and change notification. SIP 733 does allow active server and client side components. However this 734 is not considered necessary for this requirement (GENOREQ-10) and 735 considered not applicable. 737 As SIP is not consider appropriate for profile retrieval or upload 738 it is consider not applicable to GENOREQ-11. 740 Enrollment 742 The SIP SUBSCRIBE mechanism of [SIP-EVENTS] satisfies all of the 743 enrolloment functional requirements. 745 xxxxx 747 Change Notification 749 CNREQ-2 is not applicable to SIP. It is more related to the profile 750 retrieval mechanism used. 752 The deferral of making profile changes effective is a user agent 753 implementation issue in the context of [SIP-EVENTS]. CNREQ-4 is 754 considered to be not applicable to SIP. 756 Security 758 As SIP is not proposed as a data transport for profile data SECREQ-2 759 and SECREQ-3 are not applicable. 761 The security capabilities of [SIP] are considered to satisfy the 762 other security requirements. 764 5.7 HTTP 766 HTTP [HTTP] is considered for the purpose of transporting the data 767 profiles (profile retrieval and upload). To satisfy the security 768 requirements [HTTPS] is assumed. 770 General 772 As HTTP is used primarily for transport GENOREQ-11 is consider to be 773 non-applicable. However active HTTP pages could be used to help 774 support this requirement. 776 Enrollment 778 Enrollment is considered to be mostly not applicable to the proposed 779 use of HTTP. However ENREQ-7 can be satisfied as part of profile 780 retrieval. This would require active pages on the profile server. 782 Profile Retrieval 784 HTTP satisfies all of the profile retrieval requirements. 786 Change Notification 788 Enrollment is considered to be mostly not applicable to the proposed 789 use of HTTP. However CNREQ-2 can be satisfied as profile retrieval. 791 Profile Upload 793 HTTP provides gross level access control of profile. However to get 794 atomic level access control on elements of the profile data requires 795 the development of active pages on the profile server (PUREQ-2). 797 Security 798 xxxxx 800 The security capabilities of [HTTPS] are considered to satisfy the 801 security requirements. 803 5.8 DHCP Options 805 [SIP-DHCP] 807 General 808 Discovery 810 5.9 DNS 812 [DNS] 813 [DNSSRV] 815 General 816 Discovery 818 5.10 XML 820 General 821 Data Container 823 5.11 RFC 822 825 General 826 Data Container 828 6 Security Considerations 830 Security considerations are covered in section 4.7. 832 7 Conclusion 834 The following tables rate the protocols according the the 835 requirements. The rating indcates how well the protocol 836 satisfies the requirment. The notation used is defined as 837 follows: 839 No : No support of requirement 840 L : Low suppport of requirement 841 H : High support of requirement 842 - : Not applicable to requirement 844 SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS 845 GENRREQ-1 No H - H H - - - - 846 GENOREQ-10 L L - H - - - - - 847 GENOREQ-11 L H - - - H M - - 848 GENNREQ-20 L H L H H - - - H 849 GENNREQ-21 No H L H H - - - H 850 GENAREQ-30 H L L H H H H H H 851 GENAREQ-31 H L L H H H H H H 852 xxxxx 854 GENAREQ-32 H L L H H H H H H 855 GENAREQ-33 L L L H H H H H H 857 DISREQ-1 H H H 858 DISREQ-2 - - - 860 ENREQ-1 H H H H 861 ENREQ-2 H H H H 862 ENREQ-3 H H L H 863 ENREQ-4 H H L H 864 ENREQ-5 L H L H 865 ENREQ-6 H H No H 866 ENREQ-7 L L - H*1 H 867 ENREQ-8 H H - H 868 ENREQ-9 H No - H 869 ENREQ-10 H H - H 871 *1 Note: this capability could be provided either as part of 872 enrollment or profile retrieval. Therefore HTTP is evaluated 873 here as providing ENREQ-7 as part of profile retrieval. 875 SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS 876 PRREQ-1 L H H 877 PRREQ-2 L L H 879 CNREQ-1 H No H 880 CNREQ-2 H No H*2 - 881 CNREQ-3 No No H 882 CNREQ-4 L No - 884 *2 Note: this capability could be provided either as part of 885 change notification or profile retrieval. Therefore HTTP is 886 evaluated here as providing CNREQ-2 as part of profile retrieval. 888 SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS 889 PUREQ-1 H H H 890 PUREQ-2 L H L 892 SECREQ-1 H H - H H 893 SECREQ-2 H H - H - 894 SECREQ-3 H H - H - 895 SECREQ-4 H H No H H 896 SECREQ-5 H - - H H 897 SECREQ-6 H H H H H 898 SECREQ-7 H H H H H 900 DAREQ-1 H H H L 901 DAREQ-2 - - - - 902 DAREQ-3 L H H H 903 DAREQ-4 L H H H 904 DAREQ-5 H H H H 905 xxxxx 907 The discovery solution is best addressed separately. Due to the 908 varied nature of most network environments, there is no single 909 solution that will work everywhere. It is probably necessary to 910 support multiple protocols. Due to the widespread deployment and 911 use of DHCP and DNS they are the best two candidates for discovery, 912 although SLP can be used in network that already support it. 914 The data container requirements are equally satisfied by XML and 915 ACAP largely due to their ability to support an extensible, 916 hierarchal schema. XML seems to have an advantage as well based on 917 the wide spread availability of development tools that operate on 918 XML. Both ACAP and HTTP address the profile retrieval and upload 919 requirements, although the relative maturity of XML over HTTP is 920 very attractive. 922 SIP is the only protocol that addressed all the relevant enrollment 923 and change control requirements.There was no single protocol that 924 satisfied all of the requirements in the other functional areas. 925 However a combination of HTTP and SIP satisfies all of the remaining 926 requirements to a high degree. In addition the large number of 927 implementations and development tools make this combination the most 928 attractive solution. The development as well as end user (e.g. 929 administrator) skill sets are much more readily available for these 930 protocols as well. As a second choice ACAP and SIP seems to be the 931 only other reasonable combination. 933 8 References 935 [SIP] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session 936 Initiation Protocol", RFC2543, Internet Engineering Task Force, 937 Nov 1998. 939 [SIP] draft-ietf-sip-rfc2543bis-09.txt 941 [RFC2026] S Bradner, "The Internet Standards Process -- Revision 3", 942 RFC2026 (BCP), IETF, October 1996. 944 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 945 requirement levels," Request for Comments (Best Current 946 Practice) 2119, Internet Engineering Task Force, Mar. 1997. 948 [HTTP] R. Fielding et al, �Hypertext Transfer Protocol -- 949 HTTP/1.1�, Request for Comments (Standards Track) 2616, Internet 950 Engineering Task Force, June 1999 952 [HTTPS] E. Rescorla, �HTTP Over TLS�, Request for Comments 2818, 953 Internet Engineering Task Force, May 2000 955 [TLS] T. Dierks, C. Allen, �The TLS Protocol Version 1.0�, Request 956 for Comments 2246, Internet Engineering Task Force, Jan. 1999 957 xxxxx 959 [EP-CONFIG] draft-stredicke-sipping-ep-config-00.txt 961 [SNMP] Request for Comments 2570-2576, Internet Engineering Task 962 Force 964 [ACAP] Request for Comments 2244, Internet Engineering Task Force 966 [ACAP-TLS] Request for Comments 2595, Internet Engineering Task 967 Force 969 [SLP] Request for Comments 2608, Internet Engineering Task Force 971 [SIP-EVENTS] A. Roach, �Event Notification in SIP�, , IETF; February 2002, Work in progress. 974 [DHCP] S. Alexander and R. Droms, "DHCP options and BOOTP vendor 975 extensions," Request for Comments (Draft Standard) 2132, Internet 976 Engineering Task Force, Mar. 1997. 978 [SIP-DHCP] G.Nair, H.Schulzrinne , �DHCP Option for SIP Servers�, 979 , IETF; March 1, 2002, Work in progress. 981 [DNSSRV] M. Mealling and R. Daniel, "The naming authority pointer 982 (NAPTR) DNS resource record," Request for Comments 2915, Internet 983 Engineering Task Force, Sept. 2000. 985 [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, 986 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 987 Recommendation, October 2000, 990 [RFC822] D. Crocker, �STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 991 MESSAGES�, Request for Comments 822, Internet Engineering Task 992 Force, Aug. 1982 994 [UA-PROF-FRAMEWORK] draft-petrie-sipping-config-framework-00.txt 996 9 Acknowledgments 998 Thanks to Henry Sinnreich and Henning Schulzrinne for their input 999 and review of this document. 1001 10 Author's Addresses 1003 Daniel G. Petrie 1004 Pingtel Corp. 1005 400 W. Cummings Park 1006 Suite 2200 1007 Woburn, MA 01801 1008 USA 1009 Phone: +1 781 938 5306 1010 Email: dpetrie@pingtel.com 1011 xxxxx 1013 Cullen Jennings 1014 Cisco Systems 1015 170 West Tasman Drive 1016 MS: SJC-21/3 1017 San Jose, CA 95134 1018 USA 1019 Phone: +1 408 527-9132 1020 EMail: fluffy@cisco.com 1022 Full Copyright Statement 1024 "Copyright (C) The Internet Society (date). All Rights Reserved. 1025 This document and translations of it may be copied and furnished to 1026 others, and derivative works that comment on or otherwise explain it 1027 or assist in its implementation may be prepared, copied, published 1028 and distributed, in whole or in part, without restriction of any 1029 kind, provided that the above copyright notice and this paragraph 1030 are included on all such copies and derivative works. However, this 1031 document itself may not be modified in any way, such as by removing 1032 the copyright notice or references to the Internet Society or other 1033 Internet organizations, except as needed for the purpose of 1034 developing Internet standards in which case the procedures for 1035 copyrights defined in the Internet Standards process must be 1036 followed, or as required to translate it into languages other than 1037 English. 1039 The limited permissions granted above are perpetual and will not be 1040 revoked by the Internet Society or its successors or assigns. 1041 This document and the information contained herein is provided on an 1042 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1043 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1044 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1045 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1046 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.