Subject: [Sipping] Config framework

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 23 Feb 2004 15:22:53 +0200

Hello,

The following draft defines a framework for session policies in SIP
http://www.ietf.org/internet-drafts/draft-hilt-sipping-session-indep-policy-00.txt

It defines an event package and a data format to carry session policy 
information. Now, the following draft defines a framework for sending 
configuration information and user profiles to SIP user agents.

http://www.ietf.org/internet-drafts/draft-ietf-sipping-config-framework-02.txt

We need to decide whether session policies should use the package 
defined by the configuration framework or, on the other hand, continue 
defining its own package. The XML based data format would remain the 
same on both cases.

I would like to know what type of information folks intend to store as 
user profile. Would it make sense to consider session policies as a 
subset of the user profile, or it would be better to define a new 
profile-name value: "session-policy" (in addition to the already defined 
"user" and "device").

I tend to think that it would be better to re-use the same package for 
session policies as for configuration, defining the new "session-policy" 
value for the profile-name Event header field parameter, but I would 
like to hear other opinions.

Comments?

A further question of the config draft. Is the intention to establish 
two subscriptions, one for device configuration and another for user 
profiles, or the idea is to use a single subscription and multiplex 
somehow both data types into it.

Thanks,

Gonzalo

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
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

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Feb 2004 08:35:57 -0500

My general concern is that the current config framework is far too 
device-centric, presumably based on the origin and interests of the 
authors. Generally, configuration seems to consist of at least three 
sources that can all contain pretty much the same data, ranging from 
protocol parameters to media policies to user configuration information 
such as speed dial buttons and address lists (or IM equivalents).

The three sources are:
(1) The local network that I happen to be in, represented by the 
outbound proxy or other information conveyed by DHCP, identified by my AOR;

(2) My home provider/network, where I am identified by my AOR;

(3) My device, identified by some permanent device identifier, typically 
a MAC-address like thing, but some of the other identifiers discussed 
here recently may also be possible.

So far, only a subset of (3) seems to have been discussed.

I had raised this issue earlier, but have gotten no response. It seems 
fundamental to the whole architecture discussion. The same problem that 
Gonzalo raises (one or more events) also applies to the question as to 
how this relates to watcher lists and other IM configuration information.

Gonzalo Camarillo wrote:

> This communication is confidential and intended solely for the 
> addressee(s). Any unauthorized review, use, disclosure or distribution 
> is prohibited. If you believe this message has been sent to you in 
> error, please notify the sender by replying to this transmission and 
> delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data corruption, 
> interruption, unauthorized amendment, tampering and viruses, and we only 
> send and receive e-mails on the basis that we are not liable for any 
> such corruption, interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
>

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 23 Feb 2004 10:12:34 -0500

I have not gotten through all of draft-hilt-sipping-session-indep-policy-00
yet, but I certainly consider policies such as access and authorization to
be part of  user and device profile data.  Whether directly or by reference
the policy data applies to the user or the device.  I would hope that this
could all be decovered and delivered using the same mechanizm.

Ideally, it would be nice if all user profile data (including policies) or
all device data could optionally be delivered via one URL.  Using XML
name spaces the subscriber can specify what it wants and parse out the
parts of interest.
Cheers,
Dan

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Mon, 23 Feb 2004 11:06:40 -0500

Comments below:

> device-centric, presumably based on the origin and interests of the

This is certainly not the intension.  The draft specifies a way to separately
subscribe for device or user profile data.  I would be happy to clarify this
where you think the draft is vague or implies this restriction.

Section 3.2 describes parameters that are device specific as even in the
ideal world, purely user specific data may need to consider the UA
implementation that it is to be applied to.  Section 3.2 also specifies a
means to indicate the desire for user or device data.

Section 3.13 specifies how to form the SUBSCRIBE URI based upon
the interest for either a device or user profile.

> here recently may also be possible.

These 3 important concepts are intended to be supported in
draft-ietf-sipping-config-framework-02.  It is however difficult in
practice to keep these three things separate.  In many environments
it is easier to keep two of the three separate.

For example:
In an enterprise with physical devices that do not move much, it becomes
easier to combine the properties of 1 related to location with the properties
of 3.

When a user does not know their AOR or does not want to have to provide
it to the UA (to provide a plug and play experience), the user's AOR can be
associated with 3 (the device).  2 is may then be subscribe implicitly or explicitly.

In the automated discover phase for a new UA, the distinction between
1 and 2 become blurred as the device can only discover or derive
AORs based upon the local domain (without user input).

I think that this illustrates a very good point that the separation between
user and device profile data cannot be made concrete.  Data such as
out bound proxy, or policy may be dictated by any or all of the 3
realms defined above.  Only the application and local administrative
policies can determine the realm to which data should be associated.
In addition it may be desirable to override some of the user or device
profile data based upon other local discovery data (e.g. DHCP options
for out bound proxy, STUN for NAT traversal).

At best we can define a precedence by which the device data
can be overridden by user data (or the other way around)
along with the ability for administrators to dictate policy (perhaps indicated
in the profile data) over what can be overridden.

---

From: Volker Hilt <[email-masked]>
Date: Mon, 23 Feb 2004 12:07:43 -0500

Policies and configuration information seem to share a number of 
commonalities. Thus, I think it would make sense to use the same 
framework for both. The framework should probably be able to transfer 
any kind of information from a network entity to a user agent.

More comments inline.

> where you think the draft is vague or implies this restriction.
Is it safe to assume that policy information is always part of the 
device or user configuration or can it be an independent piece of 
information a UA wants to subscribe to? Thus, would it make sense to 
define a profile-name "session-policies"? This could be useful if a 
device is configured by other means and simply wants to keep track of 
the policies in a network.

> AORs based upon the local domain (without user input).
A difference between configuration data and other information (such as 
policies) seems to be that subscriptions to configuration data must work 
on an "out-of-the-box" device that has not been configured yet. Once the 
configuration is done, its probably easier to subscribe to the different 
sources of information.

Is there information that applies to a device besides the device 
configuration? If not, would it make sense to differentiate into the 
device configuration (requiring a discovery process) and subscriptions 
to the local network using my AOR as well as subscriptions to my home 
network (also using my AOR)?

Thanks,

Volker

-- 
Volker Hilt                      Bell Labs / Lucent Technologies
phone: +1 732 332 6432           101 Crawfords Corner Rd
email: [email-masked]     Holmdel, NJ 07733

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 23 Feb 2004 18:11:27 -0500

> the interest for either a device or user profile.

3.13 and 4.1 don't really spell out that user (as opposed to device) 
data may need to go elsewhere. It only has a single set of steps that 
aborts as soon as (say) DHCP-based discovery succeeds.

I think the two modes, user and device, are somewhat dissimilar. For 
device, I may need to combine local information (e.g., information about 
outbound proxies and local dialplans) with home information (local 
dialplan, device-specific UI configuration, etc.).

For user configuration, I probably need to assume that the device has an 
AOR, either initially or discovered via device configuration, which is 
realistic for laptops and other personal devices.

4.1 does not seem to spell out what to do if either the device or the 
user knows the AOR, but wants to get the remainder of the device and 
user configuration automatically.

Thus, I'd suggest separating the two discovery models and possibly 
logically separating user configuration as being derived (among other 
sources of AORs) from the device configuration, as in:

DHCP -> device configuration query -> AOR -> user-based query

> easier to combine the properties of 1 related to location with the properties

I'd rather be more general; if the user configuration spans multiple 
devices, it's a lot cleaner if I only have to update one server rather 
than each device-based server. (Device-based servers may well be more 
local than user-based servers.)

> associated with 3 (the device).  2 is may then be subscribe implicitly or explicitly.

In my two-stage model, this is supported.

> for out bound proxy, STUN for NAT traversal).

There may well be information that could be considered both, but in my 
book, user-based configuration is independent of where I plug in my 
device and does not depend on the device itself. Thus, an outbound proxy 
and related transport parameters are clearly device-related, while speed 
dial functionality, media preferences, home dial plans and buddy lists 
are probably not.

Some parameters may be hierarchical, in that local network configuration 
overrides my general configuration. If my visited network doesn't allow 
video, that takes precedence over my user configuration that prefers 
video calls.

> in the profile data) over what can be overridden.

I agree. I think we'll have both directions of override. For example, a 
CIA agent user configuration may mandate use of TLS and AES encryption 
and accept that a call will fail in some local environments that don't 
allow this.

Having a sample set of configuration parameters that we can work through 
might test our assumptions.  draft-stredicke-sipping-ep-config-00.txt 
seems to be the last one on this topic, or is there something else?

It unfortunately conflates local parameters (e.g., outbound proxy, 
3.1.4.3) with user-based parameters (registration period, 3.1.4.1).

Henning

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 24 Feb 2004 23:36:45 -0500

> the policies in a network.

I can think of applications where policy information is useful by itself (e.g. in a
profile server UI which facilitates profile data input) as well as applications were
the profile data is needed in conjuntion with the policy data.  I would suggest
using something like XML name spaces so that everyting may be contained
in the same or separate XML documents.

> device configuration (requiring a discovery process) and subscriptions

It is an interesting thought that discover may only be needed for device
profiles.

> network (also using my AOR)?

I am not sure I follow how things get routed differently to the local or
home network.  Are there two different AORs?

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Wed, 25 Feb 2004 00:08:09 -0500

I split this into two responses.  This is good input.  I think making
two distict discover approaches makes sense.  I will try to incorporate
this into the next draft.

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Wed, 25 Feb 2004 00:37:17 -0500

snipped

> local than user-based servers.)

I am not sure I follow this.  Perhaps if I elaborate, you can help me realize
my confusion.  The three types of profile data are: local network, user and
device data.  In the above example I was suggesting that in many environments
the UA is not mobile or at least not frequently moved.  Hense the UA can
be associated with a specific location.  In these environments it is convenient
to combine the local network data and the device specific data.  I was not
suggesting that the user data should be denormalized.  A user may have
many devices.  The devices can all use the same user profile data.

