Subject: Re: [issue37] TBD - FE Protocol Attributes

From: "Putzolu, David" <[email-masked]>
Date: Fri, 3 Jun 2005 11:39:33 -0700

(hat off)

The approach you propose Joel makes sense to me technically, and it is
also a nice partitioning of the work :)

-David

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email-masked]] On Behalf Of Joel M. Halpern
Sent: Friday, June 03, 2005 11:29 AM
To: [email-masked]
Subject: Re: [FORCES] [issue37] TBD - FE Protocol Attributes

A reasonable question.

My current take is that the FE LFB should come with the model document,
and 
the FE-protocol LFB should be defined by the protocol document.
However, this is something on which reasonable people can easily differ,

and I am open to alternatives.

Yours,
Joel

At 10:50 AM 6/3/2005, Weiming Wang wrote:
>It seems we need to first decide "who should define the LFBs like
FE-LFB, 
>FE-protocol-LFB, this protocol document or elsewhere"  before trying to

>decide this issue.
>thanks,
>Weiming

---

From: "Wang,Weiming" <[email-masked]>
Date: Mon, 6 Jun 2005 15:15:18 +0800

Joel, David, and Robert,

I have some thoughts, some by my experience with GRMP:
1. Defining things like LFB attributes in details in the protocol docuement will
really leads the document to a comlex one.
2. Currently, we may be a little far away from accurately defining these
attributes.
3. Therefore, will eventually bottleneck the protocol document from going to
last call.

I actually incline to strip all that are related to LFB definitions from current
protocol docuement, while only leaving it for open discussion later that
"whether they go to model document or to a specific one for LFB definitions used
by protocol" .

Thanks,
Weiming
----- Original Message -----
From: "Putzolu, David" <[email-masked]>

(hat off)

-David

-----Original Message-----

A reasonable question.

Yours,
Joel

FE-LFB,

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 6 Jun 2005 09:01:49 -0400

I am about 60% in agreement with Weiming. Infact, thats what i was
stating before the last IETF meeting. I even have a draft called "Core
LFBs" to prove it ;->

Actually the main valid reason that Weiming provides is #3. We need to
get both the protocol and Model drafts to last call and moving this out
will help speed things up. I believe the core LFBs should still be
mentioned in the two drafts but not elucidated.

cheers,
jamal

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2005 11:19:33 -0400

I tend to disagree.

With regard to the FE LFB and the model draft, my concrete concern is that 
a human being reading the model draft without the FE LFB will not 
understand how a CE can actually make use of the model.  We could just say 
that there is an FE LFB (class 1, instance 1), that it has the basic 
information the CE needs, and leave the details to another draft.  But I am 
pretty sure that will leave readers confused.  As a minor related note, 
including the FE LFB will give me an easy way to provide an example LFB 
definition, including information about properties for access control.  (I 
won't be able to get alias in.)  I currently intend to also include some 
events (LFB Creation, LFB Deletion, Capability change, are the ones I think 
belong.)

With regard to the protocol, it is probably not as big an issue.  After 
all, we have a long tradition of putting instrumentation for protocols in 
other documents (MIBs).  The difference is that most protocols can run 
without their MIB.  Can we run the forces protocol without the Forces 
Protocol LFB?  (We can not run the model / protocol without the FE LFB.)

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 6 Jun 2005 20:50:14 -0400

On Mon, 2005-06-06 at 11:19 -0400, Joel M. Halpern wrote:
> won't be able to get alias in.)  

No aliases in general or just if FE LFB doesnt make it in?

> I currently intend to also include some 

This would be useful to show; but also if we can have some attribute
change being shown as an event - it would be more complete.

> Protocol LFB?  (We can not run the model / protocol without the FE LFB.)

The protocol needs the FE Protocol LFB from what ive seen so far.

Lets put it this way, if it will _not_ delay the two main drafts from
going last call, i have no objections to the two core LFBs to be split
and merged in the protocol and Model LFB. My impression so far has been
they are almost there. But reading Weiming's email i sense his opinion 
is that it's not ready at all.

cheers,
jamal

---

From: "Wang,Weiming" <[email-masked]>
Date: Tue, 7 Jun 2005 09:39:15 +0800

Jamal,

----- Original Message -----
From: "Jamal Hadi Salim" <[email-masked]>

> is that it's not ready at all.
Note that we now only have names for most of the Core-LFB attributes. To make
specific definitions for these attributes will still take a long way to go, I'm
afraid.

I tend to agree with you that IF it will not greatly block the process, to put
the protocol LFB in the protocol draft is ok to me.

As a resut, we then need to try to define them now.

cheers,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2005 22:57:30 -0400

I just can't come up with a good reason to use alias in the FE LFB, so 
there won't be an example of its use in the document.  The definition and 
description of alias will be there, since the working group seems to have 
accepted the need.

Yours,
Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 Jun 2005 00:06:12 -0400

I must be missing something.  For the FE LFB we have names, data types, and 
fairly good descriptions of most of the attributes.  Those were in the last 
published model draft.  They are basically the same as the ones in the FE 
Schema document, with cleanup.

The events are going to take some work.  But not an absurd amount of work.

Yours,
Joel

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 7 Jun 2005 08:42:04 -0400

> description of alias will be there, since the working group seems to have 

What about the idea of publishing a NOOP LFB that could be used as an
exercise for demonstrating the different semantics? We already had such
a LFB initially to demonstrate a few things and was used for basic
interop back in San Diego.

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Tue, 7 Jun 2005 23:44:43 +0800

Joel,

Sorry. Yes, the FE LFB has more done than the protocol LFB. I more meant the protocol LFB.  What I'm a little worried the way the LFB definition may delay the protocol lies in:

1. Some of the attributes may highly relate to other definitions, like TML definitions. This means it  tightly ties the protocol work to them,  I think we should only have a loose tie. And some attributes may be quite hard to go to the bit level definitions currently.

2. To put the attribute definitions in the protocol also limits the attributes to what we can think of currently.  The extension may become a problem. And we may also have much arguement of which attribute should be defined. 

Yes, you mentioned many protocols may run without MIBs.  Whereas I'm simply trying to see the possibility of a relation like an IP protocol with the Assigned Number, thought I'm not very sure of the idea.

thanks,
Weiming