Re: [FECFRAME-PROTO] Comments to draft-ietf-fecframe-framework-01.txt

Hi Mark,

While we agreed in our last meeting to come up with new terms (wrt CDP
etc.) that suit the architecture a bit better, we should close on it
next week, if we get the chance. 

Let me know if I could clarify any of the comments below as well.

Cheers,
Rajiv 

> -----Original Message-----
> From: fecframe-proto-bounces@ietf.org 
> [mailto:fecframe-proto-bounces@ietf.org] On Behalf Of Rajiv 
> Asati (rajiva)
> Sent: Sunday, February 17, 2008 9:27 PM
> To: fecframe-proto@ietf.org
> Subject: [FECFRAME-PROTO] Comments to 
> draft-ietf-fecframe-framework-01.txt
> 
> Hi Mark,
> 
> While working on the signaling draft, I reviewed the 
> framework-01 draft
> a bit carefully, and got the following (minor) comments for our
> consideration -
> 
> ~~~~~~~~~~
> 1) Section 1- Introduction
> .....It is expected that any complete content delivery protocol
> specification which makes use of this framework will address these
> signalling requirement(s).
> 
> TO
> .....It is expected that any complete content delivery protocol
> specification which makes use of this framework will also 
> make use of a
> signalling protocol to satisfy signalling requirement(s). The 
> signalling
> protocol is part of the FEC framework.
> 
> 
> 2) Section 4- Architecture Overview
> .....The FEC framework does not define how the FEC framework
> configuration information for the stream is communicated from 
> sender to
> receiver. This must be defined by any content delivery protocol
> specification as described in the following section.
> 
> TO
> .....The FEC framework defines the usage of any signaling protocol by
> which FEC framework configuration information for the stream is
> communicated from sender to receiver. This must be adopted by any
> content delivery protocol specification making use of the FEC 
> Framework.
> 
> 3) Section 6- Protocol Overview
> Change the title to "Building Block Overview", since Protocol doesn't
> quite convey what protocol it is.
> 
> 4) Section 2- Terminology
> 
> 4.1 - Clarify the definition of 'Source Payload ID' and 
> 'Repair Payload
> ID' a bit more. For example, Repair FEC Payload ID -- A FEC Payload ID
> to identify the source block and the mapping between the contained
> repair data and the original source block. Source Payload ID -- A FEC
> Payload ID to identify the mapping of source packet(s) with a source
> block.
> 
> 4.2 - Add definition for "Restoration Window" (based on last 
> meeting) as
> well as "instance" (which is used heavily in SDP Elements draft).
> We are freely interchanging stream and flow terms. Need to define them
> and use them appropriately.  Suggest to stick with Flow.
> 
> 5) Section 6 - Protocol Specification
> Are 'Source FEC Payload ID' and 'Repair Payload ID' conveyed by sender
> to receiver using the singaling protocol? Are they the same? Not clear
> in 6.1, 6.2 and 6.3.
> 
> 6) Section 6.5 - Why is FEC Framework Instance not a mandatory info
> The configuration information is to be formulated for each 
> FEC framework
> instance. Hence, we should mandatorily include the "instance"
> identifier, if not already.
> ~~~~~~~~~~~~~~
> 
> Cheers,
> Rajiv
> _______________________________________________
> FECFRAME-PROTO mailing list
> FECFRAME-PROTO@ietf.org
> http://www.ietf.org/mailman/listinfo/fecframe-proto
> 
_______________________________________________
FECFRAME-PROTO mailing list
FECFRAME-PROTO@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe-proto