Re: [Simple] Other proposal from View Sharing and Common Notify to reduce presence traffic

[[e-mail]]

Dear Jonathan and Avshalom,
 
Can you please clarify what you refer by "factors impossible to convey between servers" and policy or composition operations that are "proprietary to some degree"? This seems to be quite vague, at this stage.
 
I tend to imagine that you may be referring to some of those areas of differentiation typically not covered by standards. However, since you indicate that existence of these "proprietary" policies leads to the decision of one design choice instead of another, I think asking for a bit more clarification is appropriate.
 
If this is not clear enough what you refer to -at least knowing a couple of examples or use cases- then it is not clear why the existence of such "proprietary" or even "unknown" mechanisms can justify the design decision.
 
Of course, I understand Presence Servers and RLSes may implement proprietary policies. However, it should be a bit more clear what extra value these policies may add to the Presence Service itself, once the Presentity has defined its Presentity Presence Authorization Rules and the Watcher has indicated its event notification filters.
 
In summary, if the proposed Presence federation solution has been designed to ensure that certain proprietary behaviour works in a certain way, this should be described as a requirement or design constraint, with the minimum degree of detail required to agree that this is the right decision.
 
Is this a fair comment or am I totally missing the point?

Thanks.

 
Cheers,

 

David

 

 

 

 

 

 

