[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet Draft                                                D. Petrie
Doc: draft-petrie-sipping-ua-prof-framewk-reqs-00.txt     Pingtel Corp.
24 June 2002                                                C. Jennings
Expires: December 2002                                    Cisco Systems




        Requirements for SIP User Agent Profile Delivery Framework


   Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC2026].

   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.


1 Abstract

   This document attempts to identify the requirements for a protocol
   framework to provide SIP user and device profiles to SIP user
   agents.  The objective is not to invent new special purpose
   protocols, but to identify the requirements such that a rational
   decision can be made as to what existing protocol(s) should be used
   to solve the problem of providing user and device profiles to SIP
   user agents.  This document also contains an evaluation of a set of
   applicable protocols.

2 Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" this
   document are to be interpreted as described in RFC-2119 [RFC2119].









Petrie/Mahy            Exp: Dec. 2002 [Page 1]


                                xxxxx


   Table of Contents
   1  Abstract.......................................................1
   2  Conventions used in this document..............................1
   3  Overview.......................................................3
   3.1 Background.....................................................3
   3.2 Functional Groups..............................................3
   3.3 Terminology....................................................4
   4  Requirements...................................................4
   4.1 General........................................................4
   4.1.1 Roaming......................................................4
   4.1.2 Open and Extensible for Vendor...............................5
   4.1.3 NAT/Firewall Support.........................................5
   4.1.4 Availability of Development Tools............................6
   4.2 Discovery......................................................6
   4.3 Enrollment.....................................................6
   4.4 Profile Retrieval..............................................8
   4.5 Change Notification............................................8
   4.6 Profile Upload.................................................8
   4.7 Security.......................................................9
   4.8 Data Container.................................................9
   5  Protocol Evaluation...........................................10
   5.1 Evaluation Criteria...........................................10
   5.2 SNMP..........................................................11
   5.3 LDAP..........................................................12
   5.4 ACAP..........................................................12
   5.5 SLP...........................................................13
   5.6 SIP Events....................................................14
   5.7 HTTP..........................................................15
   5.8 DHCP Options..................................................16
   5.9 DNS...........................................................16
   5.10 XML..........................................................16
   5.11 RFC 822......................................................16
   6  Security Considerations.......................................16
   7  Conclusion....................................................16
   8  References....................................................18
   9  Acknowledgments...............................................19
   10 Author's Addresses............................................19

















Petrie/Mahy            Exp: Dec. 2002 [Page 2]


                                xxxxx


3 Overview



3.1 Background

   There is a general need to standardize methods for adding, enabling,
   and maintaining user and device profiles used by SIP user agents
   within a VoIP system. When one considers the effort needed to set up
   systems with hundreds or thousands of users and user agents, the
   need for reducing set up time is obvious. After a system is set up,
   ongoing maintenance in the form of changing the user and device
   profiles on a large population of user agents, is likely to be
   necessary and requires a similar administrative effort.

   In addition to these scaling problems, it is likely that the
   population of user agents in any given VoIP system will be
   heterogeneous: the configuration strategy must be flexible enough to
   accommodate different needs for different users. Consequently, for
   VoIP system administration sanity and cost practicality, a multi-
   vendor profile delivery standard is needed.
   This requirements document and protocol evaluation is a more
   formalized update to previous work in progress (e.g. expired draft
   draft-petrie-sip-config-framewk-reqs-00.txt) and evaluation
   performed by the authors.

3.2 Functional Groups

   The requirements for the configuration of a SIP user agent can be
   divided into the following high-level functions:

      ¸
       Discovery
      ¸
       Enrollment
      ¸
       Profile Retrieval
      ¸
       Change Notification
      ¸
       Profile Upload
      ¸
       Security
      ¸
       Data Container

   These functional groups are intended only to provide a means to
   think about and organize the requirements. They are not required to
   be discrete steps, and they are not intended to dictate a specific
   model.

   Discovery û is the means by which a new SIP user agent can
   automatically discover how and where to enroll and retrieve desired
   device and user profile(s).

   Enrollment û is the means by which the user agent makes the profile
   server(s) aware of its presence and desire of specific users and/or
   device profiles.



