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

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 5 Jan 2005 11:00:47 -0500

Happy New Year Hormuzd and everybody else,

On Mon, 2004-12-27 at 02:54, Khosravi, Hormuzd M wrote:

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

Agreed. 

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

Indeed.

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

The challenge is that each data sent needs to have a path associated
with it. We need to tie it to some path.
What do other people think? 

cheers,
jamal

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sun, 9 Jan 2005 23:01:19 -0800

Agree completely.

Thanks
Hormuzd
-----Original Message-----
From: Forwarding and Control Element Separation 

In any case, if we ever have a conference call i think it should
be to shoot for resolving the path-data issue which in my opinion
is the show stopper. All these other issues outstanding at the moment
are pretty much resolvable each in less than 10 minutes.

cheers,
jamal

---

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 12 Jan 2005 15:59:13 -0800

Robert, All 

The issue of LFB attributes serialization" method is actually a separate
issue and applicable to all messages (not just association). I will post
this as a separate issue (data encoding).

Other than that #1 should be closed.

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Robert Haas

In this context, the issue (raised on the list by Hormuzd) of 
advertising not only one atribute, but the whole LFB at once (for 
instance a core LFB) would require the definition of an "LFB attributes 
serialization" method, which is missing at this point.

And best wishes to all !
-Robert