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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 26 Dec 2004 23:54:09 -0800

Jamal,

Sorry for the late reply. Pls see my replies below...

-----Original Message-----
From: Forwarding and Control Element Separation Of Jamal Hadi Salim
> > 
> > 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.
> 
> The Name "advertised" by the FE is infact the attribute "FEName" - to
be
> found in the FEObject LFB instance.
> [HK] I think we have some misunderstanding here, not sure what gave
you
> this impression,
>  but the "advertise" operation is used to advertise the
> entire FE protocol object 

Did you mean the FE Object LFB? [I actually meant the FE Protocol
object, may be we need both?]
The FEname and FEID are stored in the FEObject.

Heres the way i see it:
The typical path is a CE setting things in the FE Object LFB.
The exceptions are things like the FEID in which the FE on association
setup can announce a 0 FEID in the main header as a signal it needs to
be assigned one. We also allow for it to provide one to the CE if it
knows what it is (example based on a geographical chasis location you
could come up with a static ID scheme).
The other exception i can think of that the FE would know on bootup is
its name (we could probably add vendor specific items in this list as
well - eg what model it is etc).
So those are the two things that belong to the FE Object that a FE can
"advertise" to the CE. Both of which are infact read/write i.e can be
overriden in the response (with the CE setting the values by directing
them to the FE Object attribute).
** There is a scenario where an FE may actually have a lot more
attributes on the FE Object populated. Such is in the case of a
situation where an FE is forced to reassociate for example - maybe due
to lost communication or a restart of some form.

So the summary of what i am saying is the FE OBject LFB is a source as
well as sink of the Association msg/response. If there are any
attributes already known to the FE then it makes sense to notify the CE
of their state (the name being one of them). 
[HK] Yes I agree with that...similar to what I am saying. I think we
will need both the FE Object and FE Protocol object to be advertised in
the Association message. You pointed out a good scenario where FE would
have more info than just FE Name to be advertised to the CE.

> Let me know how you would like to resolve this? Any suggestions would
be
> welcome.

Isnt this discussion the point? If we dont get anywhere i will capture
it in the tracking database. [I think if we agree with the comments
above, we have resolved this one...atleast partly]

> One more thing, you had asked for a special TLV -> FORCES_REASON for
the
> Teardown msg. Since we would both like to avoid this, any suggestions
on
> how this can be accommodated via FE LFBs? May be we remove the Reason
> completely from the Teardown msg?...let me know your thoughts?

This is a hard one. We could send it easily (either direction) if it is
an attribute. I think for logging debugging purposes we would need to
know the departure reasons. But whose attribute is this?
Maybe other people have opinions.
[HK] We could use similar mechanism as we do to report all our results,
to report the Reason. Let me know your thoughts,

Thanks
Hormuzd