Petrie/Mahy            Exp: Dec. 2002 [Page 3]


                                xxxxx

   Profile Retrieval û is the means by which the user agent gets the
   desired profiles(s).

   Change Notification û is the means by which the profile server tells
   the user agent that profiles of interest have changed.  Typically
   the intension would be for the user agent to get those changes or
   updated profiles.

   Profile Upload û this is the means by which the user agent or other
   entities in the network can update or propagate changes to a profile
   on the server.

   Security û primarily the focus is on protecting the profiles from
   unauthorized access or change as well as integrity.

   Data Container û the container or object model for the profile data
   during transport to and from the server.  The primary issues are
   structure and hierarchy.

       Note: The specific content is considered out of scope in this
       document.  The content requirements are addressed in [EP-
       CONFIG].  Ideally the container would be considered with the
       content requirements instead of the profile retrieval
       requirements.  However as some of the protocols evaluated have
       an inherent data container the requirements are included in this
       document to keep the comparison on an apples-to-apples basis.

3.3 Terminology

   This document uses the following terminology:

   Server or Profile Server û the server(s) that provide the profile
   delivery framework functions defined above.

   User Agent or Device û the client wishing to get or update the user
   or device profile(s) as defined by the above functional framework.

4 Requirements

   The requirements are categorized by the functional groups defined in
   3.2.  In addition a general set requirements are defined up front.
   Each requirement is given a unique identifier for cross referencing.

4.1 General

   This section contains miscellaneous requirements across all
   functional groups.
4.1.1 Roaming

   GENRREQ-1: The profile delivery framework MUST support the ability
   for profiles to roam.




Petrie/Mahy            Exp: Dec. 2002 [Page 4]


                                xxxxx

   That is, a user may go to another user agent within the serverÆs
   domain and with proper authorization, the user agent must be able to
   retrieve from the server and use the userÆs profile.

4.1.2 Open and Extensible for Vendor

   GENOREQ-10: The profile framework MUST allow vendor differentiation
   on both the server and user agent sides.

       This is largely an issue of how easy it is to make a more
       intelligent or active server or client without breaking the
       standard.

   GENOREQ-11: The profile server MUST be able to opaquely support
   vendor extensions to profiles.

       That is the server should be able to handle uploading of vendor
       specific data in a profile without requiring a new profile
       definition or schema.

4.1.3 NAT/Firewall Support

   There are two primary models in which VoIP systems are deployed:

      ¸
       Hosted VoIP Services ("Centrex" Model)
      ¸
       Locally Administered VoIP systems ("PBX" Model)

   In the extreme case of a hosted model, the only customer premises
   equipment is the LAN and user agents.  In the locally administered
   model all equipment, servers, gateways and user agents are on the
   local premises.  There is of course a spectrum of variations
   between.  In addition there are multi-site enterprise deployments
   that in some aspects may appear more like the hosted model.  The
   user agent in either model may be present in an commercial or in a
   residential environment.

   The primary issue relating to the profile delivery framework is the
   presence of NATs and/or firewalls between the profile server and the
   user agent.  It is assumed that if NATs or firewalls are present (in
   between) the user agents are on the inside and the profile server is
   effectively on the outside (e.g. public Internet).

   GENNREQ-20: The user agent MUST be able to reach the profile server
   through a NAT or firewall to perform all of the functions in the
   delivery framework.

   GENNREQ-21: The firewall or NAT SHOULD not require any additional
   configuration to enable the profile delivery framework to work.

       It is assumed that certain protocols are typically enabled on
       the NAT or firewall by default (e.g. HTTP access to servers
       outside).  It is assumed that SIP access in both directions is
       enabled or the user agent is not likely to be of much use.


Petrie/Mahy            Exp: Dec. 2002 [Page 5]


                                xxxxx

4.1.4 Availability of Development Tools

   The platforms (server and user agent) upon which this profile
   delivery framework must be deployed are very different in
   capability.  The user agents are largely embedded systems with
   limited resources for code and data size as well as CPU power (pure
   software based user agents are less constrained).  The profile
   server is likely to run on general purpose servers and therefore not
   as resource constrained.

   For wide spread adoption of the profile delivery system, the tools
   protocol implementations required to build the profile server should
   be readily available.

   GENAREQ-30: The protocol stack implementations needed to build a
   profile server SHOULD be commercially and/or publicly available,
   preferably with reference or open-source implementations available.

   GENAREQ-31: There SHOULD be multiple implementations of the protocol
   stacks required in the profile server readily available.

   GENAREQ-32: There SHOULD be multiple implementations of the protocol
   stacks required in the user agent readily available.

   GENAREQ-33: There SHOULD be multiple implementations of the protocol
   stacks required in the user agent suitable for embedded systems.



4.2 Discovery

   The purpose of discovery is to provide the means by which zero or
   minimal user interaction is required when plugging in a user agent
   for the first time in a specific profile server domain.  It is
   likely that there is no single protocol solution for discovery due
   to the wide variety of typical network configurations including but
   not limited to networks:
       not connected to the Internet
       with no DHCP server
       with no DNS SRV support
       with a non-configurable DNS server

   DISREQ-1: The user agent SHOULD be able to discover the profile
   server without human input.

   DISREQ-2: It MUST be possible to manually set the location of the
   profile server for a user agent.

       This is primarily a user agent implementation issue not a
       protocol issue.


4.3 Enrollment


Petrie/Mahy            Exp: Dec. 2002 [Page 6]


                                xxxxx

   ENREQ-1: A user agent must be able to provide a unique identity to
   the profile server which does not change for the life of the UA.

       This allows user and device profiles to be associated with a
       particular user agent.

   ENREQ-2: A user agent requiring profiles SHOULD make itself known to
   the profile server.

   ENREQ-3: The user agent MUST identify profiles that it requires.

   ENREQ-4: The profile server MAY be provisioned to know what profiles
   a user agent needs by default.

       There are a number of reasons for the above requirements.  In
       large scale deployments this may be important for load balancing
       purposes. This may be needed by the profile server so that it
       can understand which user agents are dependent upon which
       profiles.

   ENREQ-5: A user agent MAY request additional or different user
   profiles beyond the default provisioned for the user agent.

       This is primarily to support the notion of roaming.

   ENREQ-6: The user agent MUST provide specific information which may
   needed by the server to customize the profile(s) for the user agent.

       It may be necessary to provide different views of a profile
       based upon the specific configuration of the user agent. (for
       example, Vendor, Model number, Software or firmware version,
       serial number, MAC address, etc.).

   ENREQ-7: It SHOULD be possible for the profile server to deliver
   different views of a profile based upon characteristics of the user
   agent.

       Though the objective is to provide a standardized profile that
       has the same content for all vendors user agents, in reality
       there are changes or differences to work around.  That is it may
       be desirable to put intelligence in the profile server to work
       around differences in user agent behavior or changes in the
       standardized profile content specification.

   ENREQ-8: It MUST be possible to reassigned device-specific profiles,
   stored in the server, to a different user agent.

       This is to facilitate hardware swap out.

   ENREQ-9: It MUST be possible for the profile server, over time, to
   change the location(s) from which configuration data is retrieved.

       The intension is to allow server handoff as the result of
       failure, administration changes, load balancing, etc.

Petrie/Mahy            Exp: Dec. 2002 [Page 7]


                                xxxxx


   ENREQ-10: The user agent SHOULD re-enroll periodically.

       The user agent basically should check in periodically with the
       profile server in case a network problem prevented change
       notification from getting to the user agent.

4.4 Profile Retrieval

   PRREQ-1: It MUST be possible for the user agent to retrieve the
   profile(s) it requires on demand.

   PRREQ-2: It MUST be possible for the entire population of user
   agents to request and retrieve the required profiles in a short
   period of time.

       This is a scalability requirement: e.g. during a power outage
       tens or hundreds of thousands of user agents may power up at
       once.



4.5 Change Notification

   CNREQ-1: The profile server MUST be able to notify dependent user
   agents of profile changes.

   CNREQ-2: The user agent MUST be able to get the new updated profile.

   CNREQ-3: The server MAY specify in advance that a configuration
   change is to occur.

       That is the profile server may schedule changes.

   CNREQ-4:  The user agent MAY defer making profile changes effective
   until it is safe to do so.

       Some profile changes may disrupt the operation of the user
       agent.  The user agent should use discretion as to whether the
       change will disrupt critical operation (e.g. a call) of the user
       agent. [Should there be a means of specifying immediate or when
       safe?]

