Subject: RE: [Simple] WGLC - watcherinfo

From: Robert Sparks <[email-masked]>
Date: Mon, 3 Dec 2001 15:55:12 -0500

There's been one (1) response to this so far - 
if you have a comment get it in before 12/7.

Please drop a note if you think the draft is
good to go as is so we don't misinterpret silence
as lack of consideration.

RjS

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, November 28, 2001 3:50 PM
> To: [email-masked]'
> Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg
> Subject: [Simple] WGLC - watcherinfo
> 
> 
> There's been very little response to the
> request for discussion on watcherinfo.
> Hopefully, that means the drafts are ready
> to go. 
> 
> This is the last call for comments on these drafts:
> draft-ietf-simple-winfo-package-00.txt
> draft-ietf-simple-winfo-format-00.txt
> 
> This call will close on 12/21, but please have 
> comments on technical deficiencies in by 12/7 
> so that we can discuss them at IETF 52.
> 
> RjS
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: Ben Campbell <[email-masked]>
Date: 05 Dec 2001 13:50:58 -0600

OK after re-reading this, I have a couple of comments on section 3.6.1
(the FSM section.)

1)  [tiny nit] The state diagram shows a timeout transition between
<waiting> and <terminated>. I don't find anything about that in the text
treatment.

2) Some of the FSM description really seems more a description of the
authorization FSM rather than the watcher info notification FSM. In
particular, the treatment of pending vs. waiting suggests behavior on
the part of the SIP-event service beyond that of watcher reporting. This
section seems more descriptive than normative, so that is probably okay.

3) I know this has come up many times before, and I don't remember the
resolution. Apologies if I am beating a dead horse: I have some concern
about the concept of keeping state around indefinitely for pending
watchers. Could this not be used as a DoS against the server? It's not
nearly so bad as keeping state for denied users, but the threat may
still be there.