Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI Teleconference,Tuesday 4th

From: "Yang, Lily L" <[email-masked]>
Date: Wed, 5 Nov 2003 10:57:35 -0800

Yes. And as it stands today, the data model is still a bit "fluid" but it will firm up over time :-)

> -----Original Message-----
> From: Forwarding and Control Element Separation
> [mailto:[email-masked]]On Behalf Of Alex Audu
> Sent: Wednesday, November 05, 2003 10:48 AM
> To: [email-masked]
> Subject: Re: [NPF-SW-FAPI] RE: [NPF-SOFTWARE] Reminder: FAPI
> Teleconference,Tuesday 4th
> 
> 
> And the ForCES protocol depends on a firm data model to 
> derive byte-by-byte
> organization of the objects representative of the LFBs' data.
> 
> Alex.
> 
> "Yang, Lily L" wrote:
> 
> > John -- First of all, I want to thank you for the comments. 
> It is good to finally see some concrete feedback on the FE 
> model draft. Thanks to Alan for forwarding this to ForCES 
> mailing list, otherwise I won't even see it.
> > I believe Alan has answered most of your questions. Just 
> one comment about the questions you raised regarding data 
> type (as shown following). It is my understanding that the FE 
> model defines the logical data structure but not the 
> byte-by-byte organization. The byte-by-byte encoding of such 
> data structure will be defined by the ForCES protocol instead.
> >
> > Lily
> >
> > >
> > > > 2. Section 4.1.2 talks about "Structures."  Are they like 'C'
> > > > structures, whose layout in memory can be compiler-dependent,
> > > > or are they meant to specify a machine-independent layout in
> > > > memory or in a PDU?  This doesn't seem to be clear.
> > >
> > >
> > >
> > > >  How are
> > > > they to be used?  If their only purpose is to give names and
> > > > limits to data elements in the abstract, and not to specify
> > > > byte-by-byte organization, that makes sense and I'm fine
> > > > with it.
> > >
> >
>