4.6 Profile Upload

   PUREQ-1: A user agent MUST be able to upload changes to a profile on
   the profile server.

       This is to facilitate changes made either via a user interface
       on the user agent which are desired to be permanent as well as a
       means by which a external interface (e.g. a rich GUI on a
       general purpose computer)  may interface with the profile
       server.


Petrie/Mahy            Exp: Dec. 2002 [Page 8]


                                xxxxx

   PUREQ-2: The profile server should provide an access control
   mechanism to constrain who can read, write, delete, or by
   notified about change to profile data.

4.7 Security

   User and device profiles may contain sensitive data such as
   passwords and identities.  It MUST be possible to protect the
   profiles and information about the profiles.

   SECREQ-1: The profile server SHOULD not provide access to profile
   data without authentication and authorization.

   SECREQ-2: The profile server MUST not allow a user agent to update
   profile data without authentication and authorization.

   SECREQ-3: The profile data, when transmitted over the network,
   SHOULD be protected against man in the middle attacks and snooping.

   SECREQ-4: The profile server SHOULD not allow enrollment without
   authentication and authorization.

   SECREQ-5: The profile server SHOULD not provide change notification
   of profiles without authentication and authorization.

   SECREQ-6: The user agent SHOULD not interact with or trust any
   information from the profile server before authenticating the
   profile server.

   SECREQ-7: The information exchanged between the user agent and the
   profile server SHOULD be integrity protected.


4.8 Data Container

   DAREQ-1: The data container MUST support hierarchical and structured
   date.  Note: for a better understanding of rational for this
   requirement see [EP-CONFIG]

   DAREQ-2: It MUST be possible to define a standardized set of profile
   data that all user agents SHOULD support.

   DAREQ-3: It MUST be possible for user agent vendors to add vendor
   specific data without breaking the standardized data set or
   requiring the creation of additional profiles.

   DAREQ-4: The data container MUST be flexible enough to contain
   additional data without breaking the profile server or the user
   agent.

       e.g. non-standard, vendor specific or standard updates

   DAREQ-5: The user agent must be able to determine the differences
   when a profile has changed.

Petrie/Mahy            Exp: Dec. 2002 [Page 9]


                                xxxxx


       Note: this can be either by getting only the added, removed or
       changed data or by calculating the difference between two
       profiles.

5 Protocol Evaluation

   The following set of protocols are those that have been suggested
   for the purpose of SIP user agent profile delivery framework both on
   the SIP and SIPPING mailing lists as well as at past work group
   meetings.

       SNMP
       LDAP
       ACAP
       SLP
       SIP Events
       HTTP
       DHCP Options
       DNS
       XML
       RFC 822

   This is of course not an exhaustive list of possible protocols, but
   a pragmatic list.


5.1 Evaluation Criteria

   The requirements defined in section 4 define a set of criteria for
   by which protocols may be evaluated for use in the profile delivery
   framework.

   The following table indicates the functional area for which the
   protocols are considered.  This table indicates which requirements
   will be evaluated for each of the protocols.  As no single protocol
   provides all of the functional areas, the objective is to find a
   small set of protocols that will best satisfy the requirements.  All
   protocols are evaluated against the general requirements in section
   4.1.

                      SNMP LDAP ACAP SLP  HTTP SIP  XML  822  DHCP DNS
   Discovery                          X                        X    X

   Enrollment          X         X    X         X

   Profile Retrieval   X    X    X         X

   Change Notification X         X              X

   Profile Upload      X    X    X         X

   Security            X    X    X    X    X    X


Petrie/Mahy            Exp: Dec. 2002 [Page 10]


                                xxxxx

   Data Container      X    X    X                   X    X


   In each of the following subsections to section 5 a general over
   evaluation is made of the protocol.  In addition the requirements
   which are NOT satisfied fully or as well as other protocols are
   explicitly listed or discussed.  Those requirements that are
   satisfied are generally not explicitly called out or listed.

