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

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 19 Dec 2004 15:41:10 -0800

Jamal,

Pls see my comments below...
-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf 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 to the CE in the Association message, not just
the FE Name. The idea is that the CE learns the FE protocol
attributes/parameters via this message and can reject an FE based on
this information, if it so desires.

The ASSOCIATION message can be viewed being equivalent to a event
equivalent to a query response on the FEObject. 
[HK] That's not the case, pls see my previous comments.

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

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?

Regards
Hormuzd

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 20 Dec 2004 22:45:06 -0500

Hormuzd,

On Sun, 2004-12-19 at 18:41, Khosravi, Hormuzd M wrote: 
> --Original Message--
> this impression,
>  but the "advertise" operation is used to advertise the
> entire FE protocol object 

Did you mean the FE Object LFB?
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). 

> to the CE in the Association message, not just

Again you are refering to the FE Protocol Object above?
I think that also may deserve to be in the ASSOCIATION.

> [HK] That's not the case, pls see my previous comments.

Refer to my comments above.

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

Isnt this discussion the point? If we dont get anywhere i will capture
it in the tracking database.

> 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.

cheers,
jamal