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

Vincent Roca <> Wed, 17 October 2012 11:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2222521F8789 for <>; Wed, 17 Oct 2012 04:59:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.405
X-Spam-Status: No, score=-110.405 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id scF+W+3U8cQt for <>; Wed, 17 Oct 2012 04:59:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3DAA121F8786 for <>; Wed, 17 Oct 2012 04:59:34 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,600,1344204000"; d="scan'208";a="177612031"
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 17 Oct 2012 13:59:33 +0200
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Vincent Roca <>
In-Reply-To: <>
Date: Wed, 17 Oct 2012 13:59:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: "Luby, Michael" <>
X-Mailer: Apple Mail (2.1085)
Cc: Mathieu Cunche <>, =?iso-8859-1?Q?J=E9r=F4me_Lacan?= <>,, Stephen Farrell <>
Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of FEC Framework <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Oct 2012 11:59:36 -0000


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
>> <>),
>> several
>> 	parts of [RFC5170 <>] are useless.  In
>> particular, this is the case of
>> 	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.

>> (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

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:

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?


    Vincent, on behalf of the authors

NB: I'm adding Stephen Farrell who first identified the IPR disclosure question
during IESG review.