5.2 SNMP

   SNMPv3 [SNMP] is evaluated and referred to as SNMP in this document.
   SNMP has no discovery mechanism.

   General

   There are two aspects of the roaming requirement (GENRREQ-1),
   neither of which are solved very well by SNMP.
       - Physical relocation of a user agent in a different LAN
       - Users moving to a different user agent which subsequently
       requires a new user profile

   It is very difficult to support a user whose preferences are stored
   outside the local management domain.  This physical relocation of a
   user agent (e.g. user agent on a laptop in a visited LAN) is a very
   desirable scenario.  Because of its security model, SNMP does not
   work very well outside of its local domain.

   To support a user (one or more) temporarily using a user agent, the
   user agent would have to support the access of multiple, variable
   user profiles.  MIBs do support the ability to have arrays or
   multiple instances of an object (typically leaf nodes).  However
   MIBs do not support multiple instances of a hierarchy (e.g. multiple
   user profiles each with a hierarchy of content).

   It is difficult to make an active SNMP server.  SNMP is primarily a
   push model.  It is difficult to make an intelligent profile server
   where traps are not designed into the standard profile MIB (GENOREQ-
   10).

   MIBs have a very rigid schema that makes it difficult to add vendor
   specific data without breaking the MIB or having to create a new MIB
   (GENOREQ-11).  Supporting the vendor differentiation through MIBs
   would make management difficult.

   SNMP will not work through a NAT or firewall by default.  It is also
   likely that a firewall administrator will have serious concerns
   letting SNMP traffic through their firewall.

   Enrollment

   ENREQ-5 has the same issues with multiple user profiles as described
   above for general requirement GENRREQ-1.


Petrie/Mahy            Exp: Dec. 2002 [Page 11]


                                xxxxx

   ENREQ-7 has the same issues as GENOREQ-10 and GENOREQ-11 described
   above.

   Profile Retrieval

   As SNMP uses a push model, the user agent must throw a trap or
   inform to tell the server to push a profile to the user agent.  In
   addition the issue with multiple user profiles, described above with
   GENRREQ-1, make it difficult to satisfy PRREQ-1.

   SNMP does not scale very well to individual dynamic nodes.  It is
   difficult to build a system managing more than tens of thousands of
   users.  User agents from some vendors do not have sufficient
   persistent memory to store a whole user or device profile.  After a
   power outage tens or hundreds of thousands of user agents would all
   power up, throw traps requesting profiles.

   The push model of SNMP make it difficult to make changes from the
   user agent (PUREQ-2).  A solution perhaps could be built using a
   trap.  However this would not enable other entities (non-user
   agents) to set profile data.

   Change Notification

   There is no delayed setting of MIB data.  A SNMP agent either
   accepts the change or rejects it immediately (CNREQ-3 and CNREQ-4).

   Data Container
   DAREQ-3 and DAREQ-4 are not well supported due to the rigid nature
   of MIBs described above relative to GENOREQ-11.


5.3 LDAP

   The authors did not have sufficient time to complete a thorough
   evaluation of LDAP.

5.4 ACAP

   General

   ACAP was not designed to be active on the server side.  It has more
   of a database model.  It is probably possible to make the data
   access active or intelligent, however this is make more difficult by
   the lack of implementations (GENOREQ-10).

   ACAP [ACAP] over TLS [ACAP-TLS] is evaluated to satisfy the security
   requirements.  The authors were not able to find a commercially or
   publicly available version of ACAP written in C, C++ or Java
   (GENAREQ-30, GENAREQ-31, GENAREQ-32, GENAREQ-33).

   ACAP does not support any discovery mechanism and was not evaluated
   for this functional area.


Petrie/Mahy            Exp: Dec. 2002 [Page 12]


                                xxxxx

   Enrollment

   Due to the difficulty of making the profile server active for
   Change Notification (as described above in the general requirements
   evaluation of ACAP), it is also difficult to provide different views
   of data based upon characteristics of the user agent (ENREQ-7).  The
   different views would have to be designed into the schema requiring
   coordination on both the user agent and server sides.

   Without an event mechanism (see below) or a means to redirect
   profile data requests to another server it is difficult to re-assign
   a user agent to an alternative ACAP server (ENREQ-9).

   Change Notification

   ACAP does not support an event mechanism.  It uses a polling model.
   This makes it difficult to make profile data changes effective
   immediately.  A very short polling time must be used which does not
   scale well with large numbers of user agents.  Alternatively with a
   longer pooling period, user agents will be slow to make the profile
   changes effective (CNREQ-1, CNREQ-2, CNREQ-3 and CNREQ-4).

   Profile Retrieval

   ACAP meets the requirements for profile retrieval.

   Profile Upload

   ACAP provides a means of updating the profile data with access
   control.

   Security

   Security is provided via TLS.

   Data Container

   ACAP does have a rich hierarchal structure for containing profile
   data.  In addition it has a powerful means of describing access
   control and modification time stamping of data.

