Subject: RE: [Sipping] Comments on draft-ietf-sipping-config-framework-09

From: "Sumanth Channabasappa" <[email-masked]>
Date: Tue, 7 Nov 2006 12:57:14 -0700

Some comments inline...

<snip>

- I don't see why it's necessary to have three tiers of configuration
  data (local network, device, and user) which must somehow be merged.
  In the first three cases, ISTM that you really only have one tier
  and in the fourth there is only some very limited set of well-defined
  information, namely the local proxy. It's not like you want a
  hotel proxy to even be able to specify what you should be using
  as your SIP AOR!
[S] The reason why you need this differentiation in profiles is rooted
in the Subscriber Modeling possible in SIP based networks.

Assume the case where the 'Device (or client)' and the 'Users' are
distinct (have their own SIP AORs and their own characteristics).
Further, this client can be behind a Local Network (e.g. Public WiFi).
In this case, there is a need to have distinct profiles, each provided
to a specific AOR by a specific entity.

For e.g.:

   --------
 /          \
|   Service  |    
|  Provider  |          ---> Provides the 'User' and 'Device'           
 \     Y    /                        Profiles
   --------     
       |        ------
       |       / Local \
       |      | Network |
       |      | Provider| -> Can Provide a 'Local Network' 
       |       \       /     Profile (e.g. STUN Server Address)
       |        ------
       |         /
       |        /      
  ==============
 (Local Network )   
  ==============        
       |
       |
       |
   ---------        
  | Client X|       -> Client obtains the 'Device' 
   ---------              Profile from the SP 'Y'
    /     \         (e.g. Users allowed on this client)
   /       \     
 ------   ------
|User A| |User B|   -> 'Users' obtain individual 'Profiles'
 ------   ------       (e.g. Services, Features 
                             for each User)

Further, to answer why we can't combine the 'User' and 'Device'
Profiles, consider the following case:
- A Client X, provided by Service Provider Y who allows for its own
Subscribers (e.g. User A) as well as users from other Service Providers
(e.g. User B obtains services from Service Provider Z).
- An example could be a client that acts as a kiosk

         ----------      ----------
        |  Service  |   |  Service |
        | Provider  |   | Provider |   
        \     Y    /     \    Z   /
         ----------       --------
                |         |
                |         |
                |         |
                |         |
                |         |  
                |         |
                 \       /
                 ---------        
                | Client X|      
                 ---------       
                 /       \     
               ------   ------
              |User A| |User B|   
              ------   ------   

- Multiple mechanisms for profile retrieval. As I understand 8.4, a UA
can get its profile either via SIP or via an external reference in a
NOTIFY. Let's keep life simple.
[S] Well, would it not help to obtain smaller data (bytes) via the
NOTIFY and external references (using say XCAP) to larger profiles (KB,
MB?)from an external source? Or did I misunderstand the point?

- The mechanisms for discovering the URI seem extremely complicated.
  Currently, there are different mechanisms for each of the three
  URI types. If we collapse this down to a single type then is
  there some reason we can't use the SIP DHCP option? 
[S] In the case where the client is in a Local Network not controlled by
the Service Profider, this may not be possible. For e.g. in cases where
the client can reside in a Public WiFi network or home network you will
not be able to control the DHCP options. To allow for multiple
scenarios, it is required to have multiple methods.

My $.02!

Thanks!
- S

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP