Subject: RE: [Sipping] Updated draft on alias identities

From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>
Date: Wed, 29 Aug 2007 09:56:45 +0200

Hi folks,
 
It's been almost two months and no discussion at all around this poor
little draft (except Ravishankar's useful comment below, of course).
I kindly ask you to take a look at the draft and start dicsussing those
aspects not clear or not understood. Otherwise we won't be able to
progress with it.
 
I'm answering Ravishankar's comments inline. Thanks a lot, Ravi.
Regards,
/Javier

________________________________

From: [email-masked]
[mailto:[email-masked]] 
Sent: martes, 03 de julio de 2007 7:42
To: Jesus Javier Arauz (MI/EEM); [email-masked]
Subject: RE: [Sipping] Updated draft on alias identities

Javier,

1. Regarding the Security Considerations section:

revealing the relationship between the AoRs may not cause any change in
behavior of the network, but as a user I may not want to any other user
to be able to get a complete list of Grouped Ids for one specific id
that I may have shared. For example, even though I have shared my
[email-masked] if with somebody on a chat-room, I would not like them
to be able to find out the associated [email-masked] id. So there
should be some mechanism by which these ids should be disclosed only to
network elements (P-CSCFs etc), but not to all other users.

[Javier] This mechanism is not intended for end-users, only for the user
that owns the aliases and for trusted network elements. The privacy
policy you describe is probably necessary, but it should apply to the
registration event notification as a whole, and not only to the element
defined in the draft.

2. In the section 1 you say that:

   The P-CSCF acts as a Policy Enforcing Point (PEP) for network access.
   It would make sense that the same policies are applied to alias AoRs
   so it would be interesting for the Policy Decision Point (PDP) to
   know about the Grouped Identities Sets of a user in order to apply
   the same policies to all the identities in the same set.

I am not sure I understand this. Do you mean to say that there is a
separate PDP that tells P-CSCF what policies to be applied for what AoR?

Would it not be the PDP that is interested in the associated Ids, not
the PEP? So that PDP would have to SUBSCRIBE to this information than
the PEP?

Can you please clarify?

[Javier] The PDP does not always have a SIP interface. Though your
suggestion makes sense, what I'm describing is a PDP that leverages the
SIP interface of the PEP, so that the PEP gets the aliases and passes
them to the PDP for policy evaluation.

Regards,

Ravi.

--

Ravishankar. G. Shiroor

Wipro Technologies, Bangalore.

[email-masked]

--

________________________________

From: Jesus Javier Arauz (MI/EEM)
[mailto:[email-masked]] 
Sent: Sunday, July 01, 2007 4:37 AM
To: [email-masked]
Subject: [Sipping] Updated draft on alias identities

Folks, 

I've just submitted an updated version of the draft on notification of
alias groups. Until it shows up on the list you can fetch it from
http://www.indiana-web.com/draft-jarauz-sipping-grouping-reg-event-01.tx
t
<http://www.indiana-web.com/draft-jarauz-sipping-grouping-reg-event-01.t
xt> .

Many Internet-based systems support the concept of aliases. For instance
most HTTP-based discusion forums support one or more aliases to one's
real name. These aliases come handy as part of one's avatar or as a
short alternative to using your real name. However aliases are not
restricted to the Internet. PBX systems have been supporting aliases for
decades, where there is a short (private) number and a long (public)
number for a PBX extension which are alias to each other.

SIP-based networks could benefit from supporting the alias concept as
well. SIP already allows a user to own multiple AoRs simultaneously. The
draft  assumes that the SIP network entities, specifically the user's
registrar, somehow support linking a user's AoRs in alias groups (a.k.a.
Grouped Identities Sets in the draft), and then covers how to notify
other entities that may need to know about those groups. The draft does
not cater for a mechanism that would allow a user to create those
groups. That mechanism could be the subject of another ID.

In this version I've clarified the processing of alias group information
conveyed in extended reg-event notifications. I've also added some cases
to the introduction that further justify the need for network entities
to know about the alias groups. And last but not least, I've reserved a
new XML sub-namespace under 'urn:ietf:params:xml:reginfo' for the alias
group information.

Any comments will be really welcome. 

Regards, 
/Javier 

The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain proprietary, confidential or privileged information. If
you are not the intended recipient, you should not disseminate,
distribute or copy this e-mail. Please notify the sender immediately and
destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient
should check this email and any attachments for the presence of viruses.
The company accepts no liability for any damage caused by any virus
transmitted by this email.

www.wipro.com
	
_______________________________________________
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: [email-masked]
Date: Wed, 29 Aug 2007 15:16:52 -0400