5.5 SLP

   SLP [SLP] is primarily a LAN based solution for discovery of
   services.  It allows the discovery of URL or server and port for a
   well named service.  SLP is not appropriate for profile retrieval,
   change notification or profile update.  Nor does it provide a data
   container.

   General

   As SLP is primarily for LAN based discovery where roaming
   functionality is not applicable (GENRREQ-1).  Likewise vendor


Petrie/Mahy            Exp: Dec. 2002 [Page 13]


                                xxxxx

   differentiation in the server and user agent are less applicable
   (GENOREQ-10 and GENOREQ-11).

   It is difficult to make SLP work through NATs or firewalls (GENNREQ-
   20, GENNREQ-21).



   Enrollment

   The ability to provision or create active responses to user agent
   request makes ENREQ-3, ENREQ-4, ENREQ-5 and ENREQ-6 more
   appropriately performed with protocols other than SLP.

   As SLP does not get involved with the profile retrieval, update or
   change notification enrollment requirements: ENREQ-7, ENREQ-8,
   ENREQ-9 and ENREQ-10 are not applicable to SLP.

   Security

   For the above reason security requirements: SECREQ-1, SECREQ-2,
   SECREQ-3 and SECREQ-5 are also not applicable.

   SLP does not authenticate or authorize the user agent.  It assumes
   that is preformed by the server performing the profile retrieval,
   upload and change notification functions (SECREQ-4).

5.6 SIP Events

   The only appropriate use of SIP is for its event mechanism [SIP-
   EVENTS].  SIP is evaluated assuming SIPS and S/MIME [SIP] support
   for the security functionality.  SIP provides a very powerful event
   framework through the SUBSCRIBE and NOTIFY messages.

   SIP is not appropriate for profile retrieval or upload.  It is not a
   data transport protocol.  Nor does SIP provide a data container.
   SIP does support multicast that could be used as a discovery
   mechanism.  However it is not evaluated for discovery features.

   General

   The primary requirement for vendor differentiation is in the
   enrollment, profile retrieval, update and change notification.  SIP
   does allow active server and client side components.  However this
   is not considered necessary for this requirement (GENOREQ-10) and
   considered not applicable.

   As SIP is not consider appropriate for profile retrieval or upload
   it is consider not applicable to GENOREQ-11.

   Enrollment

   The SIP SUBSCRIBE mechanism of [SIP-EVENTS] satisfies all of the
   enrolloment functional requirements.

Petrie/Mahy            Exp: Dec. 2002 [Page 14]


                                xxxxx


   Change Notification

   CNREQ-2 is not applicable to SIP.  It is more related to the profile
   retrieval mechanism used.

   The deferral of making profile changes effective is a user agent
   implementation issue in the context of [SIP-EVENTS].  CNREQ-4 is
   considered to be not applicable to SIP.

   Security

   As SIP is not proposed as a data transport for profile data SECREQ-2
   and SECREQ-3 are not applicable.

   The security capabilities of [SIP] are considered to satisfy the
   other security requirements.

5.7 HTTP

   HTTP [HTTP] is considered for the purpose of transporting the data
   profiles (profile retrieval and upload).  To satisfy the security
   requirements [HTTPS] is assumed.

   General

   As HTTP is used primarily for transport GENOREQ-11 is consider to be
   non-applicable.  However active HTTP pages could be used to help
   support this requirement.

   Enrollment

   Enrollment is considered to be mostly not applicable to the proposed
   use of HTTP.  However ENREQ-7  can be satisfied as part of profile
   retrieval.  This would require active pages on the profile server.

   Profile Retrieval

   HTTP satisfies all of the profile retrieval requirements.

   Change Notification

   Enrollment is considered to be mostly not applicable to the proposed
   use of HTTP.  However CNREQ-2 can be satisfied as profile retrieval.

   Profile Upload

   HTTP provides gross level access control of profile.  However to get
   atomic level access control on elements of the profile data requires
   the development of active pages on the profile server (PUREQ-2).

   Security



