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

From: Adam Roach <[email-masked]>
Date: Tue, 25 Mar 2003 18:14:43 -0600

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?

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

---

From: Ben Campbell <[email-masked]>
Date: 25 Mar 2003 20:12:46 -0600

> Jonthan? Ben? Do either of you object to removing

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.

---

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

inline.

> dependent is fairly weak, so I do not object to removing or softening

I think it has to go one of two ways. Either we say a LOT more about 
recommended ways to build the back-ends of such systems, so that a 
subscriber can expect better poll behavior, or, we say nothing about the 
back-ends, and then the motivation doesnt make sense. I vote for the 
latter, and so would prefer to remove the bullet.

-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