Subject: [Simple] WGLC: partial notification

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Apr 2004 09:55:42 -0500

This is a Working Group Last call on the following drafts:

http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-notify-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-partial-pidf-format-01.txt

This abbreviated WGLC will end on Wednesday, April 28.

These drafts went through a previous last call at the beginning of
March. These versions reflect changes due to comments received during
that period. See
https://www1.ietf.org/mail-archive/working-groups/simple/current/msg02519.html
for details.

Please send comments to the list, copying the editor. If you reviewed
the draft and found no issues, please indicate so on the list.

RjS

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Apr 2004 17:02:48 -0500

Writing as a WG member - not as chair -

I've sent a list of typo level nits in these drafts to Mikko privately -

While doing a nit review, I found some things that should have received
list attention earlier. 

In section 4.4 of -partial-notify it says "The PA SHOULD construct
the partial presence document according to the following logic:"
followed by a bunch of MUST level statements. Why is that SHOULD there?
What would it mean to violate it? I suggest striking it and simply
saying "The PA constructs"

Why do we have both "state" and "version"? As defined in these drafts,
state=full if and only if version=0. You could delete the state
parameter with no loss of information, so why is it there?

3261 currently allows overlapping non-INVITE transactions inside
a dialog (there's an open issue suggesting this might be a bad
thing, see http://bugs.sipit.net/sipwg/show_bug.cgi?id=686). Neither
3265 or simple-presence prohibit overlapping NOTIFYs. For full state
documents, having multiple outstanding NOTIFYs is probably manageable.
For partial state documents, at least as they are specified here, it
could be disastrous. Consider four notifies N1(full), N2(partial),
N3(full), N4(partial). If the recipient receives only N1 and N4
(something prevents N2 and N3 from being delivered or simply delays
them (packetloss over UDP for example)), it will apply the delta in
N4 to the wrong full state document (N1 instead of N3). We can preserve
the properties of the existing system is we forbid sending a NOTIFY
with a document with state="partial" when any other NOTIFY transaction
is still in progress on this dialog.

Section 4.5 of partial-notify says "If the watcher receives a presence
document whose "version" attribute value (is) higher by more than one
with the locally stored value, the watcher assumes that one or more
NOTIFYs were lost. The watcher SHOULD either refresh the subscription 
in order to receive a full presence document or terminate the
subscription."  Why is that SHOULD? In what scenario is any other
course of action reasonable? (The only one I can think of is
_if_ we allow overlapping partial NOTIFYs, then the watcher can wait
around for awhile for the gaps to fill in - if we allow this, then
we need to explicitly state this as why the above is SHOULD, not MUST.
However, I think this should be a MUST.)

Just below that, there's a "SHOULD discard the document" if it gets
a partial notification with a lower version number. I don't see how
this is right at all, and suggest that this MUST trigger a refresh
or termination instead. (We wouldn't get to this logic if a NOTIFY
was reordered and arrived late - the CSeq processing logic would 
have caught it).

I'll send a separate message on the Security Considerations
section for -partial-notify.

RjS

---

From: Robert Sparks <[email-masked]>
Date: Thu, 22 Apr 2004 17:02:48 -0500

RjS

---

From: Robert Sparks <[email-masked]>
Date: Fri, 23 Apr 2004 10:32:58 -0500

The abstract for -partial-notification needs to focus 
more on what the document is defining. I suggest this
as a replacement for the current text:
                                                                               Abstract

   By default, presence delivered using the Presence Event
   Package for the Session Initiation Protocol is represented
   in the Presence Information Data Format (PIDF). A PIDF
   document contains a set of tuples, each representing
   a different aspect of the presence being reported. When
   one tuple changes, a new document containing the full set
   of tuples is delivered. This memo defines an extension
   allowing delivery of a new document type that contains
   information about only those tuples that have actually
   changed.

---

From: Robert Sparks <[email-masked]>
Date: Fri, 23 Apr 2004 10:32:58 -0500

---

From: Robert Sparks <[email-masked]>
Date: Fri, 23 Apr 2004 14:52:44 -0500

I was going to wait until I could "send text" for this, but the
weekend is looming and I want people to start thinking about this
earlier rather than later:

The current security considerations section in partial-notify
will draw "Did you really think about this?" scrutiny. The bare
"there are no new problems here" assertions dominate the
"We thought about this, but its not a problem because" discussions.

A global statement justifying the bare assertions would help.
I think that's what the first sentence was trying to do, but
its not correct (this _does_ introduce protocol functionality
or we wouldn't need a PS document).

More text exploring attacks against the partial notification
mechanism itself is warranted (yes, we've thought through this,
and we've convinced ourselves there are no new problems. We need
to leave tracks making it easier for the rest of the IETF
to convince themselves there are no problems.

Some things we could discuss:

  A third party can inject a partial notify that will cause the
  watcher to think it missed a partial document and request
  a new full state document. This is no worse than what we
  have without this extension since a party that could pull
  that off could also simply send a Subscription-State: 
  terminated NOTIFY and achieve the same effect without
  knowing about the extension. We've made the situation
  no worse, and the protection mechanisms form the existing
  system apply to preventing this attack against the partial
  notification mechanism.

  Its probably worth explicitly discussing what happens when
  you replay a partial-notify document in a new SIP NOTIFY 
  (as opposed to replaying the whole NOTIFY). (What happens
  will depend on the answer to one of the questions I asked
  in a different thread.) Its also worth explicitly calling
  out how to protect against this kind of replay.

Hopefully the rest of the group can help capture the other things
we've talked about (send text).

RjS

---

From: Robert Sparks <[email-masked]>
Date: Fri, 23 Apr 2004 14:52:44 -0500

RjS