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

[Ballot comment]
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"?

[Ballot discuss]
I support Cullen's DISCUSS -- I read in the summary that the working group has spent a year clarifying whether it's entity state or event state that's indicated by the token, but that clarity (and related understandings) didn't make it off the mailing list into the doc.

[Ballot comment]
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.

[Ballot discuss]
I really like the etag concept for subscriptions and strongly support this draft. However, I know from the etag experence in HTTP and webdav, we need to have this pretty crisp for implementors or we will have lots of problems. This document probably needs some changes.

In particular, it seems to say in a few places that the one needs to save forever and infinite number of old entity tags. This is clearly not implementable and I doubt what anyone really wanted.

Just to check I am on the same page with everyone else. I want to check we all agree on the following. A client device does a poll and gets ETag=123 and a entity state of foo. Later it does a poll with an etag of 123 and if the responses body is suppressed, at this point the client can use the value foo for the entity state just as if the response had actually returned foo. I want to make sure we all agree this is true that the client can rely on using the value foo in this case. If not the mechanisms seems pretty useless.

The big issue has to do with the draft is too vague about what the properties of an etag are. Statements like "the subscriber MUST NOT assume identical entities (i.e. event state) for NOTIFYs with identical entity-tag values" leave me baffled beyond belief. That directly contradicts exactly what this draft is all about which is if you have an etag that matches you can assume that the entity value is the same. The draft needs a list of properties the ETags MUST have and them some examples ways to generate them. From the WG discussion, I'm expecting that few ways of computing them would be
1) a sha1 hash of entity value
2) A date time stamp of every time the resource changed or a rule/filter/auth that changed an entity changed
3) an incrementing counter of every time the resource/entity changed and the counter was big enough to never wrap
4) an UUID every time the resource/entify changed

They types of properties I am assuming for an etag would be things along line of

A) if the etags are the same, it is statistically interoperability for the entities to not be the same

B) if two versions of an entity are the same, the etags may or may not be

C) different subscribers may or may not get the same the same etag for the same version of a resource

It would also be nice to know what the semantics of the etag in a request are. Does it mean the client has that version of entity? Or does it mean just don't tell me if it it has not changed since that version. This makes difference to storage and what extensions can be build on this. Section 6.4 seems to rely on the first type of description.

We also need more information about the scoping of the etags, saying they are scoped to Entities is not really right as theses disappear with the subscriptions disappears. I think it is closer to say they are scoped to the view of the resource but that introduces the whole view concept. I'm not sure exactly how to do this but the the draft struggles with the difference of the entity from the resource.

[Ballot comment]
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.

[Ballot comment]
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.

IANA Last Call Comments:

IANA has reviewed draft-ietf-sipcore-subnot-etags-02.txt, which is
currently in Last Call, and has the following comments:

Action #1:
Upon approval of this document, the IANA will make the following assignments
in the "Session Initiation Protocol (SIP) Parameters" registry located at
http://www.iana.org/assignments/sip-parameters.
Sub-registry: "Methods and Response Codes"

Note: under Successful 2xx
204 No Notification [RFC-sipcore-subnot-etags-02]


Action #2:
Upon approval of this document, the IANA will make the following assignments
in the "Session Initiation Protocol (SIP) Parameters" registry located at
http://www.iana.org/assignments/sip-parameters.
Sub-registry: "Header Fields"
Header Name compact Reference
----------------- ------- ---------
Suppress-If-Match | | [RFC-sipcore-subnot-etags-02]

We understand the above to be the only IANA Actions for this document.

[Ballot comment]
In Section 2.2:

  Some subscriber implementations may choose to operate in semi-
  stateless mode, in which they immediately upon receiving and
  processing the NOTIFY forget the resource state.

I suggest rephrasing this for readability:

  Some subscriber implementations may choose to operate in semi-
  stateless mode, in which they immediately forget the resource
  state upon receiving and processing the NOTIFY.

In Section 5.3:

[...]

  The subscriber MUST NOT infer any meaning from the value of an
  entity-tag; specifically, the subscriber MUST NOT assume identical
  entities (i.e., event state) for NOTIFYs with identical entity-tag
  values.

      Note that there are valid cases for which identical entity-tag
      values indeed imply identical event state.  For example, it is
      possible to generate entity-tag values using a one-way hash
      function.

I suggest deleting the Note, as it seems to contradict the MUST NOT
in the previous paragraph.
While I understand what you are trying to say, I think the Note text is actually not helping.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Dean Willis. He has reviewed this document
and believes it is ready for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been widely reviewed within the working group. Dale
Worley in particular provided some detailed analysis, and Eric
Rescorla also performed useful review leading to subtle changes in the
document. Paul Kyzivat provided further assistance with correcting the
ABNF during the final review process, and Adam Roach reviewed the
document from perspective of RFC 3265.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no shepherd concerns, and the shepherd is unaware of
specific IPR
disclosures.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document was widely reviewed within the working group between
August, 2007 and October, 2008.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

There appears to be no extreme discontent or significant conflict
surrounding the draft.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

The shepherd checked idnits, validated BNF using BAP, and did the usual
visual review of the document. There are no formal criteria review for
this document.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References appear to be appropriate.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations appear to be appropriate.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The document contains only a trivial BNF for a SIP response code and
another very small addition for a message-header. The BNF was verified
using BAP.


(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:


Document Writeup


Technical Summary

The Session Initiation Protocol (SIP) events framework enables
receiving asynchronous notification of various events from other SIP
user agents. This framework defines the procedures for creating,
refreshing and terminating subscriptions, as well as fetching and
periodic polling of resource state. These SIP Events Framework
procedures have a serious deficiency in that they provide no tools to
avoid replaying event notifications that have already been received by
a user agent. This specification defines an extension to SIP events
that allows the subscriber to condition the subscription request to
whether the state has changed since the previous notification was
received. When such a condition is true, either the body of a
resulting event notification or the entire notification message is
suppressed. This "conditioning" of the subscription requests uses the
well-known concept of entity tags (eTags).


Working Group Summary

This document received extended working group review during a WGLC
period that exceeded one year in duration. One critical clarification
came up in this review period: this specification does not provide
"versioning history" for events; rather it lets a subscriber know
whether the current event state is consistent with the event state as
currently known by that subscriber. The distinction is subtle. For
example, if the subscriber knows of event state "A", but the actual
state has changed to "B" and then back to "A", the subscriber will not
be informed about the B state through this specification.

Following WGLC, the proto review process detected and corrected a
minor error in the ABNF, and further review by Adam Roach detected and
corrected problem related to suppressed NOTIFYs on initial dialogs.



Document Quality


The Open Mobile Alliance SIMPLE Presence specification references this
document, and has done so for several years. Note that the most recent
OMA document the shepherd could locate references
draft-ietf-sip-subnot-etags-03.txt rather than the current
specification.