idnits 2.17.1 draft-petrie-sip-config-framewk-reqs-00.txt: -(199): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(262): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(287): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(310): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(333): 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 Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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? == There are 38 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 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.) -- The document date (February 1, 2001) is 8478 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 329, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 333, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Petrie 3 Internet Draft Pingtel 4 Document: draft-petrie-sip-config-framewk-reqs-00.txt 5 Expires: July 2001 February 1, 2001 7 Requirements for a SIP User Agent Configuration 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. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document defines a set of high level requirements for an 31 extensible framework to configure SIP user agents 32 Requirements for a SIP User Agent February 2001 33 Configuration Framework 35 Table of Contents 37 Status of this Memo................................................1 38 Abstract...........................................................1 39 1 Overview.......................................................3 40 2 Conventions used in this document..............................3 41 3 Assumptions....................................................3 42 3.1 Network configuration........................................3 43 3.2 Firewalls....................................................4 44 3.3 Terminology..................................................4 45 3.4 Simplicity...................................................4 46 4 Requirements...................................................4 47 4.1 Configuration Service Discovery..............................5 48 4.2 Configuration Consumer Registration..........................5 49 4.3 Configuration Retrieval......................................6 50 4.4 Configuration Change Notification............................6 51 4.5 Configuration Modification...................................7 52 5 References.....................................................8 53 6 Author's Address...............................................8 54 Requirements for a SIP User Agent February 2001 55 Configuration Framework 57 1 Overview 59 There is a general need to standardize methods for adding, 60 configuring, and maintaining SIP user agents within a VoIP system. 61 When one considers the effort needed to set up systems with hundreds 62 or thousands of user agents, the need for reducing set up time is 63 obvious. After a system is set up, ongoing maintenance in the form 64 of changing the configuration of the user agents, or upgrading the 65 software or firmware on a large population of user agents, is likely 66 to be necessary and requires a similar administrative effort. 68 In addition to these scaling problems, it is likely that the 69 population of user agents in any given VoIP system will be 70 heterogeneous: the configuration strategy must be flexible enough to 71 accommodate different needs for different users. Consequently, for 72 VoIP system administration sanity and cost practicality, a multi- 73 vendor configuration standard is needed. 75 Due to the highly divergent capabilities and purposes of the SIP 76 user agent population, it seems impractical to propose a single set 77 of data content to configure all possible variations. Common data 78 sets, or content profiles, can probably be defined, but special 79 purpose user agents or vendor value-added features are always likely 80 to need specific configuration data sets beyond any defined norm 82 This document proposes a general framework to support the use of 83 open data sets for configuring SIP user agents. Discussion of the 84 requirements for the content and format of these data profiles is 85 left for another document. 87 2 Conventions used in this document 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC-2119 [1]. 93 3 Assumptions 95 3.1 Network configuration 97 An assumption is made that basic network configuration can be 98 completed for the user agent device, based on the availability of 99 either: 101 - DHCP 102 - a manual, vendor-specific method for providing static network 103 settings to the user agent device 105 Once basic network configuration is completed through one of these 106 methods, the configuration task that remains is to make the device 107 functional within its SIP domain. 109 Requirements for a SIP User Agent February 2001 110 Configuration Framework 112 3.2 Firewalls 114 There are two basic network topologies that need to be supported by 115 a standard SIP UA configuration: 117 � Hosted VoIP Services 118 � Enterprise Based VoIP systems 120 The primary difference between these topologies, from a 121 configuration standpoint, is the placement of the server(s) that 122 provide the configuration and the devices relative to a firewall. 123 This spec does not propose to solve the firewall issue. At least one 124 protocol (or set of protocols if more than one are used for 125 configuration purposes) must be usable through a firewall, where the 126 devices are on the inside and the server is on the outside. 128 3.3 Terminology 130 Because a configuration server must perform a number of logical 131 functions, implementers may decide to spread different functions 132 across multiple servers. However, this document references this 133 potential collection of configuration servers in the singular as 134 �the server�. 136 A user agent device may actually be software running on a general 137 purpose computer, or a specially built hardware appliance. The user 138 agent to be configured is referenced as �the device�. 140 3.4 Simplicity 142 There are likely to be a wide range of configuration servers 143 implemented (for example, to provide scalability range, feature 144 sets, etc.). It is intended that the requirement defined here will 145 allow the server to be active and feature rich. However, it should 146 also be possible to build a simple server that meets the minimum 147 requirement for devices by delivering nearly static configuration 148 content. 150 4 Requirements 152 The requirements for the configuration of a SIP user agent can be 153 divided into the following high-level functions: 155 � Discovery 156 � Registration 157 � Configuration Retrieval 158 � Notification of Configuration Changes 159 � Configuration upload/change 161 These functional groups are intended only to provide a means to 162 think about and organize the requirements. They are not required to 163 be discrete steps, and they do not dictate a specific model. 165 Requirements for a SIP User Agent February 2001 166 Configuration Framework 168 4.1 Configuration Service Discovery 170 Once the network configuration has been resolved using either DHCP 171 or some static method, the first problem for a new SIP user agent to 172 solve is where to get its configuration. There are a number of well- 173 defined ways to resolve this configuration service discovery 174 problem. Most existing solutions are trivial to implement, although 175 each has pros and cons. 177 It is likely that a number of the existing solutions should be 178 supported to perform this function as either the network environment 179 or administration may dictate which solutions will work or be 180 allowed. 182 � A device MUST be able to determine where to retrieve its 183 configuration without manual provisioning. 185 4.2 Configuration Consumer Registration 187 The next operation that a new device in the network must perform is 188 to register with the configuration server. The server may require 189 notification of a device�s presence in order to create a new set of 190 configuration data values, allocate resources, etc. 192 � A device that is new to the configuration domain MUST make the 193 configuration server aware of its presence before it can retrieve 194 configuration data for the first time. 196 � A server MUST be able to uniquely identify every device in its 197 management domain. 199 � A device�s identity MUST NOT change through its lifetime in a 200 management domain. 202 � A device MUST have specific identifying configuration values 203 (for example, Vendor, Model number, Software or firmware version, 204 serial number, MAC address, etc.). 206 � To facilitate hardware swap out, it MUST be possible for 207 device-specific configuration values, stored in the server, to be 208 reassigned ). 210 � The device MUST be able to specify the configuration data 211 profiles that it requires (for example, the SIP parameters, 212 software or firmware updates, CPL scripts, applications, etc.) so 213 that the server can identify which devices are affected by a 214 given configuration change. 216 � The server MUST be able to specify the configuration data 217 profiles that it can provide. 219 Requirements for a SIP User Agent February 2001 220 Configuration Framework 222 � The configuration server MUST be able to communicate the 223 locations(s) (in the form of URL(s) or address(es), for example) 224 from which the device may retrieve specific configuration data. 226 � It MUST be possible, over time, to change the location(s) from 227 which configuration data is retrieved (as the result of failure, 228 administration changes, etc.). 230 � The server MAY require authentication and authorization of the 231 device in order for it to join the configuration server�s 232 management domain. 233 . 234 � The device MAY require authentication of the server. 236 � The device MAY support the ability to authenticate the 237 configuration server. 239 4.3 Configuration Retrieval 241 Configuration requirements and data are likely to vary widely from 242 device to device. As a result, it is proposed that the mechanism for 243 retrieval be a framework as opposed to closed and single purpose 245 Where common sets of data can be derived across multiple vendors, 246 data profiles can be defined to contain that common data in a 247 standard format. These profiles should be named so that upon 248 registration, a device can specify which profiles it requires 250 However, it is unreasonable to expect that a single profile can be 251 used to configure all devices, great and small. On the other hand, 252 it is reasonable to define a single profile (or set of profiles) 253 that will configure a device as a basic SIP user agent. Extended 254 features and functions can then be configured through separate 255 additional profiles. 257 � A device MAY retrieve configuration data for a specified user. 259 � The server MUST support the retrieval of device- and user- 260 specific configuration data values by a device. 262 � The server MAY infer a default user specific to that device, if 263 the device does not specify a user for the configuration data 264 retrieved. 266 � The server and device MAY support secure retrieval of 267 configuration data. 269 � The server MAY require authorization for data retrieval. 271 4.4 Configuration Change Notification 273 Configuration data is not static. It is likely to be changed over 274 time on the server by either this standard, or by some proprietary 275 Requirements for a SIP User Agent February 2001 276 Configuration Framework 278 interface. It is up to the implementer to provide the business logic 279 as to when devices should be notified after some configuration 280 change occurs on the server. As a result, a standard means of 281 notifying the device that changes in the configuration data of 282 interest have occurred is proposed. 284 In some environments it may not be possible for the server to 285 initiate configuration change notifications. 287 � The server MAY notify the device of configuration data changes. 289 � The device SHOULD perform the necessary operations to retrieve 290 and make effective the configuration changes indicated by the 291 change notification. 293 � The server and the device SHOULD support an expiration period 294 for configuration data. When this period ends, the device SHOULD 295 automatically retrieve refreshed data or confirm that no changes 296 have occurred. 298 � The server MAY specify in advance that a configuration change 299 is to occur (that is, schedule changes). 301 4.5 Configuration Modification 303 In addition to data changes made on the server, the device (or other 304 consumers of device configuration) may provide a facility for 305 modifying the data. The device therefore requires a means of 306 communicating such configuration modifications back to the server. 308 � The device MAY upload configuration changes to the server. 310 � The server MAY require authentication and authorization for the 311 configuration changes. 313 � The server MAY enforce authentication and authorization scopes 314 at a finer granularity than on a single vs. whole configuration 315 profile (that is, some end users may not be permitted to modify 316 all parameters). 318 � The user requesting the configuration change MAY be different 319 than the user to whom the configuration profile applies. 321 Requirements for a SIP User Agent February 2001 322 Configuration Framework 324 5 References 326 [1] S. Bradner, "The Internet Standards Process -- Revision 3", 327 RFC2026 (BCP), IETF, October 1996. 329 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 330 Session Initiation Protocol", Request for Comments (Proposed 331 Standard) 2543, Internet Engineering Task Force, Mar1999. 333 [3] H. Schulzrinne, �Configuring IP Telephony End Systems�, Internet 334 Draft, Internet Engineering Task Force, December 28, 2000 Work in 335 progress. 337 1 RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997 340 6 Author's Address 342 Dan Petrie 343 Pingtel Corp. 344 400 W. Cummings Park Phone: 1-781-938-5306 345 Suite 2200 Email: dpetrie@pingtel.com 346 Woburn, MA 01801 USA