Subject: RE: [Simple] RE: Comments on draft-ietf-simple-event-list-00

From: [email-masked]
Date: Wed, 26 Mar 2003 10:19:24 +0200

A separate issue:

I build a list then I subscribe to the list. I start receiving notifications. During the subscription, I add a new member to the list. When does this become effective? I mean when would I start receiving notifications about this new member?

a) Immediately
b) After a subscription refresh?
c) After a new subscription?

Should there be some discussion in the draft about this? or is this implementation specific?

Regards,
Hisham

> -----Original Message-----
> From: ext Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, March 26, 2003 4:13 AM
> To: Adam Roach
> Cc: 'Sean Olson'; Simple WG; Jonathan Rosenberg
> Subject: RE: [Simple] RE: Comments on draft-ietf-simple-event-list-00
> 
> 
> On Tue, 2003-03-25 at 18:14, Adam Roach wrote:
> > Sean> 5) One of the problems that was given as
> > Sean> motivation for the draft in the Introduction:
> > Sean> 
> > Sean>    o  If a subscriber has only intermittent
> > Sean>       connectivity, and generally
> > Sean>       polls for state rather than simply
> > Sean>       subscribing, the latency to
> > Sean>       obtain the state of the entire resource can
> > Sean>       be large.  The messaging required for each
> > Sean>       poll can also be substantial.
> > 
> > Adam> You can poll. This works exceptionally well if the
> > Adam> RLS also hosts the resources (as will often be the
> > Adam> case in networks exhibiting this behavior).
> > Adam>
> > Adam> Because you're only having to poll the list instead
> > Adam> of each individual resource, you do end up having
> > Adam> a savings in overhead that can be considerable for
> > Adam> a large list.
> > 
> > Sean> I guess I was confused because it seems like polling
> > Sean> with an RLS can (depending on the implementation of
> > Sean> the RLS) be somewhat useless. The draft alludes to 
> > Sean> this at one point.
> > 
> > That's true. It depends greatly on whether one can
> > know a priori whether the RLS will also serve the
> > resources. Since this really is only the case
> > in a closed system, I don't have any problem with
> > taking out this particular bullet point.
> > 
> > I didn't write that part of the document, though:
> > Jonthan? Ben? Do either of you object to removing
> > this bullet?
> 
> It is equally possible to build RLS implementations where polling is
> very useful. Even if the RLS does not have authoritative knowledge of
> all the list members, nothing forces the RLS to associate back-end
> subscription lifetimes with the list subscription lifetime. 
> So you could
> build an RLS where the first poll attempt triggers back-end
> subscriptions. The first poll would not net much, but subsequent polls
> could be _very_ useful.
> 
> However, I can accept that a motivation that is so highly 
> implementation
> dependent is fairly weak, so I do not object to removing or softening
> it.
> > 
> > /a
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 
_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 27 Mar 2003 00:55:42 -0500

inline.

> c) After a new subscription?

The answer is (a) if you want a useful system.

> Should there be some discussion in the draft about this? or is this implementation specific?

I think its worth mentioning in the draft that the list could change 
during the lifetime of the subscription, in which case the RLS should 
take the appropriate actions as soon as possible.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Scientist                             Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com