> Yes. Even if the two servers will have the same representation of
> the authorization rules, the actual processing of them may be dependant
> on other factors that are impossible to convey between servers.
>
> --Avshalom
>
>
>
>
>
>
> Jonathan Rosenberg <[e-mail]>
> Sent by: [e-mail]
> 03/11/2008 13:54
>
> To
> Paul Kyzivat <[e-mail]>
> cc
> n Martínez <[e-mail]>, [e-mail], Victoria
> Beltrá@core3.amsl.com
> Subject
> Re: [Simple] Other proposal from View Sharing and Common Notify to reduce
> presence traffic
>
>
>
>
>
>
> Sorry for the very late response here..
>
> There is a bigger issue aside from the privacy one Paul raises. The
> bigger problem is that, in practice, the mechanisms performed by a
> presence server for policy processing and composition (both of which can
> be watcher specific) end up being proprietary to some degree (if not
> completely). Consqeuently, it is not possible to even ask another
> presence server to do the work.
>
> This is really the main reason I chose to go the route in view sharing;
> it doesn't require that the two presence servers have the same
> algorithms for view sharing or privacy processing at all.
>
> -Jonathan R.
>
> Paul Kyzivat wrote:
>> I realize that some level of trust is required in each of these cases.
>> But at least with view sharing I only trust the domain with data that I
>> am willing to give to *some* member of that domain.
>>
>> For instance, I may have very private info that I only want to share
>> with users in my own domain. (This is very common with corporate users.)
>
>> Then there may various degrees of visibility that I will make available
>> to users of other domains. View sharing supports that without my having
>> to trust all the other domains with my most sensitive data.
>>
>> With Victoria's proposal, how would you authenticate these other
>> domains? Would you allow *all* other domains access to this information?
>
>>  If you have authentication then probably you will want some filter on
>> the data that you give to that domain, even if it will enforce policy to
>
>> a finer level.
>>
>> I guess you could potentially define some domain-wide views that are the
>
>> union of the view given to any subscriber in that domain, and then let
>> the server in that domain do the added domain-specific filtering and
>> authentication.
>>
>>     Thanks,
>>     Paul
>>
>> Richard Barnes wrote:
>>> Paul,
>>>
>>> The presentity has to grant some trust to the watching domain no
>>> matter what, since all NOTIFYs pass through the RLS in the watching
>>> domain.  In the case of view-sharing, you (the presentity) trust the
>>> watching domain to hand out the right views to the right watchers.
>>> Even in the base case, you're trusting the RLS not to mix
>>> subscriptions up.
>>>
>>> Victoria's proposal could be viewed as another level in the trust
>>> taxonomy in view-sharing, with a corresponding reduction in NOTIFY
>>> traffic.
>>> Case      Policy      NOTIFYs per PUBLISH
>>> No        (nothing)   #WRs
>>> Minimal   WR->view    #views
>>> Partial   WR*->view   #views
>>> Full-VS   WR*->view*  #views
>>> Full-VBM  WR*->rule*  1
>>>
>>> --Richard
>>>
>>>
>>> Paul Kyzivat wrote:
>>>> Do you *really* want to trust other domains to enforce your security
>>>> policies???
>>>>
>>>> I don't. At least not in general. (Maybe there are *some* other
>>>> domains I would trust to do so.)
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> Victoria Beltrán Martínez wrote:
>>>>> Hi,
>>>>>
>>>>> Certainly I considered a mechanism to exchange the policy documents
>>>>> of watched presentities between watching and watched domains in
>>>>> Common Subscribe solution. The watching domain (RLS) subscribes to
>>>>> an event (called ?privacy filters?) in presentity domain?s presence
>>>>> server. Whenever a change in the policy documents for any of the
>>>>> presentity?s watchers happens, a NOTIFY message with ?event=privacy
>>>>> filters? is sent from presentity?s presence server to watchers?
>>>>> domain. The watching RLS maintains one subscription to ?privacy
>>>>> filters? event per watched presentity. This subscription could be
>>>>> explicit if existing watchers were indicated into the body of
>>>>> SUBSCRIBE messages. In this way, when a new watcher is added a
>>>>> re-SUBSCRIBE message containing the updated watcher list is sent and
>>>>> a NOTIFY message with the policy documents will be received by the
>>>>> RLS in response to this resubscription. However, a privacy filters
>>>>> subscription could be implicit so that the watcher list is not
>>>>> needed in SUBSCRIBE messages, a simple SUBSCRIBE creates a
>>>>> subscription to all the existing watchers of the watched presentity.
>>>>> Clearly, a trust relationship between watching RLS and watched PS is
>>>>> needed to share full-state presence and policy documents of watched
>>>>> presentities.
>>>>>
>>>>> When the watching domain subscribes to a presentity, the SUBSCRIBE
>>>>> message contains the list of existing watchers in order to let the
>>>>> watched domain know what watchers are watching the presentity. The
>>>>> OK response from the watched domain includes the list of authorized
>>>>> watchers to see some view of the presentity?s presence. A view of
>>>>> presence is defined by a policy document.
>>>>>
>>>>> Assuming N watched presentities , with Common Subscribe the watching
>>>>> RLS will maintain 2*N subscriptions (N for presence event and N for
>>>>> privacy filters event). In case of View Sharing, the RLS will
>>>>> maintain N*F setting F as the number of different policy documents
>>>>> per presentity. At first sight, we can imagine how the performance
>>>>> of VS gets worse as F increases.
>>>>>
>>>>> In addition, the fact that policy documents change rarely allows us
>>>>> one interesting possibility with Common Subscribe. When a common
>>>>> subscription is created for a presentity in the watched domain?s
>>>>> Presence Server, automatically a ?logical? subscription to the
>>>>> policy documents associated to the presentity is created too. In
>>>>> this way, the watching domain receives two initial NOTIFY messages
>>>>> (or a single multipart NOTIFY), one contains the presentity?s
>>>>> presence and another one contains the policy documents. Once the
>>>>> policy documents are downloaded is more than likely that privacy
>>>>> rules don?t change during the session, so that we save unnecessary
>>>>> signaling traffic to keep alive subscriptions to privacy filters
>>>>> events. Anyway, if a change of privacy rules associated to a
>>>>> presentity happened it would be notified as a NOTIFY message into
>>>>> the common subscription between the presentity and the affected
>>>>> watchers? domain. Now, if there are N presentities, the total number
>>>>> of subscriptions maintained by the watching RLS is N. I have called
>>>>> this mechanism as internal privacy filters subscription.
>>>>>
>>>>> I did several assumptions to estimate the performance of Common
>>>>> Subscribe and View Sharing. I supposed the presence federation
>>>>> scenarios described in section 2.8 of the draft ?Presence
>>>>> Interdomain Scaling Analysis for SIP/SIMPLE?)
>>>>> (ietf-simple-interdomain-scaling-analysis-04). I considered both
>>>>> implicit and internal privacy filters subscriptions when Common
>>>>> Subscribe was applied. With View Sharing, I agree with David that
>>>>> filter-based subscriptions are subject to less frequent change, so I
>>>>> supposed that each change affected half of the privacy filters on
>>>>> average (a notification was generated in half of the existing
>>>>> filter-based subscriptions on average). The number of filter-based
>>>>> subscriptions between watching and watched domains is equal to the
>>>>> number of different policy documents associated to watchers in the
>>>>> watching domain. I considered several numbers of policy documents
>>>>> depending on the number of watchers per presentity. My calculations
>>>>> show that Common Subscribe is more scalable than View Sharing and it
>>>>> achieves around 50% improvement of presence traffic in the majority
>>>>> of cases.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Victoria
>>>>>
>>>>>
>>>>> En/na David Viamonte ha escrit:
>>>>>> Hi,
>>>>>>
>>>>>> I agree with Sanjay that, at first sight, it seems that for this
>>>>>> alternate proposal to work, a sharing of (part?) of the Presence
>>>>>> authorization policies between serving and watching domains is
>>>>>> needed. On the other hand, making a single "domain-to-domain"
>>>>>> subscription as Victoria suggests would be the simplest and
>>>>>> probably most simple mechanism to distribute Presence information
>>>>>> across domains. In such case the watching domain (RLS) would have
>>>>>> responsibility of implementing Presence policies about Presentities
>>>>>> in remote domains.
>>>>>>
>>>>>> In practice, the need for sharing policy documents is implicitly
>>>>>> mentioned in the "Security Considerations" section of
>>>>>> "draft-ietf-sipping-presence-scaling-requirements-01". According to
>>>>>> that section, no decision has been made yet about allowing or
>>>>>> discouraging such approach (delegating privacy protection from one
>>>>>> domain to the other). On the contrary, it seems to be left FFS to
>>>>>> decide whether this is an acceptable security risk or not
>>>>>> ("important part of work on the requirements and optimizations will
>>>>>> be to make sure that all the security aspects are covered").
>>>>>>
>>>>>> Furthermore, my understanding is that, in practice, this
>>>>>> "domain-to-domain single subscription" mechanism does not require
>>>>>> the complete Presence or Policy documents being exchanged, only
>>>>>> those that might be applicable to any user in the watching domain
>>>>>> (of course, including a mechanism to update policies, if needed).
>>>>>> In fact, I think EXACTLY the same comments in the Security
>>>>>> Considerations section of the View Sharing draft ("if it generated
>>>>>> a subscription from each of its subscribers it would be able to
>>>>>> determine who from its domain is allowed to subscribe and what view
>>>>>> they would receive") are applicable to Victoria's proposal, so I
>>>>>> fail to see substantial security differences between both
>>>>>> approaches. I could envisage potential "logistic" issues, though...
>>>>>>
>>>>>> Since I am not a security expert, my conclusion is that getting an
>>>>>> understanding on whether there are fundamental diferences (from the
>>>>>> security perspective) between both approaches would be very
>>>>>> valuable. In case there are not such differences, the proposed
>>>>>> alternative looks interesting, as it seems to represent a very
>>>>>> important simplification (in practice, there would be no need to
>>>>>> define any SIP extension at all). It is fair to say that a
>>>>>> mechanism to exchange policies would need to be defined (not sure
>>>>>> is that is covered elsewhere?).
>>>>>>
>>>>>> When it comes to traffic reduction, my understanding is that the
>>>>>> "common subscription" mechanism "should" be more efficient than the
>>>>>> view sharing approach. Even though it leads to larger documents
>>>>>> being exchanged (thus containing more Presence information, which
>>>>>> is subject to more frequent change), such documents are delivered
>>>>>> only once per domain, while in the view sharing case documents are
>>>>>> delivered to each list of watchers sharing a same "policy profile".
>>>>>> This is only a preliminary comment without having made serious
>>>>>> calculations :-)
>>>>>>
>>>>>> Just my 2 cents,
>>>>>>
>>>>>> David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sanjay Sinha (sanjsinh) escribió:
>>>>>>> What about allowed/blocked list that a presentity may have, if
>>>>>>> there is a single subscription between watcher domain's presence
>>>>>>> server and the watcher presentity.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [e-mail] [mailto:[e-mail]] On
>>>>>>>> Behalf Of Victoria Beltrán Martínez
>>>>>>>> Sent: Wednesday, October 15, 2008 1:11 PM
>>>>>>>> To: [e-mail]
>>>>>>>> Subject: [Simple] Other proposal from View Sharing and Common
>>>>>>>> Notify to reduce presence traffic
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> The Common Notify technique (described in the expired draft
>>>>>>>> "Scaling Optimizations for Presence in SIP/SIMPLE,
>>>>>>>> houri-simple-interdomain-scaling-optimizations-00) is intended
>>>>>>>> for reducing presence traffic between federated domains. Other
>>>>>>>> draft, "Optimizing Federated Presence with View Sharing"
>>>>>>>> (ietf-simple-view-sharing-01) has the same intention. From these
>>>>>>>> proposals,  I was thinking the idea of a single subscription
>>>>>>>> between watcher and watched domains, so that the presence server
>>>>>>>> in the watcher domain is in charge of subscribing to the watched
>>>>>>>> presentity.  Then, the presence server mantains the list of
>>>>>>>> watchers that are watching each presentity and this list hasn't
>>>>>>>> to be sent in NOTIFY messages. In this way, we avoid the increase
>>>>>>>> of signaling traffic as the number of watchers grows in the case
>>>>>>>> of Common Notify and as the number of privacy filters grows in
>>>>>>>> the case of View Sharing.
>>>>>>>>
>>>>>>>> Have anyone considered this solution? I have read nothing about
> it.
>>>>>>>>
>>>>>>>> I named this solution as Common Subscribe and compared it with
>>>>>>>> Common Notify and View Sharing. I did several assumptions based
>>>>>>>> on IETF drafts and I proved that Common Subscribe reduces around
>>>>>>>> 50% of presence traffic generated by View Sharing and Common
> Notify.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>> Victoria
>>>>>>>> _______________________________________________
>>>>>>>> Simple mailing list
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Simple mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
>>>>>>>
>>>>>>>
> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No virus found in this incoming message.
>>>>>>> Checked by AVG - http://www.avg.com/" rel="nofollow">http://www.avg.com Version: 8.0.173 / Virus
>>>>>>> Database: 270.8.1/1728 - Release Date: 16/10/2008 7:38
>>>>>>>
>>>>>>>
>>>>>>
> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> No virus found in this outgoing message.
>>>>>> Checked by AVG - http://www.avg.com/" rel="nofollow">http://www.avg.com Version: 8.0.173 / Virus
>>>>>> Database: 270.8.1/1728 - Release Date: 16/10/2008 7:38
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Simple mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
>>>>>
>>>> _______________________________________________
>>>> Simple mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
>>>>
>>>
>> _______________________________________________
>> Simple mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
>>
>
> --
> Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
> Cisco Fellow                                   Iselin, NJ 08830
> Cisco, Voice Technology Group
> [e-mail]
> http://www.jdrosen.net/" rel="nofollow">http://www.jdrosen.net                         PHONE: [phone]
> http://www.cisco.com/" rel="nofollow">http://www.cisco.com
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
>
> _______________________________________________
> Simple mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/simple" rel="nofollow">https://www.ietf.org/mailman/listinfo/simple
>

_______________________________________________
Simple mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/simple