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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 23:10:24 -0400

I am sorry it took so long to respond here. Thanks for your comments. 
Responses below:

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.

I don't understand the problem. The presence server would just wait to 
send the NOTIFY until it had the state.

> 
> 
> --- Other comments and concerns ---
> Sec. 2.  All the trust levels assume a whitelist auth model, what  
> about blacklists (especially in the Full Trust model)?

Blacklists can work too; there is a blocked=true flag in a rule. So if 
you want to blacklist, you'd have something like this:

<rule id="1" blocked="true">
   <member>sip:[email-masked]</member>
   <member>sip:[email-masked]</member>
</rule>
<rule id="2">
   <other/>
</rule>

> 
> 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.

OK, I'll mention. But this is exactly the tradeoff - CPU for messaging 
traffic. I don't think the increase in CPU load is that high however.

> 
> 
> --- 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."

fixed.

> 
> 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"...)

fixed.

Thanks!

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Simple mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jul 2008 23:12:53 -0400

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,
>>
>> 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.
>>
>>
>> -Michael.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 8 Jul 2008 23:56:18 -0500

On Jul 8, 2008, at 10:10 PM, Jonathan Rosenberg wrote:

> I am sorry it took so long to respond here. Thanks for your  
> comments. Responses below:
>
> Michael Froman wrote:
>> Hello,
>> 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.
>
>
> I don't understand the problem. The presence server would just wait  
> to send the NOTIFY until it had the state.
>

3265 immediate notifies.

What do you send when its really time to kick that immediate NOTIFY  
out and the information you need for that ACL isn't there yet?

Would it be OK just to send an empty NOTIFY and then push this stuff  
out, as you say, when the presence server gets the state?

RjS

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 10 Jul 2008 09:40:05 +0300

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:
> 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 really do not understand the pro of provide this possibility 
>> compared with the scenario
>>  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,
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jul 2008 14:25:21 -0400

inline:

Robert Sparks wrote:
> What do you send when its really time to kick that immediate NOTIFY out 
> and the information you need for that ACL isn't there yet?

Is this a real problem? "Immediate" NOTIFY doesn't have a requirement 
around a specific time; it seems reasonable to wait for whatever backend 
DB operations are required before you send a NOTIFY. You need to do that 
anyway to figure out what presence document to send them.

> out, as you say, when the presence server gets the state?

I do think its OK; but I still don't understand the problem.

-Jonathan R.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 10 Jul 2008 13:30:16 -0500

On Jul 10, 2008, at 1:25 PM, Jonathan Rosenberg wrote:

>>>> 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.
>>>
>>>
>>> I don't understand the problem. The presence server would just  
>>> wait to send the NOTIFY until it had the state.
>>>
>> 3265 immediate notifies.
> Is this a real problem? "Immediate" NOTIFY doesn't have a  
> requirement around a specific time; it seems reasonable to wait for  
> whatever backend DB operations are required before you send a  
> NOTIFY. You need to do that anyway to figure out what presence  
> document to send them.

It really does have to be immediate - in the same sense that responses  
to Non-INVITE requests have to be immediate.
There's a race.

The subscriber will stop listening for NOTIFYs from other forks than  
the one that corresponds with the 200 OK very shortly after that 200  
OK arrives.

>> Would it be OK just to send an empty NOTIFY and then push this  
>> stuff out, as you say, when the presence server gets the state?
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2008 09:33:48 -0400

> maybe it should be better explain clearer the scenario.

Yes, you are correct. I will mention this. I suspect the more common 
case is a default of 'block' of course.

> ones that are blocked ?!?!)

blocked == not-authorized

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2008 09:39:14 -0400

a correction here:

Jonathan Rosenberg wrote:
>> However if the default behavior is *allow* it is useless list that 
>> user, isn't it?

Actually this is wrong. The ACL is really specifying views for watchers. 
When there is a default, it means, "this is the default view". So, if 
there are users that are allowed but are not going to get the default 
view, they need to be enumerated as well. So, the rule is correct as 
stated in the document: if a default view is included, you HAVE to 
include an enumeration of all other views that users might receive. This 
is true regardless of whether the default view is blocked or not.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 14 Jul 2008 10:09:03 -0400

Robert Sparks wrote:
>> around a specific time; it seems reasonable to wait for whatever 
>> backend DB operations are required before you send a NOTIFY. You need 
>> to do that anyway to figure out what presence document to send them.
> 
> The subscriber will stop listening for NOTIFYs from other forks than the 
> one that corresponds with the 200 OK very shortly after that 200 OK 
> arrives.

Well, in the case of presence at least there isn't going to be forking; 
RFC3856 forbids multiple dialogs from being created from forked 
branches. Particularly in the case of federation I wouldn't expect to 
see this happen even if it were allowed.

Thinking about other event packages though, I actually couldn't find a 
value for this timer in RFC 3265. Is one defined?

-Jonathan R.