SIPPING Working Group J. Littlefield Internet-Draft Cisco Systems, Inc. Expires: April 23, 2007 October 20, 2006 A Management Request Event Package for the Session Initiation Protocol (SIP) draft-littlefield-sipping-mgmt-event-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract In many environments, firewall, NAT and IP addressing issues make remote management of devices containing SIP user agents difficult. This document defines a SIP event package for notifying a user agent that it should initiate a session with a management entity for management operations. This type of "call-home" management avoids the need to maintain persistent TCP connections, or generate additional STUN traffic, with the management entity. This event package is intended not to tunnel management protocols or otherwise Littlefield Expires April 23, 2007 [Page 1] Internet-Draft SIP Management Request Event Package October 2006 provide management itself, but instead to provide a means for signaling a SIP UA that a management session is desired. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 4. Management Request Event Package . . . . . . . . . . . . . . . 5 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 5 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 5 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 5 4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 5 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 6 4.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 6 4.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 7 4.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 7 4.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 7 4.10. Handling of Forked Requests . . . . . . . . . . . . . . . 8 4.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 8 4.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 8 4.13. Examples of Usage . . . . . . . . . . . . . . . . . . . . 8 4.13.1. Example using SNMP over SSH . . . . . . . . . . . . . 9 4.13.2. Example using vendor-specific management protocol . . 12 5. Management Protocol List Document . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. SIP Event Package Registration for "management-req" . . . 15 7.2. MIME Registration for "application/mgmt-protos-list" . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Littlefield Expires April 23, 2007 [Page 2] Internet-Draft SIP Management Request Event Package October 2006 1. Introduction Element management is an important tool for troubleshooting and monitoring network entities. When devices are directly addressable, and their addresses are known, or easily resolved, using DNS (Domain Name System), management protocols such as SNMP (Simple Network Management Protocol) work well for retrieving statistics and for examining and changing settings and state. However, when NAT (Network Address Translator), NATP (NAT Protocol Translation) and firewall devices are between the managed entity and the management station, it may be difficult or impossible to initiate communication with the device in the normal way. Examples of such deployments include service providers attempting to manage devices deployed in a subscriber's home, behind a typical home gateway device, as well as some multi-site enterprises. Aside from remote manipulation of the firewall and NAT devices, these deployments typically require some form of "call-home" management, where the managed entity takes the initiative in establishing the management session or allowing for management transactions. Among the less attractive solutions to this problem are to have the managed entity maintain a persistent TCP connection to the management station, or to use STUN or similar frequent UDP exchanges to maintain a firewall pinhole or NATP port-mapping through which it may be reached. An alternative is to use some out-of-band mechanism by which the entity can be contacted to notify it of the need for it to contact the management station for management using a standard management protocol. When the managed entity contains a Session Initiation Protocol (SIP) [2] User Agent (and specifically when the entity's primary role is that of a SIP user agent), it's attractive to use the SIP protocol as the vehicle to request that the entity initiate a management session. The NAT and firewall traversal issues are already presumably solved in the environments where SIP is used across NATs and firewalls. The ability to address the managed entity using a SIP URI rather than a hostname or IP address may be attractive as well, for example, in the case of an overlay voice service provider. The use of SIP to establish management sessions does have limitations, in that it depends on the device's ability to use SIP successfully, so this approach may not allow diagnosis and correction of a severely incapacitated device. However, there are still significant benefits to this approach when compared to the complete lack of manageability. This document defines a SIP event package that allows the SIP user agent to subscribe to requests for management connections from a Littlefield Expires April 23, 2007 [Page 3] Internet-Draft SIP Management Request Event Package October 2006 particular management domain. It does not specify the management protocol that will be used, but allows for a variety of management protocols. It does not restrict notification content, in anticipation of supporting a variety of notification content appropriate to different protocols. This event package is considered complementary to the event package specified by the SIP user agent (UA) profile delivery framework [4], which defines mechanisms for configuration, but not management, of SIP user agents. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1]. Within this document, the term "device" may be used to refer to the managed entity. This is not intended to imply any limitation to special purpose hardware devices and device management. The managed entity may as easily be a software client or application to the extent that a particular management protocol is not, itself, limited to hardware devices. 3. Overview of Operation When using this event package, the managed entity begins with the name of the domain to which it belongs for management purposes. This domain name may be discovered via DHCP, manually configured, or obtained as part of a separate device configuration download (using the SIP UA profile delivery framework, for example). This domain name enables the entity to form a unique request URI to which it will subscribe using this event package. The subscription request from the device (software or hardware) contains information about the management protocol or protocols that the device supports and expects to use. In many situations, there is a standard and well-known management protocol to use, such as in the case of home telephony adapter devices managed by a service provider and conforming to a particular access network technology service standard. In other situations, the device's configuration will dictate which of a set of possible management protocols are to be used. In some situations, multiple transports of the same management protocol may be acceptable, and the device would indicate which of those protocols it supports. If one or more of the indicated Littlefield Expires April 23, 2007 [Page 4] Internet-Draft SIP Management Request Event Package October 2006 management protocols are acceptable to the management station, then it accepts the subscription. When the management station needs to contact the device to perform management operations, it sends a NOTIFY message to the device including information about the management protocol to use (selected from those offered in the SUBSCRIBE). In some cases, this may include information about which management station to contact, but in many cases the management protocol contact information for the management station will be part of the device's configuration, and the NOTIFY will simply indicate the need to establish a session with this pre-configured station (or one of several). On receipt of the notification, the managed entity immediately connects to the management station using the indicated management protocol. Authentication of this management session is dependent on the management protocol, device configuration, and authorization requirements of the device and the management station. 4. Management Request Event Package 4.1. Event Package Name This document defines a SIP Event Package as defined in RFC 3265 [3]. The event package name is "management-req". This value appears in the Event header field present in SUBSCRIBE and NOTIFY requests for this package. 4.2. Event Package Parameters This event package does not define any event package parameters. 4.3. SUBSCRIBE Bodies The SUBSCRIBE request SHOULD contain a body. The message body, if present, MUST communicate the set of management protocols that are supported by the managed device, using the content type "application/ mgmt-protos-list" described below in Section 5. The SUBSCRIBE body MAY be empty only if the content-types listed in the "Accept" header each imply a particular management protocol (see Section 4.6). 4.4. Subscription Duration Subscriptions to this event package MAY range from minutes to days. Subscriptions in hours are more typical and are RECOMMENDED, so that Littlefield Expires April 23, 2007 [Page 5] Internet-Draft SIP Management Request Event Package October 2006 a lost subscription is detected within a reasonable amount of time. Since this event package is intended to allow the device to be managed, the subscription SHOULD be refreshed and maintained while the device is active and expecting to be managed. The default expiration time for subscriptions within this event package is one hour. 4.5. NOTIFY Bodies The NOTIFY request messages MAY contain bodies that are appropriate to specific management protocols, as indicated by the "Accept" headers in the SUBSCRIBE message. A generally applicable body type ("application/mgmt-protos-list") for use with multiple protocols is specified below in Section 5. If the "Accept" header is omitted, the "application/mgmt-protos-list" type is assumed. 4.6. Subscriber Generation of SUBSCRIBE Requests The request URI of the SUBSCRIBE request SHOULD be formed exactly as "Device URIs" are formed according to the SIP UA profile delivery framework [4], section 7.13.1. Similarly, the same URI discovery process, as defined in section 8.1.2 of that document, SHOULD be used to discover the host portion of the request URI and the destination addressing of the message, with the difference that in step 3, instead of prefixing the label "sipuaconfig" to domain name in the request URI, the label "sipmgmtrequest" should be used instead. The "To" and "From" headers will typically contain the same URI as is used in the SUBSCRIBE request. The "Accept" header MUST list the content-type(s) expected in the NOTIFY message body. The "Accept" header MAY be omitted when the SUBSCRIBE message body is not empty, in which case the subscriber MUST accept NOTIFY bodies containing the default content type, "application/mgmt-protos-list". If the "Accept" header content-types each imply a particular management protocol, the SUBSCRIBE message body MAY be empty. For example, if a management protocol defines a notification content-type to be used in soliciting a device-initiated management session, the presence of that content-type in the SUBSCRIBE "Accept" header implicitly describes support for that management protocol. When the device knows it is shutting down or will become unreachable, the device SHOULD unsubscribe by sending a SUBSCRIBE message with an "Expires" header value of "0". Littlefield Expires April 23, 2007 [Page 6] Internet-Draft SIP Management Request Event Package October 2006 4.7. Notifier Processing of SUBSCRIBE Requests The general rules for notifier processing of SUBSCRIBE requests, as specified in RFC 3265 [3] apply. On receipt of a SUBSCRIBE message with the "management-req" event type, the notifier SHOULD authenticate the request. If the notifier does not support any of the content-types specified in the "Accept" header of the SUBSCRIBE request, nor any of the management protocols listed in the SUBSCRIBE message body, or if the SUBSCRIBE request message omitted the "Accept" header and did not provide a message body of type "application/mgmt-protos-list", the subscription SHOULD be rejected. In accordance with RFC 3265 [3], the notifier MUST send a NOTIFY message immediately upon successfully accepting or refreshing a subscription. If a management session is not desired at that time, the NOTIFY message MUST contain an empty body, indicating that this NOTIFY simply confirms the successful subscription and has no further meaning. The notifier MAY limit the duration of the subscription to an administratively configured period of time, as described in RFC 3265 [3]. 4.8. Notifier Generation of NOTIFY Requests When a management session with the managed device is desired (the mechanism for communicating this to the notifier is outside the scope of this specification), the notifier will form a NOTIFY request containing a message body appropriate to the acceptable types determined from the SUBSCRIBE request. The NOTIFY message body will indicate, either implicitly or explicitly, through the content-type, the desired management protocol for the device to use when establishing a management session. The notifier MAY send a NOTIFY with an "Expires" header value of "0", a "Subscription-State" header value of "terminated", and a "reason" code of "deactivated" or "probation" to end the subscription in the event of shutdown. When a security association (e.g. TLS) is used, the notifier SHOULD send the NOTIFY message over the same security association as the SUBSCRIBE request was received. 4.9. Subscriber Processing of NOTIFY Requests The general rules for subscriber processing of NOTIFY requests, as Littlefield Expires April 23, 2007 [Page 7] Internet-Draft SIP Management Request Event Package October 2006 specified in RFC 3265 [3] apply. Upon receipt of a valid NOTIFY request, the subscriber should evaluate the message body. If the NOTIFY message body is empty, as will likely be the case for the initial NOTIFY following a new or refreshed subscription, no further action is required. Otherwise, the subscriber MUST immediately attempt to establish a management session according to the mechanism and protocol indicated by the message body. Considerations of whether a subscriber should attempt to establish multiple, parallel management sessions with the same management station are beyond the scope of this specification, and should be defined for each specific management protocol as appropriate. 4.10. Handling of Forked Requests This event package does not allow forked requests to install multiple subscriptions. The techniques of RFC 3265 [3] section 4.4.9 must be used to prevent establishment of multiple subscriptions due to forking. 4.11. Rate of Notifications A notifier SHOULD implement a method to hold or otherwise avoid sending non-empty NOTIFY requests more frequently than some administratively-specified time interval. A NOTIFY request in this event package indicates the desire to establish a management session, which may impose some overhead on both the managed device and the management station. In some cases, all management sessions from the managed device will be established with the same pre-configured management station, further reducing the value of frequent notifications. The NOTIFIER SHOULD apply rate limits that are appropriate for the connection mechanisms of the management protocols being used. 4.12. State Agents State agents are not applicable to this event package. 4.13. Examples of Usage This following call flows and message illustrations are purely informative. Via headers are omitted from the message illustrations for clarity. Littlefield Expires April 23, 2007 [Page 8] Internet-Draft SIP Management Request Event Package October 2006 4.13.1. Example using SNMP over SSH A typical usage of this event package is illustrated below: Device NAT/NATP/Firewall Mgmt Station | | | (1) |----SIP SUBSCRIBE (snmp-ssh)---->| | | | (2) |<------------200 OK--------------| | | | (3) |<------SIP NOTIFY (empty)--------| | | | (4) |-------------200 OK------------->| | | | . . . . (5) |<-----SIP NOTIFY (snmp-ssh)------| | | | (6) |-------------200 OK------------->| | | | | | | (7) |-----------SSH connect---------->| | | | |<==========SSH session==========>| | | | | | | |<--------SNMP GetRequest---------| | | | |--------SNMP GetResponse-------->| | | | |<--------SNMP SetRequest---------| | | | |--------SNMP SetResponse-------->| | | | |<--------SSH disconnect----------| | | | Littlefield Expires April 23, 2007 [Page 9] Internet-Draft SIP Management Request Event Package October 2006 This shows a device sending a SUBSCRIBE for the management request event package to a management station (1): SUBSCRIBE sip:MAC%3aFF00000036C5@example.com SIP/2.0 Event: management-req From: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 To: sip:MAC%3aFF00000036C5@example.com Call-ID: 02938403840@10.1.20.2 CSeq: 298 SUBSCRIBE Contact: sip:MAC%3aFF00000036C5@10.1.20.2 Accept: application/mgmt-protos-list Content-Type: application/mgmt-protos-list Content-Length: ... snmp-ssh The message body contains an indication that the device supports the SNMP over SSH management protocol, and expects to receive notifications containing content-type "application/mgmt-protos-list". The management station recognizes the requested management protocol type, "snmp-ssh", and accepts the subscription, issuing a 200 OK (2) to the SUBSCRIBE: SIP/2.0 200 OK From: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 To: sip:MAC%3aFF00000036C5@example.com;tag=11a89b Call-ID: 02938403840@10.1.20.2 CSeq: 298 SUBSCRIBE Expires: 3600 The management station then sends the initial NOTIFY request (3) with the current subscription state. Since no management session is desired at this time, the NOTIFY message body is empty: NOTIFY sip:MAC%3aFF00000036C5@10.1.20.2 SIP/2.0 From: sip:MAC%3aFF00000036C5@example.com;tag=11a89b To: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 Call-ID: 02938403840@10.1.20.2 CSeq: 988 NOTIFY Event: reg Subscription-State: active Content-Length: 0 The device responds with 200 OK (4). Littlefield Expires April 23, 2007 [Page 10] Internet-Draft SIP Management Request Event Package October 2006 At some later time, the management station needs to establish a management session with the device. The management station sends a NOTIFY request (5) to the device requesting that the device establish a session using SNMP over SSH: NOTIFY sip:MAC%3aFF00000036C5@10.1.20.2 SIP/2.0 From: sip:MAC%3aFF00000036C5@example.com;tag=11a89b To: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 Call-ID: 02938403840@10.1.20.2 CSeq: 1022 NOTIFY Event: reg Content-Type: application/mgmt-protos-list Content-Length: ... snmp-ssh The device responds with 200 OK (6). The device then immediately initiates an SSH connection to the management station for SNMP (7)[5]. Once established, the management station can send SNMP GetRequest and SetRequest messages to the device to accomplish the needed task. In this example, the SSH connection is illustrated as being made to the same entity as the management station SIP UA, but there is no reason that must be the case. In fact, we assume here that the SSH connection is made to a server whose name or address was pre- configured (possibly using the SIP UA profile delivery framework), and that management server may simply be coordinating with the notifier with a management connection is needed. Littlefield Expires April 23, 2007 [Page 11] Internet-Draft SIP Management Request Event Package October 2006 4.13.2. Example using vendor-specific management protocol The following illustrates the use the event packet to negotiate and use a hypothetical vendor-specific management protocol, VNDX, which is carried over TCP. Device NAT/NATP/Firewall Mgmt Station | | | (1) |------SIP SUBSCRIBE (vndx)------>| | | | (2) |<------------200 OK--------------| | | | (3) |<------SIP NOTIFY (empty)--------| | | | (4) |-------------200 OK------------->| | | | . . . . (5) |<-------SIP NOTIFY (vndx)--------| | | | (6) |-------------200 OK------------->| | | | | | | (7) |-----------TCP connect---------->| | | | |-----------VNDX Inform---------->| | | | |<---------VNDX GetData-----------| | | | |----------VNDX Response--------->| | | | |<--------TCP disconnect----------| | | | Littlefield Expires April 23, 2007 [Page 12] Internet-Draft SIP Management Request Event Package October 2006 This shows a device sending a SUBSCRIBE for the management request event package to a management station (1): SUBSCRIBE sip:MAC%3aFF00000036C5@example.com SIP/2.0 Event: management-req From: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 To: sip:MAC%3aFF00000036C5@example.com Call-ID: 02938403840@10.1.20.2 CSeq: 102 SUBSCRIBE Contact: sip:MAC%3aFF00000036C5@10.1.20.2 Accept: application/mgmt-protos-list,application/vnd.vendx.notify Content-Type: application/mgmt-protos-list Content-Length: ... snmp-ssh The message body contains an indication that the device supports the SNMP over SSH management protocol. The "Accept" header implicitly indicates that the device also supports the VNDX protocol by including the specific notification content-type defined for by that protocol ("application/vnd.vendx.notify"). The "Accept" header indicates that the device is prepared to receive notifications containing the VNDX notification format, as well as the general "application/mgmt-protos-list" content-type. If the device supported only the VNDX protocol, it would not have included the "application/mgmt-protos-list" content-type in the "Accept" header, and would not have included a SUBSCRIBE message body. The management station recognizes the vendor-specific management protocol, and accepts the subscription, issuing a 200 OK (2) to the SUBSCRIBE: SIP/2.0 200 OK From: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 To: sip:MAC%3aFF00000036C5@example.com;tag=11a89b Call-ID: 02938403840@10.1.20.2 CSeq: 102 SUBSCRIBE Expires: 3600 Littlefield Expires April 23, 2007 [Page 13] Internet-Draft SIP Management Request Event Package October 2006 The management station then sends the initial NOTIFY request (3) with the current subscription state. Since no management session is desired at this time, the NOTIFY message body is empty: NOTIFY sip:MAC%3aFF00000036C5@10.1.20.2 SIP/2.0 From: sip:MAC%3aFF00000036C5@example.com;tag=11a89b To: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 Call-ID: 02938403840@10.1.20.2 CSeq: 520 NOTIFY Event: reg Subscription-State: active Content-Length: 0 The device responds with 200 OK (4). At some later time, the management station needs to establish a management session with the device. The management station sends a NOTIFY request (5) to the device requesting that the device establish a session using the VNDX protocol: NOTIFY sip:MAC%3aFF00000036C5@10.1.20.2 SIP/2.0 From: sip:MAC%3aFF00000036C5@example.com;tag=11a89b To: sip:MAC%3aFF00000036C5@example.com;tag=4039c9 Call-ID: 02938403840@10.1.20.2 CSeq: 552 NOTIFY Event: reg Content-Type: application/vnd.vendx.notify Content-Length: ... REQUEST VNDX/1.0 session-id: f09920abe99d0 nonce: XOIMJ0982JOJ00S0 time: 1161365287 sig: 7868881CA0719777B3280EB3490DC176 The device responds with 200 OK (6). The device then immediately initiates a TCP connection to the management station for the VNDX protocol. Once established, the management station can send VNDX protocol messages to the device to accomplish the needed task. 5. Management Protocol List Document [[Comment.1: This document structure needs to be defined. It is anticipated to contain an ordered list of management protocols, where Littlefield Expires April 23, 2007 [Page 14] Internet-Draft SIP Management Request Event Package October 2006 each management protocol may be composed of a protocol part and a transport part, such as "snmp-udp", "snmp-ssh", "snmp-tls", or "snmp- tcp". Consideration must be given to whether or not an existing protocol name registry can be used, or a new IANA registry must be created.]] 6. Security Considerations The intent of this event package is to enable establishment of management sessions. The security aspects of the management session itself are beyond the scope of this specification, but must be strongly considered when this event package is used. Mutual authentication of the resulting management session SHOULD be provided, though this depends on the authorization policies of both the managed device and the management station, and the operations that will be allowed. The security concerns of this event package itself depend to some extent on its use. In a scenario where the NOTIFY does not contain any information about which management station to contact, as is true for the NOTIFY message body content-type defined in this document, a forged or altered NOTIFY message will result in directing the managed device to an attacker for establishment of a management session. However, a form of denial of service (DOS) attack may result of the managed device does not rate limit its own attempts to establish management sessions. The authenticity of the NOTIFY source, and, in the case of NOTIFY message bodies which direct the managed device to a particular management server, the NOTIFY message body, SHOULD be ensured by use of appropriate end-to-end or hop-by-hop security mechanisms defined in RFC 3261 [2]. 7. IANA Considerations 7.1. SIP Event Package Registration for "management-req" Package name: management-req Package or Template: package Contact: Joshua Littlefield, joshl@cisco.com Littlefield Expires April 23, 2007 [Page 15] Internet-Draft SIP Management Request Event Package October 2006 Published Document: [This document] 7.2. MIME Registration for "application/mgmt-protos-list" MIME media type name: application MIME subtype name: mgmt-protos-list Required parameters: none Optional parameters: none Encoding considerations: This type is only defined for transfer via SIP [2]. Security considerations: none Interoperability considerations: none Published specification: [This document] Applications which use this media: The mgmt-protos-list application subtype supports the exchange of supported and desired management protocol names between managed SIP devices and management stations. Additional information: 1. Magic number(s): N/A 2. File extension(s): N/A 3. Macintosh file type code: N/A 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. Littlefield Expires April 23, 2007 [Page 16] Internet-Draft SIP Management Request Event Package October 2006 [4] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-09.txt (work in progress), October 2006. 8.2. Informative References [5] Harrington, D. and J. Salowey, "Secure Shell Transport Model for SNMP", draft-ietf-isms-secshell-05.txt (work in progress), October 2006. Littlefield Expires April 23, 2007 [Page 17] Internet-Draft SIP Management Request Event Package October 2006 Author's Address Josh Littlefield Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA Phone: +1 978-936-1379 Email: joshl@cisco.com Littlefield Expires April 23, 2007 [Page 18] Internet-Draft SIP Management Request Event Package October 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Littlefield Expires April 23, 2007 [Page 19]