Petrie/Mahy            Exp: Dec. 2002 [Page 15]


                                xxxxx

   The security capabilities of [HTTPS] are considered to satisfy the
   security requirements.

5.8 DHCP Options

   [SIP-DHCP]

   General
   Discovery

5.9 DNS

   [DNS]
   [DNSSRV]

   General
   Discovery

5.10 XML

   General
   Data Container


5.11 RFC 822

   General
   Data Container


6 Security Considerations

Security considerations are covered in section 4.7.

7 Conclusion

   The following tables rate the protocols according the the
   requirements.  The rating indcates how well the protocol
   satisfies the requirment.  The notation used is defined as
   follows:

   No : No support of requirement
   L : Low suppport of requirement
   H : High support of requirement
   - : Not applicable to requirement

               SNMP ACAP SLP  HTTP SIP  XML  822  DHCP DNS
   GENRREQ-1    No   H    -    H    H    -    -    -    -
   GENOREQ-10   L    L    -    H    -    -    -    -    -
   GENOREQ-11   L    H    -    -    -    H    M    -    -
   GENNREQ-20   L    H    L    H    H    -    -    -    H
   GENNREQ-21   No   H    L    H    H    -    -    -    H
   GENAREQ-30   H    L    L    H    H    H    H    H    H
   GENAREQ-31   H    L    L    H    H    H    H    H    H

Petrie/Mahy            Exp: Dec. 2002 [Page 16]


                                xxxxx

   GENAREQ-32   H    L    L    H    H    H    H    H    H
   GENAREQ-33   L    L    L    H    H    H    H    H    H

   DISREQ-1               H                        H    H
   DISREQ-2               -                        -    -

   ENREQ-1      H    H    H         H
   ENREQ-2      H    H    H         H
   ENREQ-3      H    H    L         H
   ENREQ-4      H    H    L         H
   ENREQ-5      L    H    L         H
   ENREQ-6      H    H    No        H
   ENREQ-7      L    L    -    H*1  H
   ENREQ-8      H    H    -         H
   ENREQ-9      H    No   -         H
   ENREQ-10     H    H    -         H

   *1 Note: this capability could be provided either as part of
   enrollment or profile retrieval.  Therefore HTTP is evaluated
   here as providing ENREQ-7 as part of profile retrieval.

               SNMP ACAP SLP  HTTP SIP  XML  822  DHCP DNS
   PRREQ-1      L    H         H
   PRREQ-2      L    L         H

   CNREQ-1      H    No             H
   CNREQ-2      H    No        H*2  -
   CNREQ-3      No   No             H
   CNREQ-4      L    No             -

   *2 Note: this capability could be provided either as part of
   change notification or profile retrieval.  Therefore HTTP is
   evaluated here as providing CNREQ-2 as part of profile retrieval.

               SNMP ACAP SLP  HTTP SIP  XML  822  DHCP DNS
   PUREQ-1      H    H         H
   PUREQ-2      L    H         L

   SECREQ-1     H    H    -    H    H
   SECREQ-2     H    H    -    H    -
   SECREQ-3     H    H    -    H    -
   SECREQ-4     H    H    No   H    H
   SECREQ-5     H    -    -    H    H
   SECREQ-6     H    H    H    H    H
   SECREQ-7     H    H    H    H    H

   DAREQ-1      H    H                   H    L
   DAREQ-2      -    -                   -    -
   DAREQ-3      L    H                   H    H
   DAREQ-4      L    H                   H    H
   DAREQ-5      H    H                   H    H




Petrie/Mahy            Exp: Dec. 2002 [Page 17]


                                xxxxx

   The discovery solution is best addressed separately.  Due to the
   varied nature of most network environments, there is no single
   solution that will work everywhere.  It is probably necessary to
   support multiple protocols.  Due to the widespread deployment and
   use of DHCP and DNS they are the best two candidates for discovery,
   although SLP can be used in network that already support it.

   The data container requirements are equally satisfied by XML and
   ACAP largely due to their ability to support an extensible,
   hierarchal schema.  XML seems to have an advantage as well based on
   the wide spread availability of development tools that operate on
   XML.  Both ACAP and HTTP address the profile retrieval and upload
   requirements, although the relative maturity of XML over HTTP is
   very attractive.

   SIP is the only protocol that addressed all the relevant enrollment
   and change control requirements.There was no single protocol that
   satisfied all of the requirements in the other functional areas.
   However a combination of HTTP and SIP satisfies all of the remaining
   requirements to a high degree.  In addition the large number of
   implementations and development tools make this combination the most
   attractive solution.  The development as well as end user (e.g.
   administrator) skill sets are much more readily available for these
   protocols as well.  As a second choice ACAP and SIP seems to be the
   only other reasonable combination.



