idnits 2.17.1 draft-ietf-sipping-ua-prof-framewk-reqs-00.txt: ** The Abstract section seems to be numbered -(136): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(925): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(940): 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 1 longer page, the longest (page 5) being 60 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 785, but not defined == Unused Reference: 'TLS' is defined on line 925, but no explicit reference was found in the text == Unused Reference: 'DHCP' is defined on line 943, but no explicit reference was found in the text == Unused Reference: 'XML' is defined on line 954, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 959, but no explicit reference was found in the text == Unused Reference: 'UA-PROF-FRAMEWORK' is defined on line 963, 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-ietf-sipping-ua-prof-framewk-reqs-00.txt Pingtel Corp. 4 Feb. 2003 C. Jennings 5 Expires: Aug. 2003 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 Table of Contents 45 1 Abstract.......................................................1 46 2 Conventions used in this document..............................1 47 3 Overview.......................................................3 48 3.1 Background.....................................................3 49 3.2 Functional Groups..............................................3 50 3.3 Terminology....................................................4 51 4 Change History.................................................4 52 4.1 Changes from draft-petrie-sipping-ua-prof-framewk-reqs-00.txt..4 53 5 Requirements...................................................4 54 5.1 General........................................................4 55 5.1.1 Roaming......................................................5 56 5.1.2 Open and Extensible for Vendor...............................5 57 5.1.3 NAT/Firewall Support.........................................5 58 5.1.4 Availability of Development Tools............................6 59 5.2 Discovery......................................................6 60 5.3 Enrollment.....................................................7 61 5.4 Profile Retrieval..............................................8 62 5.5 Change Notification............................................8 63 5.6 Profile Upload.................................................8 64 5.7 Security.......................................................9 65 5.8 Data Container.................................................9 66 6 Protocol Evaluation...........................................10 67 6.1 Evaluation Criteria...........................................10 68 6.2 SNMP..........................................................11 69 6.3 LDAP..........................................................12 70 6.4 ACAP..........................................................12 71 6.5 SLP...........................................................13 72 6.6 SIP Events....................................................14 73 6.7 HTTP..........................................................15 74 6.8 DHCP Options..................................................16 75 6.9 DNS...........................................................16 76 6.10 XML..........................................................16 77 6.11 RFC 822......................................................16 78 7 Security Considerations.......................................16 79 8 Conclusion....................................................16 80 9 References....................................................18 81 10 Acknowledgments...............................................19 82 11 Author's Addresses............................................19 83 3 Overview 85 3.1 Background 87 There is a general need to standardize methods for adding, enabling, 88 and maintaining user and device profiles used by SIP user agents 89 within a VoIP system. When one considers the effort needed to set up 90 systems with hundreds or thousands of users and user agents, the 91 need for reducing set up time is obvious. After a system is set up, 92 ongoing maintenance in the form of changing the user and device 93 profiles on a large population of user agents, is likely to be 94 necessary and requires a similar administrative effort. 96 In addition to these scaling problems, it is likely that the 97 population of user agents in any given VoIP system will be 98 heterogeneous: the configuration strategy must be flexible enough to 99 accommodate different needs for different users. Consequently, for 100 VoIP system administration sanity and cost practicality, a multi- 101 vendor profile delivery standard is needed. 102 This requirements document and protocol evaluation is a more 103 formalized update to previous work in progress (e.g. expired draft 104 draft-petrie-sip-config-framewk-reqs-00.txt) and evaluation 105 performed by the authors. 107 3.2 Functional Groups 109 The requirements for the configuration of a SIP user agent can be 110 divided into the following high-level functions: 112 � Discovery 113 � Enrollment 114 � Profile Retrieval 115 � Change Notification 116 � Profile Upload 117 � Security 118 � Data Container 120 These functional groups are intended only to provide a means to 121 think about and organize the requirements. They are not required to 122 be discrete steps, and they are not intended to dictate a specific 123 model. 125 Discovery � is the means by which a new SIP user agent can 126 automatically discover how and where to enroll and retrieve desired 127 device and user profile(s). 129 Enrollment � is the means by which the user agent makes the profile 130 server(s) aware of its presence and desire of specific users and/or 131 device profiles. 133 Profile Retrieval � is the means by which the user agent gets the 134 desired profiles(s). 136 Change Notification � is the means by which the profile server tells 137 the user agent that profiles of interest have changed. Typically 138 the intension would be for the user agent to get those changes or 139 updated profiles. 141 Profile Upload � this is the means by which the user agent or other 142 entities in the network can update or propagate changes to a profile 143 on the server. 145 Security � primarily the focus is on protecting the profiles from 146 unauthorized access or change as well as integrity. 148 Data Container � the container or object model for the profile data 149 during transport to and from the server. The primary issues are 150 structure and hierarchy. 152 Note: The specific content is considered out of scope in this 153 document. The content requirements are addressed in [EP- 154 CONFIG]. Ideally the container would be considered with the 155 content requirements instead of the profile retrieval 156 requirements. However as some of the protocols evaluated have 157 an inherent data container the requirements are included in this 158 document to keep the comparison on an apples-to-apples basis. 160 3.3 Terminology 162 This document uses the following terminology: 164 Server or Profile Server � the server(s) that provide the profile 165 delivery framework functions defined above. 167 User Agent or Device � the client wishing to get or update the user 168 or device profile(s) as defined by the above functional framework. 170 4 Change History 172 4.1 Changes from draft-petrie-sipping-ua-prof-framewk-reqs-00.txt 174 Changed the name and refreshed as it had expired. 176 5 Requirements 178 The requirements are categorized by the functional groups defined in 179 3.2. In addition a general set requirements are defined up front. 180 Each requirement is given a unique identifier for cross referencing. 182 5.1 General 184 This section contains miscellaneous requirements across all 185 functional groups. 187 5.1.1 Roaming 189 GENRREQ-1: The profile delivery framework MUST support the ability 190 for profiles to roam. 192 That is, a user may go to another user agent within the server�s 193 domain and with proper authorization, the user agent must be able to 194 retrieve from the server and use the user�s profile. 196 5.1.2 Open and Extensible for Vendor 198 GENOREQ-10: The profile framework MUST allow vendor differentiation 199 on both the server and user agent sides. 201 This is largely an issue of how easy it is to make a more 202 intelligent or active server or client without breaking the 203 standard. 205 GENOREQ-11: The profile server MUST be able to opaquely support 206 vendor extensions to profiles. 208 That is the server should be able to handle uploading of vendor 209 specific data in a profile without requiring a new profile 210 definition or schema. 212 5.1.3 NAT/Firewall Support 214 There are two primary models in which VoIP systems are deployed: 216 � 217 Hosted VoIP Services ("Centrex" Model) 218 � 219 Locally Administered VoIP systems ("PBX" Model) 221 In the extreme case of a hosted model, the only customer premises 222 equipment is the LAN and user agents. In the locally administered 223 model all equipment, servers, gateways and user agents are on the 224 local premises. There is of course a spectrum of variations 225 between. In addition there are multi-site enterprise deployments 226 that in some aspects may appear more like the hosted model. The 227 user agent in either model may be present in an commercial or in a 228 residential environment. 230 The primary issue relating to the profile delivery framework is the 231 presence of NATs and/or firewalls between the profile server and the 232 user agent. It is assumed that if NATs or firewalls are present (in 233 between) the user agents are on the inside and the profile server is 234 effectively on the outside (e.g. public Internet). 236 GENNREQ-20: The user agent MUST be able to reach the profile server 237 through a NAT or firewall to perform all of the functions in the 238 delivery framework. 240 GENNREQ-21: The firewall or NAT SHOULD not require any additional 241 configuration to enable the profile delivery framework to work. 243 It is assumed that certain protocols are typically enabled on 244 the NAT or firewall by default (e.g. HTTP access to servers 245 outside). It is assumed that SIP access in both directions is 246 enabled or the user agent is not likely to be of much use. 248 5.1.4 Availability of Development Tools 250 The platforms (server and user agent) upon which this profile 251 delivery framework must be deployed are very different in 252 capability. The user agents are largely embedded systems with 253 limited resources for code and data size as well as CPU power (pure 254 software based user agents are less constrained). The profile 255 server is likely to run on general purpose servers and therefore not 256 as resource constrained. 258 For wide spread adoption of the profile delivery system, the tools 259 protocol implementations required to build the profile server should 260 be readily available. 262 GENAREQ-30: The protocol stack implementations needed to build a 263 profile server SHOULD be commercially and/or publicly available, 264 preferably with reference or open-source implementations available. 266 GENAREQ-31: There SHOULD be multiple implementations of the protocol 267 stacks required in the profile server readily available. 269 GENAREQ-32: There SHOULD be multiple implementations of the protocol 270 stacks required in the user agent readily available. 272 GENAREQ-33: There SHOULD be multiple implementations of the protocol 273 stacks required in the user agent suitable for embedded systems. 275 5.2 Discovery 277 The purpose of discovery is to provide the means by which zero or 278 minimal user interaction is required when plugging in a user agent 279 for the first time in a specific profile server domain. It is 280 likely that there is no single protocol solution for discovery due 281 to the wide variety of typical network configurations including but 282 not limited to networks: 283 not connected to the Internet 284 with no DHCP server 285 with no DNS SRV support 286 with a non-configurable DNS server 288 DISREQ-1: The user agent SHOULD be able to discover the profile 289 server without human input. 291 DISREQ-2: It MUST be possible to manually set the location of the 292 profile server for a user agent. 294 This is primarily a user agent implementation issue not a 295 protocol issue. 297 5.3 Enrollment 299 ENREQ-1: A user agent must be able to provide a unique identity to 300 the profile server which does not change for the life of the UA. 302 This allows user and device profiles to be associated with a 303 particular user agent. 305 ENREQ-2: A user agent requiring profiles SHOULD make itself known to 306 the profile server. 308 ENREQ-3: The user agent MUST identify profiles that it requires. 310 ENREQ-4: The profile server MAY be provisioned to know what profiles 311 a user agent needs by default. 313 There are a number of reasons for the above requirements. In 314 large scale deployments this may be important for load balancing 315 purposes. This may be needed by the profile server so that it 316 can understand which user agents are dependent upon which 317 profiles. 319 ENREQ-5: A user agent MAY request additional or different user 320 profiles beyond the default provisioned for the user agent. 322 This is primarily to support the notion of roaming. 324 ENREQ-6: The user agent MUST provide specific information which may 325 needed by the server to customize the profile(s) for the user agent. 327 It may be necessary to provide different views of a profile 328 based upon the specific configuration of the user agent. (for 329 example, Vendor, Model number, Software or firmware version, 330 serial number, MAC address, etc.). 332 ENREQ-7: It SHOULD be possible for the profile server to deliver 333 different views of a profile based upon characteristics of the user 334 agent. 336 Though the objective is to provide a standardized profile that 337 has the same content for all vendors user agents, in reality 338 there are changes or differences to work around. That is it may 339 be desirable to put intelligence in the profile server to work 340 around differences in user agent behavior or changes in the 341 standardized profile content specification. 343 ENREQ-8: It MUST be possible to reassigned device-specific profiles, 344 stored in the server, to a different user agent. 346 This is to facilitate hardware swap out. 348 ENREQ-9: It MUST be possible for the profile server, over time, to 349 change the location(s) from which configuration data is retrieved. 351 The intension is to allow server handoff as the result of 352 failure, administration changes, load balancing, etc. 354 ENREQ-10: The user agent SHOULD re-enroll periodically. 356 The user agent basically should check in periodically with the 357 profile server in case a network problem prevented change 358 notification from getting to the user agent. 360 5.4 Profile Retrieval 362 PRREQ-1: It MUST be possible for the user agent to retrieve the 363 profile(s) it requires on demand. 365 PRREQ-2: It MUST be possible for the entire population of user 366 agents to request and retrieve the required profiles in a short 367 period of time. 369 This is a scalability requirement: e.g. during a power outage 370 tens or hundreds of thousands of user agents may power up at 371 once. 373 5.5 Change Notification 375 CNREQ-1: The profile server MUST be able to notify dependent user 376 agents of profile changes. 378 CNREQ-2: The user agent MUST be able to get the new updated profile. 380 CNREQ-3: The server MAY specify in advance that a configuration 381 change is to occur. 383 That is the profile server may schedule changes. 385 CNREQ-4: The user agent MAY defer making profile changes effective 386 until it is safe to do so. 388 Some profile changes may disrupt the operation of the user 389 agent. The user agent should use discretion as to whether the 390 change will disrupt critical operation (e.g. a call) of the user 391 agent. [Should there be a means of specifying immediate or when 392 safe?] 394 5.6 Profile Upload 396 PUREQ-1: A user agent MUST be able to upload changes to a profile on 397 the profile server. 399 This is to facilitate changes made either via a user interface 400 on the user agent which are desired to be permanent as well as a 401 means by which a external interface (e.g. a rich GUI on a 402 general purpose computer) may interface with the profile 403 server. 405 PUREQ-2: The profile server should provide an access control 406 mechanism to constrain who can read, write, delete, or by 407 notified about change to profile data. 409 5.7 Security 411 User and device profiles may contain sensitive data such as 412 passwords and identities. It MUST be possible to protect the 413 profiles and information about the profiles. 415 SECREQ-1: The profile server SHOULD not provide access to profile 416 data without authentication and authorization. 418 SECREQ-2: The profile server MUST not allow a user agent to update 419 profile data without authentication and authorization. 421 SECREQ-3: The profile data, when transmitted over the network, 422 SHOULD be protected against man in the middle attacks and snooping. 424 SECREQ-4: The profile server SHOULD not allow enrollment without 425 authentication and authorization. 427 SECREQ-5: The profile server SHOULD not provide change notification 428 of profiles without authentication and authorization. 430 SECREQ-6: The user agent SHOULD not interact with or trust any 431 information from the profile server before authenticating the 432 profile server. 434 SECREQ-7: The information exchanged between the user agent and the 435 profile server SHOULD be integrity protected. 437 5.8 Data Container 439 DAREQ-1: The data container MUST support hierarchical and structured 440 date. Note: for a better understanding of rational for this 441 requirement see [EP-CONFIG] 443 DAREQ-2: It MUST be possible to define a standardized set of profile 444 data that all user agents SHOULD support. 446 DAREQ-3: It MUST be possible for user agent vendors to add vendor 447 specific data without breaking the standardized data set or 448 requiring the creation of additional profiles. 450 DAREQ-4: The data container MUST be flexible enough to contain 451 additional data without breaking the profile server or the user 452 agent. 454 e.g. non-standard, vendor specific or standard updates 456 DAREQ-5: The user agent must be able to determine the differences 457 when a profile has changed. 459 Note: this can be either by getting only the added, removed or 460 changed data or by calculating the difference between two 461 profiles. 463 6 Protocol Evaluation 465 The following set of protocols are those that have been suggested 466 for the purpose of SIP user agent profile delivery framework both on 467 the SIP and SIPPING mailing lists as well as at past work group 468 meetings. 470 SNMP 471 LDAP 472 ACAP 473 SLP 474 SIP Events 475 HTTP 476 DHCP Options 477 DNS 478 XML 479 RFC 822 481 This is of course not an exhaustive list of possible protocols, but 482 a pragmatic list. 484 6.1 Evaluation Criteria 486 The requirements defined in section 5 define a set of criteria for 487 by which protocols may be evaluated for use in the profile delivery 488 framework. 490 The following table indicates the functional area for which the 491 protocols are considered. This table indicates which requirements 492 will be evaluated for each of the protocols. As no single protocol 493 provides all of the functional areas, the objective is to find a 494 small set of protocols that will best satisfy the requirements. All 495 protocols are evaluated against the general requirements in section 496 5.1. 498 SNMP LDAP ACAP SLP HTTP SIP XML 822 DHCP DNS 499 Discovery X X X 501 Enrollment X X X X 502 Profile Retrieval X X X X 504 Change Notification X X X 506 Profile Upload X X X X 508 Security X X X X X X 510 Data Container X X X X X 512 In each of the following subsections to section 6 a general over 513 evaluation is made of the protocol. In addition the requirements 514 which are NOT satisfied fully or as well as other protocols are 515 explicitly listed or discussed. Those requirements that are 516 satisfied are generally not explicitly called out or listed. 518 6.2 SNMP 520 SNMPv3 [SNMP] is evaluated and referred to as SNMP in this document. 521 SNMP has no discovery mechanism. 523 General 525 There are two aspects of the roaming requirement (GENRREQ-1), 526 neither of which are solved very well by SNMP. 527 - Physical relocation of a user agent in a different LAN 528 - Users moving to a different user agent which subsequently 529 requires a new user profile 531 It is very difficult to support a user whose preferences are stored 532 outside the local management domain. This physical relocation of a 533 user agent (e.g. user agent on a laptop in a visited LAN) is a very 534 desirable scenario. Because of its security model, SNMP does not 535 work very well outside of its local domain. 537 To support a user (one or more) temporarily using a user agent, the 538 user agent would have to support the access of multiple, variable 539 user profiles. MIBs do support the ability to have arrays or 540 multiple instances of an object (typically leaf nodes). However 541 MIBs do not support multiple instances of a hierarchy (e.g. multiple 542 user profiles each with a hierarchy of content). 544 It is difficult to make an active SNMP server. SNMP is primarily a 545 push model. It is difficult to make an intelligent profile server 546 where traps are not designed into the standard profile MIB (GENOREQ- 547 10). 549 MIBs have a very rigid schema that makes it difficult to add vendor 550 specific data without breaking the MIB or having to create a new MIB 551 (GENOREQ-11). Supporting the vendor differentiation through MIBs 552 would make management difficult. 554 SNMP will not work through a NAT or firewall by default. It is also 555 likely that a firewall administrator will have serious concerns 556 letting SNMP traffic through their firewall. 558 Enrollment 560 ENREQ-5 has the same issues with multiple user profiles as described 561 above for general requirement GENRREQ-1. 563 ENREQ-7 has the same issues as GENOREQ-10 and GENOREQ-11 described 564 above. 566 Profile Retrieval 568 As SNMP uses a push model, the user agent must throw a trap or 569 inform to tell the server to push a profile to the user agent. In 570 addition the issue with multiple user profiles, described above with 571 GENRREQ-1, make it difficult to satisfy PRREQ-1. 573 SNMP does not scale very well to individual dynamic nodes. It is 574 difficult to build a system managing more than tens of thousands of 575 users. User agents from some vendors do not have sufficient 576 persistent memory to store a whole user or device profile. After a 577 power outage tens or hundreds of thousands of user agents would all 578 power up, throw traps requesting profiles. 580 The push model of SNMP make it difficult to make changes from the 581 user agent (PUREQ-2). A solution perhaps could be built using a 582 trap. However this would not enable other entities (non-user 583 agents) to set profile data. 585 Change Notification 587 There is no delayed setting of MIB data. A SNMP agent either 588 accepts the change or rejects it immediately (CNREQ-3 and CNREQ-4). 590 Data Container 591 DAREQ-3 and DAREQ-4 are not well supported due to the rigid nature 592 of MIBs described above relative to GENOREQ-11. 594 6.3 LDAP 596 The authors did not have sufficient time to complete a thorough 597 evaluation of LDAP. 599 6.4 ACAP 601 General 603 ACAP was not designed to be active on the server side. It has more 604 of a database model. It is probably possible to make the data 605 access active or intelligent, however this is make more difficult by 606 the lack of implementations (GENOREQ-10). 608 ACAP [ACAP] over TLS [ACAP-TLS] is evaluated to satisfy the security 609 requirements. The authors were not able to find a commercially or 610 publicly available version of ACAP written in C, C++ or Java 611 (GENAREQ-30, GENAREQ-31, GENAREQ-32, GENAREQ-33). 613 ACAP does not support any discovery mechanism and was not evaluated 614 for this functional area. 616 Enrollment 618 Due to the difficulty of making the profile server active for 619 Change Notification (as described above in the general requirements 620 evaluation of ACAP), it is also difficult to provide different views 621 of data based upon characteristics of the user agent (ENREQ-7). The 622 different views would have to be designed into the schema requiring 623 coordination on both the user agent and server sides. 625 Without an event mechanism (see below) or a means to redirect 626 profile data requests to another server it is difficult to re-assign 627 a user agent to an alternative ACAP server (ENREQ-9). 629 Change Notification 631 ACAP does not support an event mechanism. It uses a polling model. 632 This makes it difficult to make profile data changes effective 633 immediately. A very short polling time must be used which does not 634 scale well with large numbers of user agents. Alternatively with a 635 longer pooling period, user agents will be slow to make the profile 636 changes effective (CNREQ-1, CNREQ-2, CNREQ-3 and CNREQ-4). 638 Profile Retrieval 640 ACAP meets the requirements for profile retrieval. 642 Profile Upload 644 ACAP provides a means of updating the profile data with access 645 control. 647 Security 649 Security is provided via TLS. 651 Data Container 653 ACAP does have a rich hierarchal structure for containing profile 654 data. In addition it has a powerful means of describing access 655 control and modification time stamping of data. 657 6.5 SLP 659 SLP [SLP] is primarily a LAN based solution for discovery of 660 services. It allows the discovery of URL or server and port for a 661 well named service. SLP is not appropriate for profile retrieval, 662 change notification or profile update. Nor does it provide a data 663 container. 665 General 667 As SLP is primarily for LAN based discovery where roaming 668 functionality is not applicable (GENRREQ-1). Likewise vendor 669 differentiation in the server and user agent are less applicable 670 (GENOREQ-10 and GENOREQ-11). 672 It is difficult to make SLP work through NATs or firewalls (GENNREQ- 673 20, GENNREQ-21). 675 Enrollment 677 The ability to provision or create active responses to user agent 678 request makes ENREQ-3, ENREQ-4, ENREQ-5 and ENREQ-6 more 679 appropriately performed with protocols other than SLP. 681 As SLP does not get involved with the profile retrieval, update or 682 change notification enrollment requirements: ENREQ-7, ENREQ-8, 683 ENREQ-9 and ENREQ-10 are not applicable to SLP. 685 Security 687 For the above reason security requirements: SECREQ-1, SECREQ-2, 688 SECREQ-3 and SECREQ-5 are also not applicable. 690 SLP does not authenticate or authorize the user agent. It assumes 691 that is preformed by the server performing the profile retrieval, 692 upload and change notification functions (SECREQ-4). 694 6.6 SIP Events 696 The only appropriate use of SIP is for its event mechanism [SIP- 697 EVENTS]. SIP is evaluated assuming SIPS and S/MIME [SIP] support 698 for the security functionality. SIP provides a very powerful event 699 framework through the SUBSCRIBE and NOTIFY messages. 701 SIP is not appropriate for profile retrieval or upload. It is not a 702 data transport protocol. Nor does SIP provide a data container. 703 SIP does support multicast that could be used as a discovery 704 mechanism. However it is not evaluated for discovery features. 706 General 708 The primary requirement for vendor differentiation is in the 709 enrollment, profile retrieval, update and change notification. SIP 710 does allow active server and client side components. However this 711 is not considered necessary for this requirement (GENOREQ-10) and 712 considered not applicable. 714 As SIP is not consider appropriate for profile retrieval or upload 715 it is consider not applicable to GENOREQ-11. 717 Enrollment 719 The SIP SUBSCRIBE mechanism of [SIP-EVENTS] satisfies all of the 720 enrolloment functional requirements. 722 Change Notification 724 CNREQ-2 is not applicable to SIP. It is more related to the profile 725 retrieval mechanism used. 727 The deferral of making profile changes effective is a user agent 728 implementation issue in the context of [SIP-EVENTS]. CNREQ-4 is 729 considered to be not applicable to SIP. 731 Security 733 As SIP is not proposed as a data transport for profile data SECREQ-2 734 and SECREQ-3 are not applicable. 736 The security capabilities of [SIP] are considered to satisfy the 737 other security requirements. 739 6.7 HTTP 741 HTTP [HTTP] is considered for the purpose of transporting the data 742 profiles (profile retrieval and upload). To satisfy the security 743 requirements [HTTPS] is assumed. 745 General 747 As HTTP is used primarily for transport GENOREQ-11 is consider to be 748 non-applicable. However active HTTP pages could be used to help 749 support this requirement. 751 Enrollment 753 Enrollment is considered to be mostly not applicable to the proposed 754 use of HTTP. However ENREQ-7 can be satisfied as part of profile 755 retrieval. This would require active pages on the profile server. 757 Profile Retrieval 759 HTTP satisfies all of the profile retrieval requirements. 761 Change Notification 763 Enrollment is considered to be mostly not applicable to the proposed 764 use of HTTP. However CNREQ-2 can be satisfied as profile retrieval. 766 Profile Upload 767 HTTP provides gross level access control of profile. However to get 768 atomic level access control on elements of the profile data requires 769 the development of active pages on the profile server (PUREQ-2). 771 Security 773 The security capabilities of [HTTPS] are considered to satisfy the 774 security requirements. 776 6.8 DHCP Options 778 [SIP-DHCP] 780 General 781 Discovery 783 6.9 DNS 785 [DNS] 786 [DNSSRV] 788 General 789 Discovery 791 6.10 XML 793 General 794 Data Container 796 6.11 RFC 822 798 General 799 Data Container 801 7 Security Considerations 803 Security considerations are covered in section 5.7. 805 8 Conclusion 807 The following tables rate the protocols according the the 808 requirements. The rating indcates how well the protocol 809 satisfies the requirment. The notation used is defined as 810 follows: 812 No : No support of requirement 813 L : Low suppport of requirement 814 H : High support of requirement 815 - : Not applicable to requirement 817 SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS 818 GENRREQ-1 No H - H H - - - - 819 GENOREQ-10 L L - H - - - - - 820 GENOREQ-11 L H - - - H M - - 821 GENNREQ-20 L H L H H - - - H 822 GENNREQ-21 No H L H H - - - H 823 GENAREQ-30 H L L H H H H H H 824 GENAREQ-31 H L L H H H H H H 825 GENAREQ-32 H L L H H H H H H 826 GENAREQ-33 L L L H H H H H H 828 DISREQ-1 H H H 829 DISREQ-2 - - - 831 ENREQ-1 H H H H 832 ENREQ-2 H H H H 833 ENREQ-3 H H L H 834 ENREQ-4 H H L H 835 ENREQ-5 L H L H 836 ENREQ-6 H H No H 837 ENREQ-7 L L - H*1 H 838 ENREQ-8 H H - H 839 ENREQ-9 H No - H 840 ENREQ-10 H H - H 842 *1 Note: this capability could be provided either as part of 843 enrollment or profile retrieval. Therefore HTTP is evaluated 844 here as providing ENREQ-7 as part of profile retrieval. 846 SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS 847 PRREQ-1 L H H 848 PRREQ-2 L L H 850 CNREQ-1 H No H 851 CNREQ-2 H No H*2 - 852 CNREQ-3 No No H 853 CNREQ-4 L No - 855 *2 Note: this capability could be provided either as part of 856 change notification or profile retrieval. Therefore HTTP is 857 evaluated here as providing CNREQ-2 as part of profile retrieval. 859 SNMP ACAP SLP HTTP SIP XML 822 DHCP DNS 860 PUREQ-1 H H H 861 PUREQ-2 L H L 863 SECREQ-1 H H - H H 864 SECREQ-2 H H - H - 865 SECREQ-3 H H - H - 866 SECREQ-4 H H No H H 867 SECREQ-5 H - - H H 868 SECREQ-6 H H H H H 869 SECREQ-7 H H H H H 871 DAREQ-1 H H H L 872 DAREQ-2 - - - - 873 DAREQ-3 L H H H 874 DAREQ-4 L H H H 875 DAREQ-5 H H H H 877 The discovery solution is best addressed separately. Due to the 878 varied nature of most network environments, there is no single 879 solution that will work everywhere. It is probably necessary to 880 support multiple protocols. Due to the widespread deployment and 881 use of DHCP and DNS they are the best two candidates for discovery, 882 although SLP can be used in network that already support it. 884 The data container requirements are equally satisfied by XML and 885 ACAP largely due to their ability to support an extensible, 886 hierarchal schema. XML seems to have an advantage as well based on 887 the wide spread availability of development tools that operate on 888 XML. Both ACAP and HTTP address the profile retrieval and upload 889 requirements, although the relative maturity of XML over HTTP is 890 very attractive. 892 SIP is the only protocol that addressed all the relevant enrollment 893 and change control requirements.There was no single protocol that 894 satisfied all of the requirements in the other functional areas. 895 However a combination of HTTP and SIP satisfies all of the remaining 896 requirements to a high degree. In addition the large number of 897 implementations and development tools make this combination the most 898 attractive solution. The development as well as end user (e.g. 899 administrator) skill sets are much more readily available for these 900 protocols as well. As a second choice ACAP and SIP seems to be the 901 only other reasonable combination. 903 9 References 905 [SIP] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session 906 Initiation Protocol", RFC2543, Internet Engineering Task Force, 907 Nov 1998. 909 [SIP] draft-ietf-sip-rfc2543bis-09.txt 911 [RFC2026] S Bradner, "The Internet Standards Process -- Revision 3", 912 RFC2026 (BCP), IETF, October 1996. 914 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 915 requirement levels," Request for Comments (Best Current 916 Practice) 2119, Internet Engineering Task Force, Mar. 1997. 918 [HTTP] R. Fielding et al, �Hypertext Transfer Protocol -- 919 HTTP/1.1�, Request for Comments (Standards Track) 2616, Internet 920 Engineering Task Force, June 1999 922 [HTTPS] E. Rescorla, �HTTP Over TLS�, Request for Comments 2818, 923 Internet Engineering Task Force, May 2000 925 [TLS] T. Dierks, C. Allen, �The TLS Protocol Version 1.0�, Request 926 for Comments 2246, Internet Engineering Task Force, Jan. 1999 928 [EP-CONFIG] draft-stredicke-sipping-ep-config-00.txt 930 [SNMP] Request for Comments 2570-2576, Internet Engineering Task 931 Force 933 [ACAP] Request for Comments 2244, Internet Engineering Task Force 935 [ACAP-TLS] Request for Comments 2595, Internet Engineering Task 936 Force 938 [SLP] Request for Comments 2608, Internet Engineering Task Force 940 [SIP-EVENTS] A. Roach, �Event Notification in SIP�, , IETF; February 2002, Work in progress. 943 [DHCP] S. Alexander and R. Droms, "DHCP options and BOOTP vendor 944 extensions," Request for Comments (Draft Standard) 2132, Internet 945 Engineering Task Force, Mar. 1997. 947 [SIP-DHCP] G.Nair, H.Schulzrinne , �DHCP Option for SIP Servers�, 948 , IETF; March 1, 2002, Work in progress. 950 [DNSSRV] M. Mealling and R. Daniel, "The naming authority pointer 951 (NAPTR) DNS resource record," Request for Comments 2915, Internet 952 Engineering Task Force, Sept. 2000. 954 [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler, 955 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 956 Recommendation, October 2000, 959 [RFC822] D. Crocker, �STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT 960 MESSAGES�, Request for Comments 822, Internet Engineering Task 961 Force, Aug. 1982 963 [UA-PROF-FRAMEWORK] draft-petrie-sipping-config-framework-00.txt 965 10 Acknowledgments 967 Thanks to Henry Sinnreich and Henning Schulzrinne for their input 968 and review of this document. 970 11 Author's Addresses 972 Daniel G. Petrie 973 Pingtel Corp. 975 400 W. Cummings Park 976 Suite 2200 977 Woburn, MA 01801 978 USA 979 Phone: +1 781 938 5306 980 Email: dpetrie@pingtel.com 982 Cullen Jennings 983 Cisco Systems 984 170 West Tasman Drive 985 MS: SJC-21/3 986 San Jose, CA 95134 987 USA 988 Phone: +1 408 527-9132 989 EMail: fluffy@cisco.com 991 Full Copyright Statement 993 "Copyright (C) The Internet Society (date). All Rights Reserved. 994 This document and translations of it may be copied and furnished to 995 others, and derivative works that comment on or otherwise explain it 996 or assist in its implementation may be prepared, copied, published 997 and distributed, in whole or in part, without restriction of any 998 kind, provided that the above copyright notice and this paragraph 999 are included on all such copies and derivative works. However, this 1000 document itself may not be modified in any way, such as by removing 1001 the copyright notice or references to the Internet Society or other 1002 Internet organizations, except as needed for the purpose of 1003 developing Internet standards in which case the procedures for 1004 copyrights defined in the Internet Standards process must be 1005 followed, or as required to translate it into languages other than 1006 English. 1008 The limited permissions granted above are perpetual and will not be 1009 revoked by the Internet Society or its successors or assigns. 1010 This document and the information contained herein is provided on an 1011 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1012 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1013 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1014 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1015 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.