An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification
draft-ietf-sipcore-subnot-etags-04

In section 5.6 you have several times...
  before the subscription is about to expire

This may be a little subtle, but do you mean "slightly earlier than before the subscription expires" or do you mean "when the subscription is about to expire"?

A bunch of these likely need to be a discuss level item but I would like to wait till we have talked about them a little in some email threads before I figure out which ones need are not just a comment level note. Much of it depends on how the previous items get resolved. 

In abstract, I don't think this system tells you if state has changed, it tells you if the state is different than a previous fetch value. It may have changed and changed back to original and this system would not necessarily tell you that. 

Need more explicitly discussion of what happens when something that would change the Entity but not the resource happens. Say a filter rule changes but the resource did not. Does this change the etag? 

Explain why we want the "*" and when to use it 

Not enough discussion of what it means for two version of an entity to be the same. I would suggest bitwise exact. I don't want to get into things like whitespace chances in an XML doc that don't effect the canonical form of the document are OK. 

The document says in multiple places that there is a single authoritative notifier for a given resource or words along theses lines. I'm not sure this is really true - clearly many systems allows many different UA to act in a authoritative way for a resources. One just hopes they all return the same answer. It's not even clear to me that there could not be different answers based on where in the network the request came from. 

Section 1.2 - Entity definition. Worth noting that 3256 uses entity to mean something different than this. The definition of it is what is in the body does not work for what you want with the differential encoding approaches to state. I think you will need to change the definition to make this work. The idea that the entity-tag is unique across all version seems wrong - for example this would not be true with a hash based approach. 

Section 2.2 - "low rate of notification triggered by state changes" should be clear the state we are talking about is resource state 

Pretty much everywhere the word "unique" occurs I think it bears some careful thought about if that is right and the scope of it. For example, 2nd para of section 3 seems wrong. 

The statement "the notifier remembers the entity-tags of all version of entities" just about made me spill my coffee. Surely not. 

The discussion of how this was not like Publish in section 3 just seemed confusing and not needed in this part of the draft.

The first sentences in last para of section 3 seems like it would make far more sense in middle of previous paragraph.

I found section 2.2 pretty useless and wonder if it could just be deleted. I know how it got there but I don't see any value for it in the RFC. 

Figure 1 would make more sense if between 6 and 7 there was a step that indicated the resource changed value 

Figure 2 would make more sense if you deleted all the things that were not discussed. Basically everything except URI, resoruces, Entity, Version, and Entity-tag

In section 4 where you have "a resource is identified by zero or more"  - I don't see how zero works. I would have put one or more. 

When I look at the things that are part of the entity-header, I don't see how any of these can change without the body changing so I don't understand why they need to be covered by the etag. Why are they needed?

Section 4 has a para starting about "Note that two entity tags being equal does not ....". This seems wrong to me. How would this work. 

More is needed about treatment of difference encoded data. I agree with what you are saying - I just think this is going to need to be more explicit to have implementors get it right. 

Section 5.2 - first para says "MUST include" - shouldn't this be "MAY include". There are cases (like the first time you subscribe) or when the state was very old - that the device may want a full refresh. 

Nothing seems to discuss how entity tags are compared. We should head of the case sensitive and related arguments.

Section 5.4 - figure 3 - it was not clear reading this why it did a 202 instead of a 204. I understand what why but that detail is sort of missing from the figure. 

Section 5.6 make clear this is inside a subscription dialog and that is why did 204.

Might be nice to show example that uses "*"

The B2BUA section seems sort of wrong. A B2BUA is, well among other things a valid UA. There will be two types - ones that implement this spec and ones that don't (ie existing B2BUA). When A B2BUA that supports this receives this header on one side, it will know how to use it on the other side (if local policy wants it to do that) so it all works. Fo a B2BUA that does not support this, it would be non compliant with the SIP spec for the UA to include the header it did not understand. So the B2BUA would not transit the header and the the client would assume the Notifier did not support this (which is basically true given the NOTIFIER to the client is the B2BUA). So again things work fine. Basically this scheme works fine with existing B2BUA that dod not support this and future ones that might support it. 

The example of an etag that is implemented by a counter of NOTIFY generated seems very broken. So you have two people subscribed to the resource. One supports etags one does not. Both poll every minute. It seems to me the etag will never match. 

"An entity tag is valid as long as an entity is valid" - I have no idea how long an entity is valid. Does it stay valid when the subscription terminates? what would that even mean? when would it become invalid?

Section 6.1 - I had no idea what you are talking about of remember older etags for journal state updates until I read section 6.4. I think 6.4 is not quite right for things where the resource did not change but something else changed that would cause the entity to change. Similarly with section 6.5

The whole established dialog stuff seems pretty arm wavy. What if it was an INVITE that established the dialog, or a dialog to different event package, or different resource. I think this all needs to get a bit crisper. Probably need some mention of it in the introduction and explanation of two different types of suppression. 

Section 9 - I'm not sure I buy this does not change the security situation. It seems like some attacks want to suppress certain messages going from server to client and this might give new angles to cause suppression of NOTIFYies.

Minor clarification: it might be useful to include the "else" condition for the condition evaluation in steps 6 and 10 in the typical message flow.

Section 3, paragraphs 2 and 3 should probably introduce the notion that entity tags are specific
to a state for the resource.  This idea doesn't surface until step 7 in the typical message
flow, which is too late imho.