Hi,
I have the following comments on the content of this draft.
I also included some suggestions for improvement where appropriate.
Your comments and opinions are requested on these issues.
--------Comment-1-------
Section-1
Do the CDPs mentioned in this draft include only file delivery protocols like FLUTE or do they also include CDPs like "MBMS streaming framework"?
Please give examples of CDP. e.g., FLUTE, MBMS Streaming framework etc.
--------Comment-2-------
Section-6.1
"The value of the FEC Encoding ID MUST be the same for all transmission of encoding symbols related to a particular object,"
Why did you impose this restriction?
This restriction prevents a sender from using different FEC schemes for different transmissions of the encoding symbols.
For example, a server may wish to use no FEC in the first transmission, it may wish to use some FEC in the second transmission.
--------Comment-3-------
"An already defined Under-Specified FEC Scheme (i.e. FEC Encoding ID value) MUST be reused if the associated FEC Payload ID and FEC Object Transmission Information have the required fields and encoding formats for a new Under-Specified FEC scheme instance."
Please give an example. What is the motivation behind this restriction?
--------Comment-4-------
Section-7
" 2. The type, semantics and encoding format of one or two FEC Payload IDs.
Where two FEC Payload ID formats are specified, then the FEC scheme MUST be a systematic FEC code and one FEC Payload ID format MUST be designated for use with packets carrying only source symbols and the other FEC Payload ID format MUST be designated for use with packets carrying at least one repair symbol."
There can be more than two FEC Payload IDs defined by some FEC schemes.
When two FEC Payload IDs are specified, they may not necessarily strictly correspond to "source packets" and "repair packets".
So I propose to change the "MUST" to "MAY" in the above sentence. What do you think?
Thank you,
Ramakrishna Vedantham
Nokia Research Center
----------------------------------------------------------------------
Nokia | Phone +1-972-374-1922
6000 Connection Dr, | Fax +1-972-894-5937
Irving, TX 75039, USA | mailto: [email protected]
www.nokia.com/openness
----------------------------------------------------------------------
-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of ext
Lorenzo Vicisano
Sent: Monday, September 12, 2005 1:36 AM
To: [email protected]
Subject: Re: [Rmt] draft-ietf-rmt-fec-bb-revised-01 WG Last-Call
Correcting my own typo: the deadline is Monday September 26th,
not 27th.
thank you,
Lorenzo
On Sun, Sep 11, 2005 at 11:14:36PM -0700, Lorenzo Vicisano wrote:
> Please be advised that this email starts RMT working group
> last-call for draft-ietf-rmt-fec-bb-revised-01.
>
> Please provide your comments by Monday September 27th, if
> any.
>
> Additional notes:
>
> draft-ietf-rmt-fec-bb-revised-01 is a revision of RFC 3452, FEC
> Building Block, intended to obsolete RFC 3452 and to move the FEC BB to
> the Standard Track category. Please note that, although this building
> block specification might not be fully backward compatible with RFC
> 3452, the overall revision process of RMT Experimental RFCs strives to
> produce backward-compatible protocol instantiations.
>
> thank you,
> Lorenzo Vicisano
>
> _______________________________________________
> Rmt mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmt
_______________________________________________
Rmt mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rmt
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.