From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>

I ran into this:

   One of the **leif motives** of IMS is to support the provision of
   network-based value-added services to its users.

If the marked words are supposed to be the plural of "leitmotif", that
plural is "leitmotifs".

But more substantially, does this have any use outside of IMS?

Dale

---

From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>
Date: Thu, 30 Aug 2007 14:39:14 +0200

Thanks a lot for the clarification Keith.
As to your question, I'm attaching the text I used when first posted
this draft:

Regards,
/Javier

[email-masked] wrote:
>    It's been almost two months and no discussion at all around this
>    poor little draft (except Ravishankar's useful comment below, of
>    course). I kindly ask you to take a look at the draft and start
>    dicsussing those aspects not clear or not understood. Otherwise we
>    won't be able to progress with it.
> 
> I ran into this:
> 
> If the marked words are supposed to be the plural of "leitmotif",
> that plural is "leitmotifs". 
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 30 Aug 2007 16:15:27 +0200

This draft is giving me some concern.

The problem is that it assumes that for all needs, only one grouping
exists.

To my view, even in the examples given in the document, these do not
correspond to the same group of identities representing the end user.
(Note that the description given in section 1 does not correspond to the
description given in 3GPP TS 23.228 of the service profile concept (see
4.3.3.4 of that document
http://www.3gpp.org/ftp/Specs/html-info/23228.htm), and there is no such
concept of an individual service profile versus shared service profile -
there is only one type).

In IMS stage 3, the concept of alias has two documented use cases:

-	a set of related identities that are included in the
P-Asserted-Identity header by the outbound proxy when one of them exists
by the outgoing serving proxy. This if the P-Asserted-Identity contains
a SIP URI, the outgoing serving proxy would insert a related tel-URI and
vice versa. This means that if an interworking point (e.g. to the PSTN)
is reached that requires a public telecommunications number is reached,
then that number is available, even in the UA included a SIP URI in the
P-Preferred-Identity header in the first place.

-	a set of related identities such that if a GRUU is assigned, the
GRUU is not ressigned to the aliases.

Both these use cases use the term alias in the same context as is used
elsewhere in other IETF documents. For example from:

http://tools.ietf.org/html/draft-rosenberg-rai-phone-names-numbers-00

   Freephone numbers are just another form of name, and the translation
   of the freephone number to an actual number is just another form of
   name to address translation or name to name translation.  Like number
   portability, the concept of many alias numbers for a user, each of
   which has different service implications, is applicable even in pure
   networks.  Indeed, it is perfectly reasonable for a freephone number
   to resolve to a SIP URI that points to a SIP entity.  This would
   allow a SIP UA to call a freephone number which routes entirely over
   the IP network.

And the RFC on the presence data model (RFC 4479)

   Characteristics of a person are the static information about a user
   that does not change under normal circumstances.  Such information
   might include physical characteristics, such as age and height.
   Another example of a person characteristic is an alias.  An alias is
   a URI that identities the same user, but with a different presentity
   URI.  For example, a presentity "sip:[email-masked]" might have a
   presence document with a person component that indicates an alias of
   "sip:[email-masked]" and "sip:[email-masked]".

And usage from
http://www.ietf.org/internet-drafts/draft-ietf-sip-gruu-14.txt:

   When a UA sends a request, the request will be sent 'using' one of
   its AOR.  This AOR will typically show up in the From header field of
   the request, and credentials unique to that AOR will be used to
   authenticate the request.  The GRUU placed into the Contact header
   field of such a request SHOULD be one that is associated with the AOR
   used to send the request.  In cases where the UA uses a tel URI (as
   defiend in [11]) to populate the From header field, the UA typically
   has a SIP AOR that is treated as an alias for the tel URI.  The GRUU
   associated with that SIP AOR SHOULD be used in the Contact header
   field.

Both seems to be a usage in the same context as the documented 3GPP
stage 3 usage.

Now neither of these use cases require the same service profile to work.
They may have the same service profile, but that does not appear to be a
given requirement. If you are identifying a grouping of identities that
have the same set of services, then that could exist over multiple UAs
and is not necessarily the same group of identities.

So what I am saying is that if we have groups of URIs, we need to
clearly define the semantics of that group of URIs, and possibly signal
it as well. Alias URIs are only one of these groupings, and that has no
need to have anything to do with groupings based on same service
profile.

An additional issue is whether any grouping information needs to be
known by other entities other than the outgoing serving proxy, which
obtains the information using a different protocol from the subscriber
database. For the two real use cases identified, only the outgoing
service proxy needs to know this information. The UA does not, and the
application servers have other means of getting this information. If
some other entity does not need it, then we don't need a SIP extension
to convey it.

I would note that some of these issues are being discussed in 3GPP, and
the issue is not becoing any clearer there either.

Regards

Keith

	From: Jesus Javier Arauz (MI/EEM)
[mailto:[email-masked]] 
	Sent: Wednesday, August 29, 2007 8:57 AM
	To: [email-masked]; [email-masked]
	Cc: Gonzalo Camarillo (JO/LMF)
	Subject: RE: [Sipping] Updated draft on alias identities

	Hi folks,
	 
	It's been almost two months and no discussion at all around this
poor little draft (except Ravishankar's useful comment below, of
course).
	I kindly ask you to take a look at the draft and start
dicsussing those aspects not clear or not understood. Otherwise we won't
be able to progress with it.

	Javier,

	revealing the relationship between the AoRs may not cause any
change in behavior of the network, but as a user I may not want to any
other user to be able to get a complete list of Grouped Ids for one
specific id that I may have shared. For example, even though I have
shared my [email-masked] if with somebody on a chat-room, I would not
like them to be able to find out the associated [email-masked] id.
So there should be some mechanism by which these ids should be disclosed
only to network elements (P-CSCFs etc), but not to all other users.

	[Javier] This mechanism is not intended for end-users, only for
the user that owns the aliases and for trusted network elements. The
privacy policy you describe is probably necessary, but it should apply
to the registration event notification as a whole, and not only to the
element defined in the draft.

	   The P-CSCF acts as a Policy Enforcing Point (PEP) for network
access.
	   It would make sense that the same policies are applied to
alias AoRs
	   so it would be interesting for the Policy Decision Point
(PDP) to
	   know about the Grouped Identities Sets of a user in order to
apply
	   the same policies to all the identities in the same set.

	I am not sure I understand this. Do you mean to say that there
is a separate PDP that tells P-CSCF what policies to be applied for what
AoR?

	Would it not be the PDP that is interested in the associated
Ids, not the PEP? So that PDP would have to SUBSCRIBE to this
information than the PEP?

	Can you please clarify?

	[Javier] The PDP does not always have a SIP interface. Though
your suggestion makes sense, what I'm describing is a PDP that leverages
the SIP interface of the PEP, so that the PEP gets the aliases and
passes them to the PDP for policy evaluation.

	Regards,

	Ravi.

	--

	Ravishankar. G. Shiroor

	--

	Folks, 

	I've just submitted an updated version of the draft on
notification of alias groups. Until it shows up on the list you can
fetch it from
http://www.indiana-web.com/draft-jarauz-sipping-grouping-reg-event-01.tx
t
<http://www.indiana-web.com/draft-jarauz-sipping-grouping-reg-event-01.t
xt> .

	Many Internet-based systems support the concept of aliases. For
instance most HTTP-based discusion forums support one or more aliases to
one's real name. These aliases come handy as part of one's avatar or as
a short alternative to using your real name. However aliases are not
restricted to the Internet. PBX systems have been supporting aliases for
decades, where there is a short (private) number and a long (public)
number for a PBX extension which are alias to each other.

	SIP-based networks could benefit from supporting the alias
concept as well. SIP already allows a user to own multiple AoRs
simultaneously. The draft  assumes that the SIP network entities,
specifically the user's registrar, somehow support linking a user's AoRs
in alias groups (a.k.a. Grouped Identities Sets in the draft), and then
covers how to notify other entities that may need to know about those
groups. The draft does not cater for a mechanism that would allow a user
to create those groups. That mechanism could be the subject of another
ID.

	In this version I've clarified the processing of alias group
information conveyed in extended reg-event notifications. I've also
added some cases to the introduction that further justify the need for
network entities to know about the alias groups. And last but not least,
I've reserved a new XML sub-namespace under
'urn:ietf:params:xml:reginfo' for the alias group information.

	Regards, 
	/Javier 

	The information contained in this electronic message and any
attachments to this message are intended for the exclusive use of the
addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately and destroy all copies of this message and any attachments. 
	
	WARNING: Computer viruses can be transmitted via email. The
recipient should check this email and any attachments for the presence
of viruses. The company accepts no liability for any damage caused by
any virus transmitted by this email.
	
	www.wipro.com

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 30 Aug 2007 11:41:08 -0400

While it is true that the concept of aliases has widespread interest and 
applicability, the details of application vary widely. This draft 
supports a very specific notion of alias that is not so widely applicable.

For example, the recent discussions of nicknames in the simple wg are 
another form of alias. I don't believe nicknames would fit within the 
concept of alias presented in this draft.

One of the key restrictions of alias in this draft is that all the 
aliases are tied to a single registrar. In the case of sip AORs this 
means that the domains of all the aliases must be the responsibility of 
the same registrar. That is not something that would work for the 
nickname discussion.

I agree with some of the others regarding the policy implications - the 
party responsible for the AOR should make the policy available to those 
that need it. Trying to infer policy relationships from alias 
relationships seems like a bad idea.

It seems to me that what is being proposed is at best an IMS-specific 
extension, that is unlikely to be of interest to anyone else. And based 
on Keith's comments, it may not be applicable to IMS either.

	Paul

Jesus Javier Arauz (MI/EEM) wrote:
> _http://www.indiana-web.com/draft-jarauz-sipping-grouping-reg-event-01.txt_.
> 
> ------------------------------------------------------------------------
>

---

From: "Jesus Javier Arauz (MI/EEM)" <[email-masked]>
Date: Fri, 31 Aug 2007 11:48:13 +0200

Paul,

Please see answer to Keith's comments and mine inline below.
Regards,
/Javier

Paul Kyzivat wrote:
> While it is true that the concept of aliases has widespread interest
> and applicability, the details of application vary widely. This draft

While I may agree that it may not be widely applicable, it is convenient
when the service provider uses service profiles that it assigns to users
in order to provide the right user experience.

For instance, say Alice has been assigned an IPTV service to one of her
AoRs (sip:[email-masked], which she uses from her set-top-box at
home). This service has some requirements on the access network the PDP
must grant, so Alice's operator provisions the required parameters in
the PDP. Now alice asks her operator to add the IPTV service to other of
her identities (sip:[email-masked], so Alice's daughter can start
her own IPTV sessions from home). Unless the PDP is promptly updated,
Alice's daughter won't receive the same QoS as Alice when watching TV.
But if the PEP knew that alice.foo and alice.bar have the same service
profile, it could apply the right policy straight away without even
querying the PDP.

Another example: Bob has an AoR he only uses when playing World of
Warcraft III on-line (sip:[email-masked]). Bob.the.ork has free
walkie-talkie chatting (PTT). Bob has linked his WoW identity to the WoW
client on his device so when he clicks "call" and uses bob.the.ork the
WoW game starts. Now Bob gets a new identity for WoW from his operator
(sip:[email-masked]). Now Bob needs to manually link this new
identity to the WoW client on his device. However if Bob's device knew
that bob.the.ork and bob.the.elf are aliases, it could start the WoW
client right away.

> means that the domains of all the aliases must be the responsibility
> of the same registrar. That is not something that would work for the
> nickname discussion.    
>
 
I haven't heard of read of those discusions before so I guess they're
restricted to the WG for now. If you could provide me some more input on
this issue I could give a proper answer.

> I agree with some of the others regarding the policy implications -
> the party responsible for the AOR should make the policy available to
> those that need it. Trying to infer policy relationships from alias

It is not when aliases are defined as AoRs with the same service
profile. If aliases are defined using some other criteria then I agree
it seems a bad idea.
 
> extension, that is unlikely to be of interest to anyone else. And
> based on Keith's comments, it may not be applicable to IMS either.  
>

The extension should be of interest for anyone having a well-defined
device and policy&charging architecture with clear roles and
responsibilities for each entity and a service delivery architecture
based on service profiles. I don't know if only IMS falls into that
category, but if so, then so be it.

>> alias groups. Until it shows up on the list you can fetch it from
_http://www.indiana-web.com/draft-jarauz-sipping-grouping-reg-event-01.t
xt_.
>> instance most HTTP-based discusion forums support one or more aliases
>> to one's real name. These aliases come handy as part of one's avatar
>> or as a short alternative to using your real name. However aliases
>> are 
>> not restricted to the Internet. PBX systems have been supporting
>> aliases for decades, where there is a short (private) number and a
>> long (public) number for a PBX extension which are alias to each
>> other. 
>> 
>> well. SIP already allows a user to own multiple AoRs simultaneously.
>> The draft  assumes that the SIP network entities, specifically the
>> user's registrar, somehow support linking a user's AoRs in alias
>> groups (a.k.a. Grouped Identities Sets in the draft), and then
>> covers how to notify 
>> other entities that may need to know about those groups. The draft
>> does not cater for a mechanism that would allow a user to create
>> those 
>> network entities to know about the alias groups. And last but not
>> least, I've reserved a new XML sub-namespace under
----------------------------------------------------------------------
>> 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