Re: [Sip] Review of draft-ietf-sip-subnot-etags-01

[Aki Niemi <[e-mail]>]

On ma, 2007-10-08 at 17:02 +0200, ext Avshalom Houri wrote:
> 
> Several comments: 
> 
> ------------- 
> A possible security issue with the following scenario: 
> a) Subscriber subscribes with Suppress-Body-If-Match header with 
> etag of e1. 
> b) The document has changed but what was changed is suppressed from 
> that subscriber due to privacy. 
> c) The subscriber will get notify with new tag but with the same 
> document. 
> 
> If the subscriber wants to it can compare to the previous value and 
> understand that something is being suppressed from it. 

I think this is an implementation issue. But really, the notifier
shouldn't be generating a new entity-tag, if the entity hasn't changed. 

I think the model already talks about this. A resource can have several
*different* representations, each of which also has its own private pool
of entity-tags. 

> ------------- 
> Section 5.2 - second paragraph 
> "the first notification after the SUBSCRIBE" sounds as the first new 
> notification due to state change after the SUBSCRIBE. Maybe it is
> better 
> to write "the immediate notification following the SUBSCRIBE". 
> Note that there are other occurrences of the usage of "first" if you 
> decide to change. 

This is fixed in -02. Now, the condition applies to all subsequent
notifications.

> ------------- 
> Section 5.2 - Last paragraph before the examples 
> typo - "simply copies"  should be  "simply copied" 

No I really meant copies. I guess this could be said differently, but I
like my way better. ;) 

> ------------- 
> Section 5.2 - last example 
> 
> Maybe there should be some explanation of why * is needed earlier 
> in the document. Liveliness use case is described below but maybe 
> better to explain earlier in the doc 

The wildcard is better motivated now, I think.

> ------------- 
> Figure 4 
>           ... poll interval elapses 
> 
> Should probably be  "... poll interval elapses immediately" 
> Since it is zero initially. 

No, it's not zero; the expires is zero because it's a "fetch". The poll
interval is the time between successive fetches. That can be anything
the subscriber wants.

> Section 5.6 
> Should not this be the first use case described? From bandwidth pov 
> it is the most important. 

Well, these are not in priority order. 

> ------------- 
> Section 6.1 
> 
> " 
> ...The notifier MUST remember the entity-tag of an entity as long 
>    as the version of the entity is current.  The notifier MAY
> remember 
>    the entity-tag longer than this, e.g., for implementing journaled 
>    state differentials (Section 6.4). 
> " 
> 
> I understood from the text that the etag can be deleted by the
> notifier 
> when there is no current value to the entity. Consider the case when 
> a subscriber subscribed and got entity e1. Meanwhile the resource has
> become 
> stale (all previous publishes expired).

This would cause the entity to change, no?

> After e.g. two days the subscriber tries to subscribe with e1 for 
> the suppressing condition. What will the notifier selecting e1 as the 
> current entity tag again? If it does so the subscriber will not get 
> a notify (or body of notify) while it should have gotten one. 
> I hope that this is only my misunderstanding. 

It should get a new NOTIFY that reports the latest state.

> ------------- 
> Comment from Ofira Tal (IBM) 
> 
> Should we consider the change of the entity tag as a reason to 
> send a notify with the entity tag only even though there is no 
> need to send an actual notify to the subscriber since the change 
> affects filtered information due to privacy or just filtering. 
> This will enable avoiding redundant NOTIFY in subsequent 
> subscribes since the latest entity tag will be used. 

The model tries to take privacy filtering into account with the concept
of representations. In effect, each possible variation of the resource
state due to privacy filters being applied and whatnot, is a unique
representation that has it's own entity-tag pool. Notifications are only
generated for this representation, when actual reportable changes
trickle through the filters. At this point, a new entity-tag would be
generated as well.

If the model isn't clear on this, I'm open to suggestions.

Thanks for the review!

Cheers,
Aki

> --Avshalom
> 
> 
> 
> 

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip