Subject: RE: [Simple] WGLC - watcherinfo

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 4 Dec 2001 01:03:17 -0500

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Wednesday, November 28, 2001 5:21 PM
To: 'Robert Sparks'; [email-masked]'
Cc: Jon' 'Peterson (E-mail); Jonathan Rosenberg
Subject: RE: [Simple] WGLC - watcherinfo

>Well, if you insist. I don't see the need for the "event" 
>in the XML winfo format. The "status" seems to carry 
>everything that is needed.

No, and for much the same reason we have asked for various reason phrases in
the Subscription-Expires header for sip-events. If a subscriptions state
goes to terminated, the reason it went there (rejected vs. deactivated)
makes a difference in the subsequent processing.

> The "first-subscribed" element 
>also seems a bit odd. Either this requires the PA to 
>maintain information that lasts longer than a subscription 
>(a bad idea) or it is a mislabelled and probably useless 
>piece of information. 

Good point. I don't know what I was thinking here. I think its useful to
know when they first subscribed, but as soon as the subscription expires,
this data would be lost, and a new subscription would result in a new
"first-subscribed" value.

>What is the purpose of providing 
>(optionally) the "notify-address" in the winfo? 

If there was a reason, it slips my mind at this time.... I'm happy to remove
it.

-Jonathan R.

>-----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 
> 

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Dec 2001 11:49:40 -0500

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, December 05, 2001 2:51 PM
> To: [email-masked]; Robert Sparks
> Cc: [email-masked]
> 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.

It is in there:

   Of course, policy may never be specified for the subscription. As a
   result, the server can timeout the waiting subscription. The value
   for this timeout is system dependent. It SHOULD be several times
   larger than the default expiration time for the package being
   watched.

Its not clear that this is the timeout event. I've reworded to:

   Of course, policy may never be specified for the subscription. As a
   result, the server can generate a timeout event to move the waiting
   subscription to the terminated state. The value for this timeout is
   system dependent. It {\SHOULD} be several times larger than the
   default expiration time for the package being watched.

> 
> 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.

The section heading is a misnomer. You are right that this FSM is NOT the
description of the winfo FSM. Its a descrption of the FSM for sip-events in
general, or at least a model of that FSM, as a well-defined model is needed
for the watcherinfo package to work. That definitely needs to be clarified.
I updated the text at the top of 3.6 to say:

   Notifications may be generated for watcher information on package foo,
   when the subscription state for a user on package foo changes. The
   watcher information package therefore needs a model of subscription
   state. This is accomplished by specifying a subscription state
   machine, described below, which governs the
   subscription state of a user in any package. Notifications are
   generated on transitions in this state machine. Its important to note
   that this FSM is just a model of the subscription state machinery
   maintained by a server. An implementation would map its own state
   machines to this one in an implementation-specific manner.

and I changed the title of 3.6.1 to "The Subscription State Machine"

> 
> 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.

I don't recall what conclusions were made from past discussions.

I do think that it needs to be a policy decision. Remember, we are talking
about authenticated, but not authorized, subscriptions, so that the room for
DoS attacks is narrowed. Of course they can still happen. So, you want the
server to be able to make a policy decision. It should be allowed to move
the subscription to terminated at any time. The "timeout" event exists from
the waiting state to terminated for this reason, but also needs to exist at
the "pending" to "terminated" transition as an allowed event. I will add
that. The spec also says that the server SHOULD set the timeout interval to
be much larger than the refresh interval for subscriptions; i will temper
that to discuss making it shorter to handle potential dos attacks.

So, I added the following text:

   The ``timeout'' event is generated in either the waiting or pending
   states to destroy resources associated with unauthorized
   subscriptions. Servers need to exercise care in selecting this
   value. It needs to be large in order to provide a useful user
   experience; a presentity should be able to log in days later and see
   that someone tried to subscribe to them. However, allocating state to
   unauthorized subscriptions can be used as a source of DoS
   attacks. Therefore, it is RECOMMENDED that servers which retain state
   for unauthorized subscriptions add policies which prohibit a
   particular subscriber from having more than some number of pending or
   waiting subscriptions. 

Thanks,
Jonathan R.
---