RE: FEB BB changes impacts on FLUTE and NORM

Toni,

Ok - just to be clear, though, the FEC Schemes will define the full
encoding format but they won't actually specify that it is EXT-FTI that
is used to carry that information, because other future (non-LCT-based)
protocols might carry the same information in a different place.

Then in ALC we will define EXT-FTI and say that the OTI encoding format
defined by the FEC Scheme is carried within the EXT-FTI.

...Mark

-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Monday, September 26, 2005 11:56 AM
To: Mark Watson; [email protected]
Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM

Hello Mark,

Yes, let's go for (2) with the brief definition of the EXT_FTI header
extension type in ALC, as you propose.

That is:
- very brief declaration of the EXT_FTI header extension type in ALC
- both the generic part of EXT_FTI and Scheme-specific part defined in
"Basic FEC Schemes"

Regards, 
 Toni

> -----Original Message-----
> From: ext Mark Watson [mailto:[email protected]]
> Sent: 26 September, 2005 21:51
> To: Paila Toni (Nokia-M/Espoo); [email protected]
> Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> 
> 
> Toni,
> 
> Of these, I would go for (2), except that I would still put the
> definition of the EXT-FTI header extension type in ALC. Then the FEC
> Schemes would provide the complete details of the encoding of the
> contents of the EXT_FTI (in fact, they provide complete details of the
> encoding of the FEC OTI and then in the specific case of ALC/LCT we
> specify that EXT_FTI is used to carry this data - other 
> future protocols
> might carry it some other way).
> 
> The problem with (1), is that the generic part of the EXT-FTI includes
> the Transfer Length, which is kind of specific to fixed length object
> delivery and so it might not be appropriate to have this in ALC which
> could in future have wider application than delivery of fixed length
> objects.
> 
> The problem with (3) is that EXT-FTI is specific to a particular
> protocol (ALC/LCT) and so it's not appropriate to have it in 
> the FEC BB
> which is supposed to be protocol-independent.
> 
> So, can we agree on (2) ?
> 
> ...Mark
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] 
> Sent: Monday, September 26, 2005 11:31 AM
> To: Mark Watson; [email protected]
> Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> 
> Hello Mark,
> 
> Seems that I read your previous email too quickly...
> 
> Anyway, I prefer to have the definition of EXT_FTI not in FLUTE. The
> reason is that EXT_FTI is more widely appicable than just FLUTE. Also,
> as I said earlier, we can put this either in the "FEC BB" or 
> "Basic FEC
> Schemes" since they define the FEC issues. Under these conditions I
> would go for one of the following (first one is my favourite).
> 
> 1) generic part of EXT_FTI defined in ALC and Scheme-specific part
> defined in the FEC Schemes.
> 
> 2) both the generic part of EXT_FTI and Scheme-specific part 
> defined in
> FEC Schemes 
> 
> 3) generic part of EXT-FTI defined in FEC BB and Scheme-specific part
> defined in the FEC Schemes.
> 
> What is your view?
> 
> Regards,
>  Toni
> 
> 
> > -----Original Message-----
> > From: ext Mark Watson [mailto:[email protected]]
> > Sent: 26 September, 2005 21:21
> > To: Paila Toni (Nokia-M/Espoo); [email protected]
> > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > 
> > 
> > Hi Toni,
> > 
> > Actually, (i) and (ii) below were alternatives. So I'm not 
> sure which
> > you prefer!
> > 
> > The two options (IMO) are:
> > (i) generic part of EXT-FTI defined in FLUTE or ALC or LCT plus
> > Scheme-specific part defined in the FEC Schemes
> > 
> > OR
> > 
> > (ii) whole format defined separately in each FEC Scheme - but 
> > of course
> > the format will be aligned with the present one, so no backwards
> > compatibility issues.
> > 
> > In both cases, the ETX-FTI header extension type should be 
> defined in
> > FLUTE or ALC or LCT (tbd) as it is specific to that protocol.
> > 
> > Regards...Mark
> > 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]] 
> > Sent: Monday, September 26, 2005 10:19 AM
> > To: Mark Watson; [email protected]
> > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > 
> > Hello Mark,
> > 
> > (i) OK - let's put this into "FEC BB".
> > 
> > (ii) OK - let's put these (actually they already are) in "Basic FEC
> > Schemes" document.
> > 
> > Regards,
> >  Toni
> > 
> > > -----Original Message-----
> > > From: ext Mark Watson [mailto:[email protected]]
> > > Sent: 26 September, 2005 20:16
> > > To: Paila Toni (Nokia-M/Espoo); [email protected]
> > > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > 
> > > 
> > > Hi Toni,
> > > 
> > > Actually, right now the generic part is specified in FLUTE, 
> > so moving
> > > that to the FEC BB would broaden its applicability to 
> > protocols other
> > > than FLUTE and even protocols which used some other container than
> > > EXT-FTI for this information.
> > > 
> > > So, I would prefer that either (i) the generic part is 
> > > defined wherever
> > > the EXT-FTI header extension code is defined - which should 
> > be FLUTE,
> > > ALC or LCT or (ii) there is no generic part and each FEC 
> > > Scheme defines
> > > its own format (accepting that for the existing schemes, the 
> > > first bytes
> > > of the formats will all look the same).
> > > 
> > > ...Mark
> > > 
> > > 
> > > 
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]] 
> > > Sent: Monday, September 26, 2005 9:51 AM
> > > To: Mark Watson; [email protected]
> > > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > 
> > > Hi Mark,
> > > 
> > > > What I was proposing (in fact I thought it was what you were 
> > > > proposing) is that the whole contents of the EXT-FTI should 
> > > > be defined by each FEC scheme, even if the the existing 
> > > > schemes it will always start the same way with the transfer 
> > > > length and FEC instance Id.
> > > 
> > > Splitting the definition between "FEC BB" and "Basic FEC 
> > > Schemes" is OK
> > > to me. I'm only concerned about maintaining the existing 
> > > definitions as
> > > they are, outside FLUTE.
> > > 
> > > Is is OK if you specify the generic EXT_FTI part in "FEC 
> BB" and the
> > > individual encodings (or endings) in the "Basic FEC Schemes"?
> > > 
> > > Regards,
> > >  Toni
> > > 
> > > > -----Original Message-----
> > > > From: ext Mark Watson [mailto:[email protected]]
> > > > Sent: 26 September, 2005 18:50
> > > > To: Paila Toni (Nokia-M/Espoo); [email protected]
> > > > Subject: Re: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > > 
> > > > 
> > > > Hi Toni,
> > > > 
> > > > Yes, your summaries are correct, except that presently in the 
> > > > new FEC BB and FEC schemes, the EXT_FTI is split into two 
> > > > parts: a generic part containing transfer length and FEC 
> > > > instance Id, and .a part specific to each FEC scheme. The 
> > > > generic part is defined in FLUTE and the rest in each 
> FEC scheme.
> > > > 
> > > > What I was proposing (in fact I thought it was what you were 
> > > > proposing) is that the whole contents of the EXT-FTI should 
> > > > be defined by each FEC scheme, even if the the existing 
> > > > schemes it will always start the same way with the transfer 
> > > > length and FEC instance Id.
> > > > 
> > > > ...mark
> > > > -----Original Message-----
> > > > From: <[email protected]>
> > > > Date: Mon, 26 Sep 2005 08:20:45 
> > > > To:<[email protected]>
> > > > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > > 
> > > > Hello Mark,
> > > >  
> > > >  Thank you for good and detailed comments. I'm sorry for my 
> > > > late response. Last week I was traveling. Please find my 
> > > > comments inline.
> > > >  
> > > >  Regards,
> > > >   Toni
> > > >  
> > > >  > -----Original Message-----
> > > >  > From: ext Mark Watson [mailto:[email protected]]
> > > >  > Sent: 16 September, 2005 11:09
> > > >  > To: Paila Toni (Nokia-M/Espoo); [email protected]; Walsh Rod
> > > >  > (Nokia-NRC/Tampere); [email protected];
> > > >  > [email protected]; [email protected]
> > > >  > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > >  >
> > > >  >
> > > >  > Hi Toni,
> > > >  >
> > > >  > In the currently proposed set of drafts, then the 
> > > definition of the
> > > >  > contents of the EXT_FTI is split between FLUTE and the 
> > FEC Scheme
> > > >  > specifications. As before, FLUTE specifies that the 
> > > EXT-FTI always
> > > >  > starts with the Transfer Length and FEC Instance ID. Then 
> > > > the rest of
> > > >  > the contents depend on the FEC Scheme and the only change 
> > > > is that the
> > > >  > description of this is moved from FLUTE to the FEC Scheme
> > > >  > specifications. This was all deliberate - no luck 
> involved ;-)
> > > >  >
> > > >  
> > > >  Maybe we should then rename the updated RFC as FLUKE :)
> > > >  
> > > >  > The encodings are not mis-aligned - what is specified in the
> > > >  > new set of
> > > >  > drafts is backwards-compatible with what is in the old 
> > > > ones (assuming
> > > >  > the new FLUTE draft still defines the common part of 
> > the EXT-FTI
> > > >  > containing the Transfer Length and FEC Instance ID).
> > > >  >
> > > >  
> > > >  Yes. Maintaining the backwards compability in defining the 
> > > > encodings is very important.
> > > >  
> > > >  > But I think your proposals move towards a cleaner 
> split of the
> > > >  > description: FLUTE would not define anything about the
> > > >  > *contents* of the
> > > >  > EXT-FTI and would defer to the FEC Scheme definitions for 
> > > > that part.
> > > >  > Remember that there may be many more FEC Schemes in future
> > > >  > and each may
> > > >  > define a different format for the contents of the 
> > > EXT-FTI so FLUTE
> > > >  > should not refer to any particular FEC Schemes draft. Instead
> > > >  > you should
> > > >  > refer to the FEC BB e.g. The contents of the EXT-FTI 
> LCT header
> > > >  > extension are defined by the FEC Scheme as described in 
> > > [FEC BB].)
> > > >  >
> > > >  
> > > >  Let me try to understand this. Your proposal is to include 
> > > > the basic specification of EXT_FTI in [FEC BB]. That would 
> > > > mean more or less copy-pasting the first part of section 5.1 
> > > > and section 5.1.1. of FLUTE in [FEC BB]. Did I understand it 
> > > > right? If so, this sounds an excellent idea. Could you go 
> > > > forward and make the needed changes in [FEC BB]?
> > > >  
> > > >  > We would then amend the FEC Schemes draft to define the full
> > > >  > contents of
> > > >  > the EXT-FTI for each scheme. Note that I would not 
> > > mention EXT-FTI
> > > >  > explicitly in the FEC Schemes, but rather say that the 
> > > FEC Schemes
> > > >  > provide an encoding for the OTI and Content Delivery
> > > >  > Protocols (of which
> > > >  > FLUTE is only one example) provide a place to carry this 
> > > > encoding. In
> > > >  > the case of FLUTE it is the EXT-FTI but in the case of 
> > > > other protocols
> > > >  > it could be somewhere else.
> > > >  >
> > > >  
> > > >  Again, let me restate what you say. The encodings in FLUTE 
> > > > section 5.1.2 would be then included in Basic Forward Error 
> > > > Correction (FEC) Schemes 
> > > > [draft-ietf-rmt-bb-fec-basic-schemes-revised-00]. Actually, 
> > > > as you said before - they already are. Did I get it right?
> > > >  
> > > >  > I can make the necessary changes to the FEC BB and FEC 
> > > > Schemes drafts
> > > >  > (we should probably review the set { FEC BB, FEC 
> > Scheme, FLUTE }
> > > >  > off-line to get them consistently joined together on this 
> > > > issue before
> > > >  > submitting revised versions.)
> > > >  >
> > > >  
> > > >  Let's do it! The authors of FLUTE are putting FLUTEbis 
> > > > together. Based on the discussion and agreement on the split 
> > > > of specifications, we will remove section 5.1 altogether from 
> > > > FLUTE. We will also do necessary changes in the beginning of 
> > > > chapter 5 to accommodate this and add [FEC BB] and 
> > > > [draft-ietf-rmt-bb-fec-basic-schemes-revised-00] as 
> > > > references. Or, would [FEB BB] be enough?
> > > >  
> > > >  > The remaining issue is where the EXT-FTI LCT Header Extension
> > > >  > Type value
> > > >  > should be defined. Presently I think it is in FLUTE, but 
> > > perhaps it
> > > >  > should be moved to LCT ?? The LCT update should probable 
> > > include a
> > > >  > registry for LCT Header Extensions as well - any 
> > opinions on the
> > > >  > allocation rules ??
> > > >  >
> > > >  
> > > >  I think we can do this in [FEB BB].
> > > >  
> > > >  > Regards,
> > > >  >
> > > >  > Mark
> > > >  >
> > > >  > -----Original Message-----
> > > >  > From: [email protected] [mailto:[email protected]]
> > > >  > Sent: Thursday, September 15, 2005 10:59 PM
> > > >  > To: Mark Watson; [email protected]; [email protected];
> > > >  > [email protected]; [email protected];
> > > >  > [email protected]
> > > >  > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > >  >
> > > >  > Hello Mark,
> > > >  >
> > > >  > Please find my answers inline.
> > > >  >
> > > >  > > -----Original Message-----
> > > >  > > From: ext Mark Watson [mailto:[email protected]]
> > > >  > > Sent: 15 September, 2005 16:00
> > > >  > > To: Paila Toni (Nokia-M/Espoo); [email protected]; Walsh Rod
> > > >  > > (Nokia-NRC/Tampere); [email protected];
> > > >  > > [email protected]; [email protected]
> > > >  > > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > >  > >
> > > >  > >
> > > >  > > Toni,
> > > >  > >
> > > >  > > Regarding EXT_FTI, do you mean that the whole EXT_FTI
> > > >  > > definition should
> > > >  > > be in the FEC-BB ? This would be strange since the EXT-FTI
> > > >  > is specific
> > > >  > > to LCT (it being an LCT Header Extension) and the FEC-BB is
> > > >  > > not specific
> > > >  > > to any particular protocols. I think we could define the
> > > >  > > encoding format
> > > >  > > for the contents of the EXT-FTI in the FEC BB, and 
> FLUTE (or
> > > >  > > LCT) would
> > > >  > > need to define that the EXT_FTI LCT Header Extension could
> > > >  > be used to
> > > >  > > carry that.
> > > >  > >
> > > >  >
> > > >  > If I understand your proposal, you would like to 
> > specify the core
> > > >  > concepts of FEC in FEC BB without going to details. Then you
> > > >  > would like
> > > >  > to have FLUTE just use the concepts by referring to the
> > > >  > specification of
> > > >  > EXT_FTI. Yes, that sounds what I was trying to explain. 
> > > > Now the only
> > > >  > missing link is the place where EXT_FTI is specified. I 
> > > believe you
> > > >  > explain it in the following:
> > > >  >
> > > >  > > 5.1.2.1 and 5.1.2.2 contain FEC-scheme specific 
> > > > information and so
> > > >  > > should not be in FLUTE. The proposal is not to discard
> > > >  > these sections
> > > >  > > but to include them in the definitions of those FEC 
> > > Schemes (see
> > > >  > > draft-ietf-rmt-bb-fec-basic-schemes-00). Btw, we should
> > > >  > probably Last
> > > >  > > Call that draft as well - it just collects together the 
> > > > previously
> > > >  > > existing material on these FEC Schemes in one place and 
> > > > makes them
> > > >  > > compliant to the new FEC BB.
> > > >  > >
> > > >  >
> > > >  > I think this is a good idea. However, before going that 
> > > way, let me
> > > >  > clarify a two of things:
> > > >  >
> > > >  > 1)
> > > >  > What is the source of the Figure 2 and Figure 5 in
> > > >  > (draft-ietf-rmt-bb-fec-basic-schemes-00)? I.e., where are 
> > > > they coming
> > > >  > from? Why I ask this question is that we already have 
> > > > almost identical
> > > >  > figures in RFC 3926 section 5.1.2.1 (similar to Figure 2) 
> > > > and section
> > > >  > 5.1.2.2 (similar to Figure 5). What is the reason you did not
> > > >  > use those
> > > >  > encodings?
> > > >  >
> > > >  > 2)
> > > >  > As far I see (draft-ietf-rmt-bb-fec-basic-schemes-00) 
> > > does not yet
> > > >  > provide encodings for Transfer-Lenght and FEC Instance ID 
> > > > (in case of
> > > >  > underspecified schemes). Fortunately, RFC 3926 has defined
> > > >  > these as well
> > > >  > - please see section 5.1.1.
> > > >  >
> > > >  > My conclusion is that if we want to remove the EXT_FTI 
> > > > from FLUTE, the
> > > >  > cleanest way to do it is to have the spec text in
> > > >  > (draft-ietf-rmt-bb-fec-basic-schemes-00). Further, since 
> > > > that document
> > > >  > currenly has slighly misaligned encodings for FEC 
> > information and
> > > >  > missing encodings for some common pieces, 
> > complementing document
> > > >  > (draft-ietf-rmt-bb-fec-basic-schemes-00) with the relevant
> > > >  > section 5.1.1
> > > >  > of RFC 3926 is needed.
> > > >  >
> > > >  > Consequently I will remove the EXT_FTI definitions from
> > > >  > section 5.1 and
> > > >  > clean up the section so that it only refers to
> > > >  > (draft-ietf-rmt-bb-fec-basic-schemes-00) for the 
> > specification of
> > > >  > EXT_FTI.
> > > >  >
> > > >  > What do you think?
> > > >  >
> > > >  > Regards,
> > > >  >  Toni
> > > >  >
> > > >  > > Regards...Mark
> > > >  > >
> > > >  > > -----Original Message-----
> > > >  > > From: [email protected] [mailto:[email protected]]
> > > >  > > Sent: Thursday, September 15, 2005 12:06 PM
> > > >  > > To: Mark Watson; [email protected]; [email protected];
> > > >  > > [email protected]; [email protected];
> > > >  > > [email protected]
> > > >  > > Subject: RE: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > >  > >
> > > >  > > Dear Mark, FLUTE authors and all,
> > > >  > >
> > > >  > > Doing the FLUTEbis work it occurred to me that the 
> > > > current FLUTE RFC
> > > >  > > contains something that has wider applicability than FLUTE
> > > >  > > itself. What
> > > >  > > I mean is the specification for EXT_FTI. My proposal is 
> > > > to move the
> > > >  > > section 5.1 Use of EXT_FTI for delivery of FEC Object 
> > > > Transmission
> > > >  > > Information of RFC 3926 to the 
> > to-be-proposed-standard FEC BB.
> > > >  > > Investigating the case, I found that section 5.1 
> is specified
> > > >  > > in a clean
> > > >  > > way - i.e., it can be nicely separated from FLUTE, 
> shifted to
> > > >  > > FEC BB and
> > > >  > > then referenced from FLUTE.
> > > >  > >
> > > >  > > Actually this is pretty much in line with your comment 2)
> > > >  > below. Only
> > > >  > > thing I do not agree is the dropping of specific sections
> > > >  > 5.1.2.1 and
> > > >  > > 5.1.2.2. Dropping the sections makes the specification 
> > > > weaker as it
> > > >  > > leaves these essential details unspecified.
> > > >  > >
> > > >  > > What do you think?
> > > >  > >
> > > >  > > Please consider this as my formal comment in the FEC BB 
> > > > last call.
> > > >  > >
> > > >  > > Regards,
> > > >  > >  Toni
> > > >  > >
> > > >  > > -----Original Message-----
> > > >  > > From: [email protected] [mailto:[email protected]]On
> > > >  > > Behalf Of ext
> > > >  > > Mark Watson
> > > >  > > Sent: 02 August, 2005 12:39
> > > >  > > To: [email protected]; Walsh Rod (Nokia-NRC/Tampere);
> > > >  > > [email protected]
> > > >  > > Subject: [Rmt] FEB BB changes impacts on FLUTE and NORM
> > > >  > >
> > > >  > >
> > > >  > >
> > > >  > > All,
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > I was asked at the RMT session yesterday to summarise the
> > > >  > > impacts on the
> > > >  > > RMT protocols which use the FEC Building Block of the
> > > >  > changes proposed
> > > >  > > in the FEC BB
> > > >  > > 
> > (http://www.ietf.org/internet-drafts/draft-ietf-rmt-fec-bb-rev
> > > >  > > ised-00.tx
> > > >  > > t). The requirements on Content Delivery Protocols are
> > > >  > > explicitly listed
> > > >  > > in Section 8 of the FEC BB, so the task is really to 
> > > > bring FLUTE and
> > > >  > > NORM into compliance with that section, without introducing
> > > >  > backwards
> > > >  > > compatibility issues.
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > From a quick review I have come up with the following:
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > FLUTE:
> > > >  > >
> > > >  > > 1)     The FDT Schema needs updating to provide 
> > support for FEC
> > > >  > > Scheme-specific Object Transmission Information, for
> > > >  > example using the
> > > >  > > FEC-OTI-Scheme-Specific-Info attribute defined in Section
> > > >  > > 7.2.10 of 3GPP
> > > >  > > TS26.346 6.1.0 (
> > > >  > >
> > > >  > 
> > > > 
> > > 
> > 
> http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-610.zip)
> > > >  > >
> > > >  > > 2)     The FEC Encoding ID specific portion of the 
> > > > EXT-FTI should no
> > > >  > > longer be defined in FLUTE except to say that it consists
> > > >  > of (a subset
> > > >  > > of) the Common FEC OTI elements (except the Transfer 
> > > > Length which is
> > > >  > > included in the FLUTE General EXT-FTI portion) followed by
> > > >  > > (optionally)
> > > >  > > the Scheme-Specific FEC OTI element the encoding formats of
> > > >  > which are
> > > >  > > defined by the FEC Scheme. As a result, the following 
> > > changes are
> > > >  > > needed:
> > > >  > >
> > > >  > > a.      Remove section 5.1.2
> > > >  > >
> > > >  > > b.      Modify the text on the FEC Encoding ID Specific
> > > >  > > Format in 5.1.1
> > > >  > > according to the above
> > > >  > >
> > > >  > > 3)     The algorithm for computing source block 
> > > > structure should be
> > > >  > > removed - this is in 5.1.2.2, so removing 5.1.2 as 
> > > > suggested in 2(a)
> > > >  > > above achieves this.
> > > >  > >
> > > >  > > 4)     The description of the use of FDT for signaling the
> > > >  > FEC OTI in
> > > >  > > Section 5.2 needs modification to remove references to 
> > > > specific FEC
> > > >  > > Encoding IDs and instead reference the Common FEC 
> OTI Element
> > > >  > > descriptions in the FEC Building Block. It should also be
> > > >  > > mentioned that
> > > >  > > the value range for each of these Common elements is
> > > >  > specified by the
> > > >  > > FEC Scheme.
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > NORM:
> > > >  > >
> > > >  > > 1)     Most of the references to specific FEC Encoding ID
> > > >  > > values in the
> > > >  > > NORM protocol are examples, so it would not be strictly 
> > > > necessary to
> > > >  > > remove or modify these. But we could consider (for example)
> > > >  > whether it
> > > >  > > would be clearer to replace the description in 4.2.1 of the
> > > >  > > FEC Payload
> > > >  > > ID for the Small Block Systematic FEC Scheme with 
> a reference
> > > >  > > to the FEC
> > > >  > > Schemes document.
> > > >  > >
> > > >  > > 2)     Likewise, the EXT-FTI format is given as an example.
> > > >  > > However, it
> > > >  > > probably is necessary to specify the 'skeleton' EXT-FTI 
> > > > format - at
> > > >  > > least to include the FEC Instance ID since it is a 
> > > Mandatory OTI
> > > >  > > element. At the moment I think it is assumed, although 
> > > > not explicit,
> > > >  > > that the EXT-FTI format for NORM is the same as that for
> > > >  > FLUTE and so
> > > >  > > perhaps a reference to FLUTE would be appropriate ?
> > > >  > >
> > > >  > > 3)     The FEC Building Block does not require that each
> > > >  > > packet of data
> > > >  > > contains only a single Encoding Symbol, wheras this 
> > > > requirement is
> > > >  > > included in NORM section 5.1.1 - of course this can be
> > > >  > > resolved by just
> > > >  > > defining the term 'symbol' differently in the context of 
> > > > NORM vs the
> > > >  > > context of a particular FEC Scheme - but this can lead 
> > > > to confusion.
> > > >  > >
> > > >  > > 4)     NORM defines an object partitioning algorithm, in 
> > > > contrast to
> > > >  > > FLUTE, which just recommended one, I think. The new FEC BB
> > > >  > defines an
> > > >  > > algorithm (which I believe to be the same, but 
> others should
> > > >  > > check!) and
> > > >  > > the FEC Schemes document requires that it be used for the
> > > >  > FEC schemes
> > > >  > > defined there. So, I am unsure whether this should 
> be removed
> > > >  > > from NORM
> > > >  > > and deferred to the FEC Scheme specifications or whether 
> > > > NORM should
> > > >  > > refer to the FEC BB and require the same algorithm for all
> > > >  > > FEC Schemes -
> > > >  > > I would prefer the former, since the way the input 
> > > parameters are
> > > >  > > calculated (particular the number of symbols per packet) 
> > > > may be FEC
> > > >  > > Scheme-specific.
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > One potentially confusing point that I noticed is that the
> > > >  > new FEC BB
> > > >  > > proposal requires CDP specification to define Means 
> > to reliably
> > > >  > > communicate the Common FEC Object Transmission Information
> > > >  > > element from
> > > >  > > sender to receiver(s) using either or both of (a) 
> > > > encoding formats
> > > >  > > defined by the FEC Scheme or (b) encoding formats defined
> > > >  > by the CDP
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > (This should say 'elements' not 'element' in the 
> second line)
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > The confusing point is that FLUTE will need to treat the
> > > >  > > Transfer Length
> > > >  > > differently from the other Common OTI elements, since FLUTE
> > > >  > defines a
> > > >  > > single format for the Transfer Length in the general 
> > > > portion of the
> > > >  > > EXT-FTI - we can't make the length of this field 
> > > > FEC-scheme specific
> > > >  > > since it is before the FEC Instance ID. i.e. FLUTE defines
> > > >  > > both (a) and
> > > >  > > (b) above for the Common FEC OTI elements with the 
> exception
> > > >  > > of Transfer
> > > >  > > Length, where is defines (b) only.
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > We could consider whether Transfer Length should be one of
> > > >  > > the Mandatory
> > > >  > > FEC OTI elements, rather than a Common one.
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > Regards,
> > > >  > >
> > > >  > > 
> > > >  > >
> > > >  > > Mark
> > > >  > >
> > > >  > >
> > > >  >
> > > >  
> > > >  
> > > > Sent from my BlackBerry.
> > > > 
> > > 
> > 
>