S. Channabasappa
Internet-Draft J-F. Mule
Expires: August 30, 2006 CableLabs
February 26, 2006
Use Cases and Considerations for SIP Client Configuration and Management
draft-channabasappa-sipua-config-mgmt-00.txt
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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides use cases for the configuration and management
of SIP-based devices (SIP client and applications) based on available
IETF protocols and related methodologies. The use cases have been
made generic enough to take into account common network topologies
and requirements in SIP service deployments.
Based on the use cases, we present a preliminary analysis of
available IETF protocols that meet these requirements and highlight
some of the limitations.
Channabasappa & Mule Expires August 30, 2006 [Page 1]
Internet-Draft SIP Config and Management Considerations February 2006
Finally, a summary section captures the main findings to generate
further discussion with the relevant IETF working groups. It is the
intent of the authors to seek general feedback from the IETF
community on the approaches outlined in this document, especially in
the OPS area and in SIPPING.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SIP UA Config and Management - Basic Scenario and Use Cases . 4
3. Use Case 1: SIP client provisioning using XML-based
configuration and data modeling . . . . . . . . . . . . . . . 6
4. Use Case 2: Access Control Definitions and XML-based
configuration methodologies . . . . . . . . . . . . . . . . . 11
5. Use Case 3: Management of clients behind firewalls (and
NATs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Summary and Next Steps . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Channabasappa & Mule Expires August 30, 2006 [Page 2]
Internet-Draft SIP Config and Management Considerations February 2006
1. Overview
A couple of IETF working groups, OPS area and BoF meetings have
reported the various emerging models and requirements to configure
devices or applications and perform some monitoring or element
management of such devices or apps.
Various working groups are also defining the new IETF toolkit
available to end-users, product vendors, enterprises and service
providers to meet these configuration and element management
requirements, including NETCONF, ISMS, SIP, SIPPING, SIMPLE, CallHome
BoF to cite a few.
At the same time, many IP networks are seeing a shift in the types
and variety of SIP-based communication clients being used and the
associated configuration and management needs are evolving.
A communication client may be software or hardware-based, embedded
into an access network bridge or router, or a standalone device; it
may operate on diverse platforms (PDAs, PCs, Mobile phones, home
router) and operating systems (real and non-real time), with
differing requirements related to capabilities, memory and CPU
constraints.
As described in XCAP, multiple end-users can share a client and
multiple clients can be bound to an end-user.
In short, from a configuration and management standpoint, the above
means:
o increased configuration requirements to handle multiple profiles
and dynamic changes.
Configuration changes may be generated by multiple sources: an
end-user (based on application usage needs), a client (based on
network conditions or profile usage), or an actor (admin user,
enterprise IT or service provider sysadmin);
o support for configuration and management of clients with single or
dual IP stacks with IPv4 and IPv6 support which may be behind NATs
and firewalls.
This document attempts to describe a basic scenario for configuring
and managing SIP devices by providing a couple of common use cases
and looking at the available solutions in the IETF toolkit. Our goal
is to show the design choices some folks are confronted with and
underline open issues to support some of the current IETF work and,
more importantly, outline some areas that potentially need more work.
Channabasappa & Mule Expires August 30, 2006 [Page 3]
Internet-Draft SIP Config and Management Considerations February 2006
2. SIP UA Config and Management - Basic Scenario and Use Cases
The basic scenario we use in this document is the one of an end-user,
enterprise or service provider (an actor) wanting to configure and
manage its SIP-based client and SIP-related application functionality
by using available IETF protocols and existing element management
tools (through various user interfaces: Command Line Interfaces, web-
based views, or even management protocols via SNMP [RFC3411] for some
categories of actors). The SIP client may be dual-stack IPv4 and
IPv6 and may or may not be behind a home-based or network-based NAT:
this special case is only secondary and invoked in the third use
case.
We consider three use cases derived from this basic scenario:
o SIP client provisioning using XML-based configuration protocols
with common management and data modeling techniques.
The configuration of a SIP client is based on the use of IETF
SIPPING Configuration framework ([ID-SIP-CFG]) and the IETF XCAP
protocol ([ID-XCAP]) with the addition of commonly used MIB design
methodologies using the Structure of Management Information (SMI)
to solve the lack of XML data modeling. The use case illustrates
the shift in client configuration methodology and elaborates on
how SNMP configuration is evolving into XML-based configuration.
We insist on some SNMP-based modeling techniques that could be of
valuable to re-use for describing data elements for the purpose of
management: especially but not exclusively when the SNMP protocol
is used for management in conjunction with XML configuration.
o Management of access control for SIP client configuration based on
SIPPING-config and XCAP based on XML data modeling:
When using the IETF SIPPING configuration framework and XML-based
configuration via XCAP, the actor should have flexible means to
define the type of access on a particular object or XCAP target
(read, write, execute, notify, etc.). Access control should also
provide multiple access control levels for a particular object,
similar to the UNIX access control lists: owner (user), group,
others.
o Management of SIP devices behind NATs and firewalls:
All types of actors want their SIP clients or devices to
transparently operate behind well-behaved NATs and firewalls. The
use case takes the specific instance of a service provider or an
enterprise wanting to manage IPv4-IPv6 SIP devices using CLI or
protocols like SNMP or HTTP over secure transport. We look at how
management sessions for clients behind firewalls (and may be NATs)
require from the use of SIP signaling stimulus.
Channabasappa & Mule Expires August 30, 2006 [Page 4]
Internet-Draft SIP Config and Management Considerations February 2006
The next sections provide more details on the three distinct use
cases and indicate potential solutions based on IETF protocols.
Channabasappa & Mule Expires August 30, 2006 [Page 5]
Internet-Draft SIP Config and Management Considerations February 2006
3. Use Case 1: SIP client provisioning using XML-based configuration
and data modeling
In this section, we consider a SIP client being provisioned using
XML-based configuration protocols (IETF SIPPING configuration
framework and IETF XCAP protocol). We investigate how re-using some
of the commonly used MIB design methodologies may help to solve the
lack of XML data modeling.
While the intent of the use case is generic, taking a specific
example of cable service providers should help provide some context.
This may also be applicable to other actors, enterprises and service
providers in particular. The main point is not to insist on the use
of SNMP but more importantly, to underline how engineers and
implementers have used the SMI data model associated with SNMP to
design configuration files.
Traditionally, devices in cable networks (e.g. DOCSIS(r) cable
modems, PacketCable VoIP clients) have used SMI-based
([RFC1155],[RFC2578]) SNMP MIB modules as a means to represent both
configuration and management data elements. Device management is
performed using the IETF SNMP protocols and recommendations. The
initial device configuration relies on a configuration file
downloaded via TFTP or HTTP whose content includes TLV attributes
(Type, Length, Value): each TLV in a typical client configuration
file represents an SNMP variable binding: a configuration parameter
and its initial value.
This process is illustrated in Figure X1. A cable device or client
obtains its configuration file, populates the configuration
parameters by 'internally' setting the corresponding SNMP MIB objects
and proceeds to initialization of the supported services and is ready
to be managed by element management systems based on SNMP.
Note that the configuration file was provided using TFTP (or HTTP) on
a one-time basis (during bootstrapping) as opposed to using a
configuration protocol that can support dynamic changes.
Channabasappa & Mule Expires August 30, 2006 [Page 6]
Internet-Draft SIP Config and Management Considerations February 2006
---------------------------
|Configuration data elements|
| Name, data type, default |
| value, access type (read, |
| write, etc.) |
---------------------------
|
V
------------------
|MIB module design |
| (SMIv2) |
------------------
|
V
--------------
/ \
| Configuration |
| file |
| (TLV SNMP |
| varbinds) |
\ /
---------------
|
V
Configuration ----------------
---------------------------->| TFTP/HTTP |
| | Server |
| ----------------
V
-------------
| Client |
-------------
^
| ---------------
| Management | EMS/NMS |
---------------------------->|(SNMP Manager) |
---------------
Figure X1: Traditional configuration of cable clients managed via
SNMP
A couple of points are worth noting in the data modeling process:
- Modeling data using SMI to create a MIB module may not always be
perceived as adequate, elegant or efficient by many, but there are
Channabasappa & Mule Expires August 30, 2006 [Page 7]
Internet-Draft SIP Config and Management Considerations February 2006
many design guideline documents available and it is used by the MIB
designers in the IETF community. The experience gained over the
years is invaluable;
- there are many tools available to check the syntax of MIB modules
and enforce strict adherence to the SMI (e.g. boundaries for integer
values, default values, formatting of the display of strings, re-
usability of textual conventions facilitating interoperability and
eliminating the parsing of free form strings, etc.);
- there are numerous data models built on SMI that would benefit from
being available in the XML-based data modeling world in support of
configuration or management.
Moving to the use case at hand, the increased client configuration
requirements, the recognition that SNMP is rarely used for
configuration (NETCONF), and the good work done by the IETF SIPPING
working group on the configuration framework (([ID-SIP-CFG])) has led
many to explore an XML-based configuration model.
The configuration of SIP-based clients and devices in this example is
based the configuration proposals available in the IETF for SIP User
Agents (UAs) configuration, the eXtensible Markup Language
Configuration Access Protocol (XCAP) is chosen as the configuration
protocol of choice for this use case.
Client management is left unexplored by many proposals: it is not in
scope of XCAP or not fully addressed by NETCONF. In this use case,
we propose to use SMI for three main reasons:
1. to overcome the lack of XML data modeling for element management
and configuration,
2. to leverage the guidelines and experience in doing configuration
and management modeling using well-defined techniques,
3. to provide continuity for some actors that may manage devices
using SNMP.
This may be where the use case becomes more specific but we believe
that even without the use of SNMP, re-using SMI brings some clear
advantages.
For these reasons, SMI-to-XML Schema transformations are accomplished
to provide XML Schemas ([IR-SMI-XML]). This enables the same
operation as shown in Figure X1, but supports a full-fledged SIPPING
and XCAP configuration protocols and allows SNMP management (SNMP
management means SNMP for monitoring here (e.g. GET), not for
configuration (e.g. SET)).
Given the IETF does not have any standard XML-based data modeling
proposals, the SMI-to-XML conversion mechanism seems to provide a
stop-gap solution for supporting some element configuration. It is
important to realize that folks who do not want to deal with SMI or
ASN.1 will obtain the derived XML schemas. Rather than defining
Channabasappa & Mule Expires August 30, 2006 [Page 8]
Internet-Draft SIP Config and Management Considerations February 2006
those schemas from scratch, SMI is used as an intermediary step.
This may be seen as short-sighted but in the short term, and
potentially long-term, it may provide a viable solution.
------------------
|MIB module design |
| (SMI) |
------------------
|
V
--------------
/ \
| SMI to XML |
\ /
---------------
|
V
Configuration ----------------
---------------------------->| XCAP |
| | Server |
| ----------------
V
-------------
| Client |
| SIP UA |
-------------
Figure X2: Configuration of SIP clients via XCAP using SMI for data
modeling
Channabasappa & Mule Expires August 30, 2006 [Page 9]
Internet-Draft SIP Config and Management Considerations February 2006
------------------
|MIB module design |
| (SMI) |
------------------
|
V
--------------
/ \
| SMI to XML |
\ /
---------------
|
V
Configuration ----------------
---------------------------->| XCAP |
| | Server |
| ----------------
V
-------------
| Client |
| SIP UA |
|+ SNMP Client|
-------------
^
| ---------------
| Management | EMS/NMS |
---------------------------->|(SNMP Manager) |
---------------
Figure X3: Configuration of SIP clients via XCAP and Management via
SNMP
In conclusion, the co-authors believe that a well-defined XML data
model for configuration and management is required. While it has
surfaced in some working groups (netconf [ID-NETCONF] for example),
it is not available today. The long-term solution may be to define a
new model in IETF or elsewhere but in the short-term, given the
availability of SMI design guidelines and tools, and the experience
that can be leveraged from the SNMP community on configuration data
design, the IETF should continue the work initiated on SMI-to-XML to
provide a standard means to perform quick and reliable syntax
conversions.
Channabasappa & Mule Expires August 30, 2006 [Page 10]
Internet-Draft SIP Config and Management Considerations February 2006
4. Use Case 2: Access Control Definitions and XML-based configuration
methodologies
Access control definitions allow data model designers to choose
access rights and restrictions for the defined data elements. Most
everyone is familiar with the UNIX ACL management associated with the
file system: each file has read/write/execute access rights for the
owner, group, and others. The View-based Access Control Model (VACM)
for SNMP is also a good reference as it is applied to configuration
([RFC3415]).
In this use case, we look at the change in data ownership that is
introduced by XML-based configuration models and protocols (XCAP as
an example) and conclude that access control definitions for XML-
based data models is a necessity. This use may be viewed as an
extension of the first one and it also shows some areas that are not
addressed by the SMI-to-XML conversions.
Use case description:
A SIP client is configured using the SIPPING configuration framework
and XCAP. Changes in the configuration data elements may occur at
multiple levels (write access): based on end-user settings on the SIP
device, remote configuration changes (end-user accessing a web-based
interface to change settings or a service operator updating the
config), and many other means (software updates from device
manufacturer changing some default configuration parameters, etc.).
Furthermore, the presentation of some configuration data (read
access) may also have to be controlled: not all users of a client may
be allowed to change the settings, some settings may be hidden by the
protocol stacks, device manufacturers or service providers so that
end-users may not misconfigure the device and disrupt the service.
Note that the mechanism by which the configuration change is not a
factor in this use case: a configuration change may be operated via a
custom user interface on the SIP device or application, an end-user
or operator controlled CLI, remote web-based interface.
Problem statement:
How does the designer of the XML schema specify access rights for
each data element and for each level (owner, group, others) in an
interoperable manner?
To provide more context to the use case, we compare this problem
statement with the SNMP or SMI-based model even though, as stated
above, the problem statement is independent of SNMP. Clients with an
SNMP agent store configuration data as instances of the SNMP MIB
objects. Changes to such data by authorized network elements is
accomplished via SNMP through EMS and NMS systems. Any change is
authorized by the SNMP agent based on the SMI access control
Channabasappa & Mule Expires August 30, 2006 [Page 11]
Internet-Draft SIP Config and Management Considerations February 2006
definitions (specified by the MAX-ACCESS clause).
This arrangement is suitable when dynamic configuration changes are
minimal: the configuration data is stored on the client and the model
works well when there is a single source of changes. There are
examples of MIB modules that have been defined where an object was
not writable via SNMP but since the object value could be changed
during runtime or by the end-user: a note was put in the DESCRIPTION
clause.
This is illustrated in Figure Z1.
----------
| Network |
| Elements |
----------
|
|
| Configuration
| Changes
---------------- |
| Client | |
| (SNMP agent) | V
| ------------ | ---------
| | Config | | Configuration changes | EMS/NMS |
| | Data | |<------------------------->| (SNMP |
| ------------ | | Manager)|
| ----------- | ---------
| | Management | | Management |
| | Data | |<-------------------------------
| ----------- |
| |
----------------
Figure Z1: Example of Configuration and Management using SNMP
With the use of a configuration protocol like XCAP, this paradigm has
shifted as illustrated in Figure Z2.
Channabasappa & Mule Expires August 30, 2006 [Page 12]
Internet-Draft SIP Config and Management Considerations February 2006
----------
| Network |
| Elements |
----------
^
|
-------------- |
| Config Server | |
| (XCAP Server) | |
| ----------- | |
| | Config | | |
| | Data | |<---------
| ----------- |
---------------
^
Configuration |
-----------------------
|
|
|
V
----------------
| Client |
| (XCAP Client) | --------------------
| ----------- | Management | Management App |
| | Management | |<----------------------| (SNMP, CLI, |
| | Data | | | web-based etc) |
| ----------- | --------------------
----------------
Figure Z2: Configuration and Management using various protocols
A separate configuration server (for example, the XCAP Server in the
above figure) is responsible for the storage and modification of
data. This configuration data is accessible by clients and
authorized network elements alike.
The importance of access control can be illustrated by many examples:
assume a data element that is accessible by both the client and a
network element, but is modifiable only via the network element
(e.g.: my speed dial list or favorite friends' URI list is modifiable
via a web-based application talking to the "Network Element"). One
would expect the XCAP server, the 'keeper' of the data, to enforce
this access control requirement. Should this be expressed in the XML
Schema?
Channabasappa & Mule Expires August 30, 2006 [Page 13]
Internet-Draft SIP Config and Management Considerations February 2006
Further, multiple data profiles can be built out of the same set of
data elements, but with different access control settings. There may
also be multiple entity types that share the same access control
sets. All this hints at UNIX-like or VACM-like grouping of access
controls.
Additionally, the fact that the same XML Schema definitions may call
for run-time change in access privileges should also be taken into
consideration. This may call for the ability to provide access
control definitions internal or external to the XML data models (for
example via XPATH).
In conclusion, as we hope this use case illustrates, the co-authors
believe there is a need for standardization of Access Control
directives to enable configuration and management in general, and
XCAP in particular, to be effectively deployed at wide scale and for
a wide range of applications.
Channabasappa & Mule Expires August 30, 2006 [Page 14]
Internet-Draft SIP Config and Management Considerations February 2006
5. Use Case 3: Management of clients behind firewalls (and NATs)
The issues of establishing SIP sessions behind NATs and firewalls
have been extensively discussed in IETF in SIPPING, BEHAVE, MIDCOM
and other groups. We focus on the establishment of a management
session between a SIP client and a management stationt 'separated by
a firewall (and NAT) device. Any command or management operation
should be initiated by the client.
------------ ------- ---------------
| Client | |NAT-FW | | EMS/NMS/web |
| | |Device | | Mgmt Station |
------------- ------- ---------------
| | |
| X|<-----------------| Retrieve Operations
| | | (Management host
| | | initiated)
| | |
| | |
| | |
| X|<-----------------| Modification Operations
| | | (Management host
| | | initiated)
| | |
| | |
| | |
| | | Notifications
|--------------->|----------------->| (Client initiated)
| | |
| | |
Figure Y2: Management operations affected in the presence of
firewalls (and sometimes NATs depending on the protocol used)
A management session may be established by the client for an
undefined period of time (session stays up which could be resource
intensive). For efficiency, it should be initiated as needed, based
on a stimulus from the management host. For SIP clients, this
solution may be made possible by using the same signaling mechanisms
proposed in the SIPPING Configuration framework, for e.g. using the
SIP SUBSCRIBE/NOTIFY framework. A client could subscribe to
Channabasappa & Mule Expires August 30, 2006 [Page 15]
Internet-Draft SIP Config and Management Considerations February 2006
management events and would get notified to initiated a management
session. This is illustrated in Figure Y3.
------------ ------- ---------------
| Client | | NAT | | EMS/NMS |
| | | fw | | |
------------- ------- ---------------
| | |
|< - - - - - - - |----------------->| Previously
| | | established SIP
| | | session
| | |(e.g. SIP SUBSCRIBE/NOTIFY)
| | |
|<- - - - - - - -|<-----------------| Notification
| | | (e.g. SIP NOTIFY)
| | |
| | |
|- - - - - - - - |----------------->| Management Session
| | | establishment
| | | (CLI or SNMP over ssh,
| | | HTTPS, etc.)
| | |
|<- - - - - - - >|<---------------->| Retrieve Operations
| | | (Management initiated)
| | |
| | |
| | |
|<- - - - - - - >|<---------------->| Modification Operations
| | | (Management initiated)
| | |
| | |
| | |
| | | Notifications
|- - - - - - - ->|----------------->| (Client initiated)
| | |
| | |
Figure Y3 Initiating management sessions in the presence of firewall
- NAT devices
In conclusion, the use case highlights the needs to define a generic
mechanism for establishing a client-initiated management connection
Channabasappa & Mule Expires August 30, 2006 [Page 16]
Internet-Draft SIP Config and Management Considerations February 2006
when a SIP session pre-exists.
The components of such a solution may include:
- defining how SIP can be used to establish a management session,
- defining a SIP event package for conveying the relevant management
session parameters (IP and transport addresses of the management
station, the type of transport protocol to use for management -
HTTPS, SNMP over SSH, etc.).
Channabasappa & Mule Expires August 30, 2006 [Page 17]
Internet-Draft SIP Config and Management Considerations February 2006
6. Summary and Next Steps
In summary, this document presents three use cases for the
configuration and management of SIP clients or devices using IETF
protocols. The proposed approaches lead to following findings and
suggestions:
o An XML data modeling specification for configuration and
management is required. The experimental SMI to XML conversion
methods provide an elegant, short term solution for some actors.
It leverages the experience and tools for building modules for
management purposes. It allow the reuse of some existing data
models based on SMI with XML based configuration protocols like
XCAP ([ID-XCAP]). There have been proposals in the past
([IR-SMI-XML]) that have been implemented, and, based on some
prototyping experimentation, the co-authors of this document
recommend that this proposal be revisited.
o XML-based configuration protocols can greatly benefit from a
standardized access control definition methodology. This would
foster effective deployment of XML based configuration protocols.
o Solutions developed in some OPS working groups should address the
management of clients behind NATs and firewalls, so that IPv4 and
dual-stack IPv4-IPv6 clients may be managed efficiently. An
example specific to SNMP would be to invite proposals to the ISMS
WG to help address the NAT and firewall traversal within the scope
of modified transport ([ID-SNMP-SSH]) and security models
([ID-SNMP-TMSM]).
o The SIP community may benefit from defining solutions to enable
client-initiated management connection when a SIP session exists.
A new SIP event package may be used part of the solution
([RFC3265]).
Channabasappa & Mule Expires August 30, 2006 [Page 18]
Internet-Draft SIP Config and Management Considerations February 2006
7. Acknowledgments
The authors of this draft wish to thank members of the CableLabs
PacketCable focus teams and various other IETF participants who
contributed directly or indirectly to the content presented in this
draft. Specifically, the following individuals are recognized: Josh
Littlefield, Eugene Nechamkin, Paul Duffy, Thomas Clack, Harindranath
P.R Nair.
We also thank Juergen Schoenwaelder and Frank Strausse for the email
exchanges.
Channabasappa & Mule Expires August 30, 2006 [Page 19]
Internet-Draft SIP Config and Management Considerations February 2006
8. Security Considerations
FFS.
Channabasappa & Mule Expires August 30, 2006 [Page 20]
Internet-Draft SIP Config and Management Considerations February 2006
9. References
9.1. Normative References
[ID-SIP-CFG]
Petrie, D., "A Framework for Session Initiation Protocol
User Agent Profile Delivery", July 2005.
[ID-SNMP-SSH]
Harrington, D. and J. Salowey, "Secure Shell Security
Model for SNMP", Feb 2006.
[ID-SNMP-TMSM]
Harrington, D. and J. Schoenwaelder, "Transport Mapping
Security Model (TMSM) for the Simple Network Management
Protocol", Oct 2005.
[ID-XCAP] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", October 2005.
[IR-SMI-XML]
Schoenwaelder, J., "Using XML to Exchange SMI
Definitions", January 2002.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification
of management information for TCP/IP-based internets",
STD 16, RFC 1155, May 1990.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
9.2. Informative References
[ID-NETCONF]
Enns, R., "NETCONF Configuration Protocol", Feb 2006.
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415,
Channabasappa & Mule Expires August 30, 2006 [Page 21]
Internet-Draft SIP Config and Management Considerations February 2006
December 2002.
Channabasappa & Mule Expires August 30, 2006 [Page 22]
Internet-Draft SIP Config and Management Considerations February 2006
Authors' Addresses
Sumanth Channabasappa
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: sumanth@cablelabs.com
Jean-Francois Mule
CableLabs
858 Coal Creek Circle
Louisville, CO 80027
USA
Email: jfm@cablelabs.com
Channabasappa & Mule Expires August 30, 2006 [Page 23]
Internet-Draft SIP Config and Management Considerations February 2006
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Channabasappa & Mule Expires August 30, 2006 [Page 24]