I am also questioning whether people think we really need three distinct
types of profiles (local network, user and device).  Is there a real life
environment where we need all three or can it be accomlished with
two by combining parts of the third with the other two.  If people think
we need all three then we need to have three different discovery models
and ways to form three different AORs (for each profile type).  This is not
difficult, I just want to be sure the extra moving parts are necessary.

> seems to be the last one on this topic, or is there something else?

There is nothing newer than this expired draft.  I was hoping to shake
the dust off and restructure this document once the framework was
last called.  I think the document identifies some good profile data
requirements, but I think they should be sliced up a little differently.

---

From: Volker Hilt <[email-masked]>
Date: Wed, 25 Feb 2004 01:05:59 -0500

> in the same or separate XML documents.
Yes, this would allow the UA to get the relevant information. I'm not 
sure if it would enable a UA to subscribe to a certain type of 
information (e.g. policies). Thus, the notifier might have to return all 
URIs it has available for the subscriber in the NOTIFY. Unless the UA 
can determine the exact content of a document (e.g. based on MIME type 
or URI structure) it would have to download all documents to find the 
relevant pieces of information. I'm not sure though if this poses a real 
problem.

> home network.  Are there two different AORs?
One possibility could be that the UA subscribes separately to the AOR 
and to a discovered local profile server (both times using the same AOR 
in the From header).

Volker

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 Feb 2004 09:29:11 -0500

> many devices.  The devices can all use the same user profile data.

I think we're in agreement. My suggestion is to simply logically 
separate the local network, user and device data and link those by 
pointers (URIs), rather than by inclusion. Thus, even if a stationary 
device is always associated a single user, it would reference rather 
than include the user information.

> difficult, I just want to be sure the extra moving parts are necessary.

While many devices will have one device = one user = one location, even 
within these enterprises there may well be classes of SIP endpoints that 
don't. Variations of hoteling, both the Hilton kind and the 
intra-company desk loaning, come to mind.

If I carry a device (laptop, PDA) with me from one branch to another, 
there will be device-based information that only depends on the device 
characteristics (media capabilities, user interface, network speed, 
etc.), some that depend on where I plug in the device (emergency call 
numbers, local dial plan, outbound proxy configuration, local media 
policy) and some that are the same for all my devices and only depend on 
my user identity (general media preferences, speed dial, buddy lists).

Note, for example, that media policy appears in all three configurations.

Since network, user and device are clearly distinguishable in practice, 
I'd argue that proponents of unifying two of them need to prove that 
they should *never* be treated separately, rather than the opposite.

> requirements, but I think they should be sliced up a little differently.

The discussion here illustrates that it would be useful to have at least 
a rough set of parameters that we can use as test cases to see if they 
are accommodated well within the framework.

Henning

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 24 Feb 2004 15:14:45 -0800

On Feb 23, 2004, at 3:11 PM, Henning Schulzrinne wrote:
> device, I may need to combine local information (e.g., information 
> about outbound proxies and local dialplans) with home information 
> (local dialplan, device-specific UI configuration, etc.).

Henning,

You are presenting an extremely rigid and limited view of what 
constitutes local vs. home information.  There is certainly a need for 
*specific implementations* to sort various parameters into what they 
will allow to be configured in each instance, but you will certainly 
not gain consensus on this list that the things listed above are one of 
the other.

Case in point, there are valid reasons why outbound proxy should be set 
via discovery, device, and user.  Likewise, in a thread on emergency 
services, we discussed why local dialplan (sos numbers) can be based on 
where you are OR who you are, but not both simultaneously.

> For user configuration, I probably need to assume that the device has 
> an AOR, either initially or discovered via device configuration, which 
> is realistic for laptops and other personal devices.

no, you don't need to assume that at all.  If you have an AOR, feel 
free to use it.  If you don't, but you can discover one, you should 
also feel free to do so.

> In my two-stage model, this is supported.

I don't think you have really articulated what constitutes your 2-stage 
model.  Can you elaborate please?

> device and does not depend on the device itself. Thus, an outbound 
> proxy and related transport parameters are clearly device-related, 
> while speed dial functionality, media preferences, home dial plans and 
> buddy lists are probably not.

I can present a counter-example for each of your examples.  For 
example, I can have an outbound proxy that records my call history 
independent of my device.  Speed dial functionality is not completely 
device independent as I may render speed dials for example using soft 
buttons on some devices, and as sequences of digits on another.  
Finally media preferences depend intimately on the capabilities of my 
device.

> Some parameters may be hierarchical, in that local network 
> configuration overrides my general configuration. If my visited 
> network doesn't allow video, that takes precedence over my user 
> configuration that prefers video calls.
>
>
> I agree. I think we'll have both directions of override. For example, 
> a CIA agent user configuration may mandate use of TLS and AES 
> encryption and accept that a call will fail in some local environments 
> that don't allow this.
>
> Having a sample set of configuration parameters that we can work 
> through might test our assumptions.  
> draft-stredicke-sipping-ep-config-00.txt seems to be the last one on 
> this topic, or is there something else?
>

again, your case for local vs. user parameters is very thin.  you may 
want to reconsider if your taxonomy if real or just an artifact of the 
fact that these things were divided in the past.

thanks,
-rohan