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

From: <[email-masked]>
Date: Tue, 3 Jul 2007 11:11:35 +0530

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.

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?

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 

_______________________________________________
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