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

From: Aki Niemi <[email-masked]>
Date: Mon, 25 Feb 2008 23:06:38 +0200

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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Aki Niemi <[email-masked]>
Date: Mon, 25 Feb 2008 23:08:53 +0200

On ti, 2007-10-02 at 10:53 -0400, ext Asveren, Tolga wrote: 
> Draft: draft-ietf-sip-subnot-etags-01
> Reviewer: Tolga Asveren [[email-masked]]
> Review Date: 2 October 2007
> Review Deadline:
> Status: post-WGLC
> 
> Summary: This draft is on the right track for publication and requires a
> few additions/clarifications before publication
> 
> Detailed Comments:
> 
> * 1.2 Terminology , definition of representation
> The definition of "representation" does not provide a definition. There
> are just some statements about "representation". I am not sure whether
> such a definition is necessary either. I would suggest deleting
> "representation" from this section.

Done.

> * 3. Overview of Operations, remembering entity-tags for all versions
> Why is it necessary for the notifier to remember all versions of an
> entity? To check entity-tags in SUBSCRIBEs to determine whether an
> update has happened, it just needs to know the entity-tag for the last
> version. 

Yes, but if the same entity-tag was given to a subscriber in the past,
how would the notifier know which one the subscriber is using?

> To generate unique entity-tags, it can just use a counter with
> some extra information to deal with restart situations, e.g. some
> information extracted from current time. 

Right, generating unique entity-tags doesn't require much more than
this. The extra information can be a timestamp and the resource URI for
instance. That would already fulfill the uniqueness property.

> * 5.2 Generating SUBSCRIBE requests, presence of multiple conditional
> headers
> I assume simultaneous presence of both "Suppress-Body-If-Match" and
> "Suppress-Notify-If-Match" is allowed. This could be useful for
> polling/resuming a previous subscription scenarios, where the subscriber
> isn't sure about the capabilities of the notifier. Mentioning about this
> possibility could be useful IMHO:
> "It should be noted that subscribers MAY include both
> Suppress-Body-If-Match and Suppress-Notify-If-Match conditional header
> fields together in a SUBSCRIBE request. This type of usage could be
> utilized for the cases where the subscriber is not sure about the
> suppressing capabilities of the notifier."
> I guess, we would also need to define what a notifier should do upon
> receipt of both headers:
> "If a notifier receives both Suppress-Notify-If-Match and
> Suppress-Body-If-Match headers, it SHOULD suppress the notification if
> the condition evaluates to true if it has this capability. Otherwise it
> SHOULD suppress the body of the notification if it has this capability.
> If the notifier can't do either of these, it simply SHOULD ignore these
> headers."

You're correct. The new draft version does exactly this but in another
way, i.e., there is now only one header field that does all that the
previous two did separately.

> * 5.4 Polling or Fetching Resource State, meta-information query
> What is a real life use case for meta-information query? What value
> would learning current entity-tag value provide from subscriber
> perspective?

This was probably a little too sci-fi. I've removed the text.

> * 6.1 Generating Entity-tags
> "For example, one possible method is to implement the entity-tag as a
> simple counter, incrementing it by one for each generated notification
> per resource"
> I have a few questions regarding this sentence:
> i- Multiple notifications to different subscribers could be generated
> for the same state. I don't think all these should cause a new e-tag
> value. AFAICS, the rule for a new entity-tag is as follows:
> "If a notification is generated for the current state and if the state
> changes, a new entity-tag MUST be assigned". 

I believe the draft says exactly this. Can you point to specific text
that needs fixing?

> ii- What about notifier restarts? It may be helpful to indicate about
> some differentiator between cycles, e.g. some information based on
> current time. I guess the crucial point is to make sure that the same
> entity-tag is not reused for two different versions because that may
> suppress necessary state notifications. 

A timestamp is a good idea in any case, given the uniqueness requirement
for an etag.

I'm reluctant to specifying any fixed (normative or otherwise)
specification of the entity-tag, but to leave it as an implementation
detail. Implementors don't need help here, and are likely to come up
with a better one that suits them better anyway.

> It is still tolerable if the
> notifier -for whatever reason- uses two different entity-tags for the
> same version at two distinct times. Maybe a sentence could be added
> about this : "Subscribers MUST not assume that a notifier will always
> use the same entity-tag for a specific version. Especially after
> notifier restarts, this MAY not be the case."

The way this needs to work for the subscriber is that a new NOTIFY
always resets the entity. I added a sentence on this based on Brian's
comments. Still, if you think this needs to be more explicit, I'm open
to suggestions. 

> * Forking
> RFC3265 4.4.9 has the following:
> " If such behavior is not allowed, the first potential
> dialog-establishing message will create a dialog.  All subsequent NOTIFY
> messages which correspond to the SUBSCRIBE message (i.e., match "To",
> "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and
> "Event" header "id" parameter) but which do not match the dialog would
> be rejected with a 481 response.  Note that the 200-class response to
> the SUBSCRIBE can arrive after a matching NOTIFY has been received; such
> responses might not correlate to the same dialog established by the
> NOTIFY.  Except as required to complete the SUBSCRIBE transaction, such
> non-matching 200-class responses are ignored. "
> It could make sense to amend this behavior. Consider the case, where the
> SUBSCRIBE forks and the first 200/NOTIFY arrives from a notifier which
> does not support suppressing and after a short while subscriber receives
> the NOTIFY from another notifier with an entity-tag. It could be
> preferable for the subscriber to terminate the first dialog and continue
> the second one.

Possible in theory, but in reality, how likely is it that this will be a
problem?

I just find it an incredibly bad idea to build a system that behaves
this way. 

> * Implicit Subscriptions, REFER
> I think this mechanism is applicable for implicit subscriptions as well.
> It could be an idea to mention this somewhere (maybe in 2.3.
> Requirements)
> To say a sentence or two about REFER initiated subscriptions could be
> useful as well. I guess it doesn't make much sense to use suppressing
> capability in this case: "Although technically it is possible to use
> notification/body suppressing capability for REFER initiated
> subscriptions, this is not seen as desirable considering the REFER use
> case."

Hmm... Good point. AFAICS, this should work as-is with REFER
subscriptions as well. I added this to section 4: 

        The conditional notification mechanism is independent of the
        way in which subscriptions are installed. In other words, the
        mechanism supports implicit subscriptions, such as those
        associated with the <xref target="RFC3515">REFER
        method</xref>.
        
> 
> Nits:
> * 3. Overview of Operation, middle of the second paragraph
> ", and attaches includes it in a SIP-ETag" 
> Just use either "attaches" or "includes"

Fixed.

Thanks for the review!

Cheers,
Aki