Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt

[Martin Stiemerling <[e-mail]>]

Hi Michael,

On 10/17/2012 03:24 PM, Luby, Michael wrote:
> Hi Martin,
> Comments below.
> Best, Mike
>
> On 10/17/12 2:13 AM, "Martin Stiemerling" <[e-mail]>
> wrote:
>
>> Hi Michael, all,
>>
>> Thanks for your comments, but I would have wished to see them either
>> during the WG Last Call or latest during IETF LC.
> ***  My comments aren't crucial, and it seems they are going to be ignored
> anyway.  I wish I had time to look at it earlier, but I didn't.  They are
> clarifying comments, and if they aren't incorporated it only means that
> the spec is a little less easy to understand, it isn't earth shattering.

Ok, thanks.

>>
>> Anyhow, apart from the timing, the questions are probably good to be
>> discussed. Especially, as there are IPR declarations for RFC 5170.
> *** I don't understand this comment, as there were no IPR-related comments
> in my feedback.

This is solely meant for discussion and to get any questions resolved. 
We have had some discussion during the IESG evaluation if IPR declared 
for RFC 5170 is also valid for draft-ietf-fecframe-ldpc. Thus the 
linkage between your email and what has happened in the IESG.

This is not out of a bad intention, but it is more your AD which wanted 
some more clarity on this.

Thank you,

   Martin

>>
>> Any feedback from the WG?
>>
>> Thanks,
>>
>>    Martin
>>
>> --
>> IETF Transport Area Director
>>
>> [e-mail]
>>
>> NEC Laboratories Europe - Network Research Division NEC Europe Limited
>> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
>> Registered in England 283
>>
>>
>> On 10/11/2012 08:23 PM, Luby, Michael wrote:
>>> Some quick comments.
>>>
>>> (1) This proposal relies upon parts of RFC 5170 for the definition of
>>> the
>>> underlying LDPC staircase code.  However, it isn't completely explicit
>>> in
>>> this proposal about what exact parts/sections of RFC 5170 are to be used
>>> in this proposal and how.  It would seem that explicit references to the
>>> particular sections of RFC 5170 that are being used, and exactly how
>>> these
>>> parts of RFC 5170 are being inherited and used, would be useful
>>> (probably
>>> necessary).  Note that there are several codes with different FEC
>>> encoding
>>> IDs defined in RFC 5170, so making exact references to which parts are
>>> used
>>> and how is important.  An example of how this is not at all precisely
>>> defined:
>>>
>>> 	Because of the requirement to have exactly one encoding symbol per
>>> 	group, i.e., because G MUST be equal to 1 (Section 4.1
>>> <http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04#section-4.1>),
>>> several
>>> 	parts of [RFC5170 <http://tools.ietf.org/html/rfc5170>] are useless.
>>> In
>>> particular, this is the case of
>>> 	Section 5.6
>>> <http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04#section-5.6>.
>>> "Identifying the G Symbols of an Encoding Symbol
>>> 	Group".
>>>
>>> This snippet above that says several parts of RFC 5170 are useless (very
>>> vague), and it seems instead it should explicitly state what
>>> parts are to be used and exactly how.  It provides one example of
>>> something that is not is to be used from RFC 5170, but it seems that
>>> it should be the other way around, stating explicitly what should be
>>> used
>>> and how.
>>>
>>>
>>> (2) This proposal references RFC 5170 and RFC 5053, and makes some
>>> comparisons.  However, there is also RFC 6330 that is relevant and is
>>> not
>>> mentioned or referenced in this proposal.  It would seem appropriate to
>>> do
>>> so.
>>>
>>> Thanks, Mike
>>>
>>>
>>>
>>> On 10/9/12 6:22 AM, "[e-mail]"
>>> <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>> This draft is a work item of the FEC Framework Working Group of the
>>>> IETF.
>>>>
>>>> 	Title           : Simple LDPC-Staircase Forward Error Correction (FEC)
>>>> Scheme for FECFRAME
>>>> 	Author(s)       : Vincent Roca
>>>>                            Mathieu Cunche
>>>>                            Jerome Lacan
>>>> 	Filename        : draft-ietf-fecframe-ldpc-04.txt
>>>> 	Pages           : 22
>>>> 	Date            : 2012-10-09
>>>>
>>>> Abstract:
>>>>     This document describes a fully-specified simple FEC scheme for
>>>> LDPC-
>>>>     Staircase codes that can be used to protect media streams along the
>>>>     lines defined by the FECFRAME framework.  These codes have many
>>>>     interesting properties: they are systematic codes, they perform
>>>> close
>>>>     to ideal codes in many use-cases and they also feature very high
>>>>     encoding and decoding throughputs.  LDPC-Staircase codes are
>>>>     therefore a good solution to protect a single high bitrate source
>>>>     flow, or to protect globally several mid-rate flows within a single
>>>>     FECFRAME instance.  They are also a good solution whenever the
>>>>     processing load of a software encoder or decoder must be kept to a
>>>>     minimum.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc
>>>>
>>>> There's also a htmlized version available at:
>>>> http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04
>>>>
>>>> A diff from the previous version is available at:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-fecframe-ldpc-04
>>>>
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> Fecframe mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/fecframe
>>>
>>> _______________________________________________
>>> Fecframe mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/fecframe
>>>
>>
>

-- 
[e-mail]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283