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

["Luby, Michael" <[e-mail]>]

Vincent,
You are welcome.  Responses below.
Best, Mike

On 10/17/12 4:59 AM, "Vincent Roca" <[e-mail]> wrote:

>Mike,
>
>Thanks for your feedback.
>
>>> (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.
>
>I have no doubt that an implementer will find its way in RFC5170 and
>identify
>what needs to be used. With the further restriction of having G=1, the
>specifications of RFC5170 become fairly small (~14 technical pages,
>pseudo-code
>included) and easy to understand IMHO.
>
>We are not planning to change anything here unless the IESG asks us to do
>so.

*** The above suggestions I made are clarifying comments, and if they
aren't incorporated it only means that the spec is a little less easy to
understand and implement, it isn't earth shattering.


>
>
>>> (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.
>
>This list is not intended to be exhaustive. No other FEC scheme tries to
>provide
>an exhaustive list: RFC5053 (Raptor) does not reference any other FEC
>scheme,
>and RFC6330 (RaptorQ) / RFC6681 (Raptor(Q) for FECFRAME) only reference
>Raptor.

*** Ok.  However, the difference is that RFC 5053 and RFC 6330 and RFC
6681 don't have any survey like comparisons to other FEC technology
(except that of course the 6330 does have text to justify its existence
vis a vis 5053), whereas this specification does seems to try and make
some comparisons to other technologies out there.  Its ok as is, just
means it isn't quite as good of a comparison list as it could have been
given that a comparison survey is included at all.  The other option of
course would have been not to have such comparisons to other FEC within
the document at all, which is the path that 5053 and 6330 take.
>
>
>More importantly. Since:
>
>1- you noticed we impose restrictions on the way LDPC-Staircase codes are
>  being used in section 4.1;
>
>2- you certainly remember the discussion we had in 2009 concerning 10 out
>  of the 13 patents mentioned in the RFC5170 IPR disclosure, whose
>conclusion
>  is here:
>	http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html
>
>3- the present I-D only considers LDPC-Staircase codes whereas RFC5170
>   defines two FEC schemes;
>
>you will probably conclude like us that QC's IPR disclosure for RFC5170
>does
>not necessarily apply to this I-D. Hence our question: does QC intend to
>do
>a new IPR disclosure? When?

*** This specification inherits technology from RFC 5170, and we have made
IPR declarations with regards to RFC 5170.  As far as I know, we do not
plan to make any further IPR declarations on this specification.
>
>
>Regards,
>
>
>    Vincent, on behalf of the authors
>
>
>NB: I'm adding Stephen Farrell who first identified the IPR disclosure
>question
>during IESG review.
>