8 References


   [SIP] M. Handley, E. Schooler, and H. Schulzrinne, "SIP: Session
   Initiation Protocol", RFC2543, Internet Engineering Task Force,
   Nov 1998.

   [SIP] draft-ietf-sip-rfc2543bis-09.txt

   [RFC2026] S Bradner, "The Internet Standards Process -- Revision 3",
   RFC2026 (BCP), IETF, October 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to indicate
   requirement     levels," Request for Comments (Best Current
   Practice) 2119, Internet     Engineering Task Force, Mar. 1997.

   [HTTP]  R. Fielding et al, ôHypertext Transfer Protocol --
   HTTP/1.1ö, Request for Comments (Standards Track) 2616, Internet
   Engineering Task Force, June 1999

   [HTTPS] E. Rescorla, ôHTTP Over TLSö, Request for Comments 2818,
   Internet Engineering Task Force, May 2000

   [TLS] T. Dierks, C. Allen, ôThe TLS Protocol Version 1.0ö, Request
   for Comments 2246, Internet Engineering Task Force, Jan. 1999


Petrie/Mahy            Exp: Dec. 2002 [Page 18]


                                xxxxx

   [EP-CONFIG] draft-stredicke-sipping-ep-config-00.txt

   [SNMP] Request for Comments 2570-2576, Internet Engineering Task
   Force

   [ACAP] Request for Comments 2244, Internet Engineering Task Force

   [ACAP-TLS] Request for Comments 2595, Internet Engineering Task
   Force

   [SLP] Request for Comments 2608, Internet Engineering Task Force


   [SIP-EVENTS] A. Roach, ôEvent Notification in SIPö, <draft-ietf-sip-
   events-05.txt>, IETF; February 2002, Work in progress.

   [DHCP] S. Alexander and R. Droms, "DHCP options and BOOTP vendor
   extensions," Request for Comments (Draft Standard) 2132, Internet
   Engineering Task Force, Mar. 1997.

   [SIP-DHCP] G.Nair, H.Schulzrinne , ôDHCP Option for SIP Serversö,
   <draft-ietf-sip-dhcp-06.txt>, IETF; March 1, 2002, Work in progress.


   [DNSSRV] M. Mealling and R. Daniel, "The naming authority pointer
   (NAPTR) DNS resource record," Request for Comments 2915, Internet
   Engineering Task Force, Sept. 2000.

   [XML] T. Bray, J. Paoli, C. Sperberg-McQueen and E. Maler,
   "Extensible Markup Language (XML) 1.0 (Second Edition)",   W3C
   Recommendation, October 2000,   <http://www.w3.org/TR/2000/REC-xml-
   20001006>

   [RFC822] D. Crocker, ôSTANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
   MESSAGESö, Request for Comments 822, Internet Engineering Task
   Force, Aug. 1982

   [UA-PROF-FRAMEWORK] draft-petrie-sipping-config-framework-00.txt

9 Acknowledgments

   Thanks to Henry Sinnreich and Henning Schulzrinne for their input
   and review of this document.

10 Author's Addresses

   Daniel G. Petrie
   Pingtel Corp.
   400 W. Cummings Park
   Suite 2200
   Woburn, MA 01801
   USA
   Phone: +1 781 938 5306
   Email: dpetrie@pingtel.com

Petrie/Mahy            Exp: Dec. 2002 [Page 19]


                                xxxxx


   Cullen Jennings
   Cisco Systems
   170 West Tasman Drive
   MS: SJC-21/3
   San Jose, CA  95134
   USA
   Phone: +1 408 527-9132
   EMail: fluffy@cisco.com


   Full Copyright Statement

   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.



















Petrie/Mahy            Exp: Dec. 2002 [Page 20]