Subject: [Simple] Review comments: draft-houri-sipping-presence-scaling-requirements-01.txt, draft-houri-simple-interdomain-scaling-optimizations-00.txt

From: "Willekens, Marc (NSN - BE/Belgium - MiniMD)" <[email-masked]>
Date: Sun, 25 Nov 2007 11:19:20 +0100

Hi Avshalom,

http://www.ietf.org/internet-drafts/draft-houri-sipping-presence-scaling-requirements-01.txt <http://www.ietf.org/internet-drafts/draft-houri-sipping-presence-scaling-requirements-01.txt> 

Typos in §4: with this problem?, are considered? can be deleted.

http://www.ietf.org/internet-drafts/draft-houri-simple-interdomain-scaling-optimizations-00.txt <http://www.ietf.org/internet-drafts/draft-houri-simple-interdomain-scaling-optimizations-00.txt> 

2.1 ... a single NOTIFY per presentity in domain B  -> should this not be domain A?

2.1.1 "Complete presence state information needs to be sent from the presentity's domain to watcher's domain".

Is it not better to filter this complete presence state information first by PS in domain A based on a domain level privacy filter. Further specific watcher dependent filtering is done in the PS of domain B.

As long as the amount of different domains is limited, the trust and privacy filtering can be handled and controlled in one or another way. However, when the PS has to interwork with many different domains, how can the trust and privacy be kept under control of the presentity? In the end, the presence state and the privacy filtering is available on many, many different systems which can dynamically change very often so that it's completely out of control. How can a presence rule be updated in all these different domains? How long will it take and what is the guarantee for it? Is the presentity still aware which watchers will receive which presence state? Suppose the presentity wants to apply a new filter to different watchers in different domains. How can it be guaranteed that this is done in a synchronized way in all these different domains to avoid a mismatch of the presence state?

2.1.2 NOTIFY failure aggregation

Is the subscription state of each watcher known by the presence server of the presentity or is the subscription state only kept in the PS of the watcher? 

What will be done by the PS in domain A when the Notify failure indicates that a certain watcher in domain B has not successfully received a NOTIFY message? Will a new NOTIFY message be sent by the PS of domain B or will it be sent by PS of domain A directly to the watcher or always to its PS?

2.1.3 Transferring the watcher list

When the watcher list is part of the NOFITY message, could it then not make sense to do the privacy filtering in domain A and determine which watchers belong to which filtered documents and pass the different watcher lists and their related presence document in function of the privacy filtering all together in one message or in different messages in function of the filtered presence document.

2.2 Batched notification

...."The presence server in domain B can then deliver the message to the watcher or create individual NOTIFY messages for different watchers...." -> Should this not be presentities (different NOTIFY messages to the watcher in function of the presentity)?

2.3 Timed presence

There are indeed many different end-user requirements. Mostly, all people want to be informed directly, until they have to pay in addition for that. In practice however, there is something as "directly", "as soon as possible", "as late as possible", "not after a certain moment in time", etc. Both the Presence server of the presentity and the presence server of the watcher can make use of these practices to optimize their traffic to serve the user as close as possible with their wishes. When the capacity of the servers and the networks is there, why not use this capacity to serve the end-user even better?

2.4 On-Demand

This depends how often the "poll" will be made. Misbehaving watchers can seriously affect the performance of the PS.

Instead of a SUBSCRIBE/NOTIFY, a RSS-feed mechanism as described in draft-roy-simple-presencerss-01.txt could also be used as an on-demand model.

3. Conclusions

Same comment as in other drafts: ".... if we do not think about scalability with the protocol design it will not be very hard to scale."  -> not!

4. Security considerations

Yes, this is a main concern. In principle, everybody is able to provide a presence server and provide this as a "free service" to many users. How can my presence server know which other worldwide available presence servers can be trusted?

br,

Marc.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple