Subject: Issue Resolution - Issue #1: Feedback, protocol section 6.2

From: "Putzolu, David" <[email-masked]>
Date: Wed, 15 Dec 2004 14:37:20 -0800

Per the procedural email sent last week (see 
http://peach.ease.lsoft.com/scripts/wa.exe?A2=ind0412&L=forces&T=0&F=&S=
&P=1053),
I would like to begin working through and closing, if possible, the 
remaining issues with the protocol draft.

The first issue to resolve is #1, which is described at:
http://www.mip4.org/issues/tracker/forces/issue1

According to the process email, the first step in resolving 
this will be  determining whether it is a new feature or a 
change request.

My reading of the issue is that it is a change request. Is this
correct?

If it is a change request, I would ask that WG participants who
have been following this topic please weigh in on the need for
whether a change is needed or not, including reasoning and proposed
resolution.

Thanks,
David

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Dec 2004 18:05:43 -0500

From my reading of this issue, there are two or three different things
tied up here.

1) It has been agreed that operations against LFB components are to be
nested inside LFB selection TLVs.

2) I am not sure what the Show / Advertise operations are intended to
reflect.  Those may be Gets, or they may be something else that requires
elucidation.

3) There is an ongoing debate about whether FE/CE level interactions such
as heartbeat should be addressed to LFBs or to the CE /FE.  There is an
elegant consistency in protocol structure if they are addressed to LFBs,
but there is a lack of generality as well in that it appears to require
special operaions within the LFB targetting.  This discussion is ongoing.

it is also possible that there are aspects Jamal intended for this issue.

Yours,
Joel M. Halpern

---

From: "Wang,Weiming" <[email-masked]>
Date: Thu, 16 Dec 2004 20:35:48 +0800

I just have a general comment triggered by this issue:

1. I see the LFBclass ID and InstanceID in the Association Setup/Teardown
messages really redundant here. We know we do this is try to keep the
consistency of LFB targeted message format, but my view is it seems not so
valuable to sacrifice to keep this consistency. The same question is actually
firstly from the Heartbeat message. I remembered we had a long discussion on the
necessity for a specific HB message. The conclusion reached was we needed it
because we then can take a specific very bit-saved format for it ( only with the
message header for the message). Now, if we low down the HB as a general LFB
targeted message format, we actually don't need the message anymore. It just
plays the role of no more than one general event message.

2. Taking the thought that we don't try to keep the LFB target structure,  I
think the Association Setup/Teardown messages can be simplified much. Note that
some of the parameters related to the Setup can be accessed by CE later based on
general LFB targeting(to FE protocol object or FE object) operations after the
association is setup, while let the Setup  message only do setup.

One comment to the suggestion to change 'Message Type' to 'Command' is I am not
sure if it also applies to Event message or HB message well. One more thing is
it seems we have already be accustomed to call protocol messages as 'Messages'
instead of 'Commands'.

Thanks,
Weiming

----- Original Message -----
From: "Putzolu, David" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, December 16, 2004 6:37 AM
Subject: Issue Resolution - Issue #1: Feedback, protocol section 6.2

Thanks,
David

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 17 Dec 2004 15:08:46 -0500

> reflect.  Those may be Gets, or they may be something else that requires

The Name "advertised" by the FE is infact the attribute "FEName" - to be
found in the FEObject LFB instance.

The ASSOCIATION message can be viewed being equivalent to a event
equivalent to a query response on the FEObject. 
>From a semantic view, there is a fit for the ASSOCIATION message to
transport the FEs name when joining (in a similar fashion it transports
or requests to be told what its FEID). It is also ok for the CE to ask
it to change its name.
We should carry the name somewhere in the path-data. i.e there should be
no need to create extra operations like Show/Advertise. i.e it should
look like:

main hdr (type = ASSOCIATION)
     |
     |
     +--- T = LFBselect
             |
             +-- LFBCLASSID = 0x1 
             |
             |
             +-- LFBInstance = 0x1
             |
             +-- T = GET //operation
                 |
                 +--  // path and data to FEName

> it is also possible that there are aspects Jamal intended for this issue.

Elegance and simplicity of coding/parsing are my main drivers. The
coding piece: I know because we have implemented both schemes. Elegance,
look at the output of the BNF grammar in the case where theres
exceptions - It is larger. Bandwidth - i wouldnt even consider it an
issue to just add an extra LFB selector.

cheers,
jamal