Subject: Re: [issue 9] Fix LFB definition

From: Dong Ligang <[email-masked]>
Date: Tue, 16 Aug 2005 09:56:45 -0400

I think not all LFBs (at least not entire LFB) are managed/controlled by 
the CE. 
As we konw, there exists some LFB attributes 
that managed by FE manager not CE.

regards
Ligang

-------------------
BTW, I am really suprised at the weak definitions of LFB; i just glanced
at model and framework docs.

Probably you want to emphasize the following:
- it resides at the FE (since we killed CE based LFBs)
- it _may_ process packets
- it is managed/controlled by the CE

i.e something along:
"LFB classes are the basic building blocks that are operated on by the
Forces protocol. The LFB is a well defined, logically separable
functional block that resides in the FE and is controlled by the CE via
forces protocol. The LFB may reside at the FEs datapath and process
packets or may be purely a control entity that is operated on by the CE"

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 16 Aug 2005 11:27:11 -0400

I guess this depends upon interpretation.
1) It is extremely unlikely that the FE Manager will control any LFBs.
2) Some LFBs are set up and their parameter settings controlled by the FE 
itself.
3) All LFBs are there for CE interaction.  An LFB which the CE neither 
reads nor writes serves no purpose.  An attribute in an LFB which a CE can 
not write and has no reason to read serves no purpose.

Phrased differently, LFBs are an abstraction of FE functionality for the 
purpose of working with the CE.
It is true that some LFBs are not modifiable, but they will still be 
examined by the CE.  (And such LFBs will severely limit what the CE can do.)

Yours,
Joel M. Halpern