Subject: Re: draft submission

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 15 Aug 2003 18:40:11 -0700

Yes, we are on the same page.
Thanks for the clarification.

Regards
Hormuzd
-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Friday, August 15, 2003 6:30 PM
To: [email-masked]
Subject: Re: [FORCES] draft submission

I had not intended to be arguing for "match block"  The argument in
favor
of match block seemed to me claiming that such a block would reduce the
complexity of the protocol.  I am arguing that such a savings is not
present.  I actually agree with Alan (and you in think) that the "match
block" as described is at best confusing and likely a mistake.

Yours,
Joel M. Halpern

At 06:14 PM 8/15/2003 -0700, you wrote:
>Joel,
>
>I agree with your position below.
>But I am not sure how the concept of "match block"
>would help with this ?
>
>regards
>Hormuzd
>-----Original Message-----
>From: Joel M. Halpern [mailto:[email-masked]]
>Sent: Friday, August 15, 2003 12:53 PM
>To: [email-masked]
>Subject: Re: [FORCES] draft submission
>
>
>Actually, I would be very disappointed if there were a distinct
protocol
>message in the Forces protocol for each type of block.  That would be
an
>unnecessarily complex protocol, and would distinctly limit
>extensibility.
>
>Rather, I would hope (and expect) that all blocks will use a basically
>common protocol messaqing, with different attributes (and methods,
still
>under discussion) being invoked by the same structure.
>That is, I would hope and expect that there will be
>a common mecahnisms to send requests and response among FE and CE
>components
>a common way to indicate the FE block or FE topology element being
>manipulated
>a common set of operations, such as
>     get attribute
>     set attribute
>     create entity
>     destroy entity
>     interconnect output port A of FELB1 with input port B of FELB2
>     get list of entities
>     and a number of other operations independent of the block types
>Attributes names, attibute values, etc will be carried in a
standardized
>fashion.  (Whether XML, ASN1, or something else.)
>This, when we create and extend a block library, the CE and the FE
>control
>components will be able to use the same protocol mechanisms to
>manipulate
>new blocks.
>
>Yours,
>Joel M. Halpern
>
>At 04:14 PM 8/15/2003 +0800, you wrote:
> > > > My fundamental
> > > > openion to propose a "match block" is that,  in the final ForCES
> > protocol, we may need
> > > > to associate every block with a specific protocol message. This
>may
> > make protocol look
> > > > quite redundant, and users may also feel a little boring to go
> > through the protocol.

---

From: avri <[email-masked]>
Date: Tue, 19 Aug 2003 09:03:47 +0900

Hi,

As I understand the match block, it does give the ability to do what 
Joel is suggesting in a powerful rule based manner.    It is certainly 
possible to use a operational (SNMP like - stepwise getting and 
setting) mechanism, but it should also be possible to do it using a 
rule based procedure.

I thought the match block was an good extension on an interesting model 
that allows it have greater expressive  power.

a.