[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simple] comments on draft-ietf-simple-view-sharing-00

thanks for the answer, now the scenario is more clear then when I read it in the draft. So the ACL will list that users (users in the originating domain that are authorized to subscribe to that presentity, but who will end up receiving a different view) only in the case where the default behavior is to *block*. However if the default behavior is *allow* it is useless list that user, isn't it? 
maybe it should be better explain clearer the scenario.
Another question you also state "The ACL can also list watchers in the originating domain that are not authorized at all" I guess here you are talking of the watchers that are in someway explicitly listed as not authorized ( which is the difference with the ones that are blocked ?!?!) in the Presence Server, as the ones for whom the authorization is still pending. 

/Sal


Jonathan Rosenberg wrote:
This is a good question. It deals with the case where the default behavior is to block, but there is a whitelist of users that have several different views. A default block rule cannot be provided unless ALL of the non-blocked users are listed, and since they have different views, that information must be conveyed to the RLS so it knows when to extend a new back-end subscription. 

Thanks,
Jonathan R.

Salvatore Loreto wrote:

Hi,

I have finally read this draft, I like it.
I have a comment:

Section 2 states that
"The ACL can also list users in the originating domain that are authorized to subscribe 
to that presentity, but who will end up receiving a different view"
I really do not understand the pro of provide this possibility compared with the scenario 
where the ACL does not say anything about a particular watcher.
From my point of view is just a discloser of information that does not provide any advance, 
but maybe I am wrong.

/Sal


Michael Froman wrote:

Hello,
I have a few comments about draft-ietf-simple-view-sharing-00. I haven't seen any of this on-list (maybe I've missed it) so please excuse me if you've already discussed this. 

--- #1 concern ---
Sec. 4.2 What if (like in RLS using xcap) the information used to construct the ACL is not nearby? There appears to be no mode of responding with "I'm working on it and I'll let you know." The phrase that specifically concerns me is "Furthermore, the initial state sent by the presence agent MUST include an ACL document." This is a current problem in 4662 when used with xcap, and it would be nice to avoid creating a similar problem in this spec. 


--- Other comments and concerns ---
Sec. 2. All the trust levels assume a whitelist auth model, what about blacklists (especially in the Full Trust model)?
Sec. 3.2.1 Trading inter-domain network traffic for higher server load (and I'm guessing much higher) based on all the acl comparisons and presence doc comparisons? There is an entire class of reverse lookups (finding all ACLs that might have referenced 'W' or worse finding all the RLSs that have 'W') that have the potential to be expensive. Just making sure that's called out. 


--- Nits ---
Sec. 3.1.3 'R' is not defined - maybe "This represents the view that the watcher is supposed to receive." --> "This rule ID, R, represents the view that the watcher is supposed to receive."
Sec. 3.1.3 All the bullets should start with the same verb tense ("If R is null" , "If R is not null", "If R was not null"...) 

-Michael.

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple








_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple