Re: Posting of IPR Disclosure related to QUALCOMM = Incorporated's Statement about IPR related to = draft-roca-fecframe-rs-02

From ietfdbh@comcast.net Thu Apr 1 07:18:40 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4AA93A6980 for ; Thu, 1 Apr 2010 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.02 X-Spam-Level: * X-Spam-Status: No, score=1.02 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Y2hq6t95HFQ for ; Thu, 1 Apr 2010 07:18:40 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id 2D8523A692C for ; Thu, 1 Apr 2010 07:18:05 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta06.westchester.pa.mail.comcast.net with comcast id 0E2N1e02H1ZXKqc56EJfv6; Thu, 01 Apr 2010 14:18:39 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta21.westchester.pa.mail.comcast.net with comcast id 0EN91e00S2JQnJT3hEN9E1; Thu, 01 Apr 2010 14:22:10 +0000 From: "David Harrington" To: "'Luby, Michael'" , "'Vincent Roca'" , References: <4BABC52E.20602@inrialpes.fr> Date: Thu, 1 Apr 2010 10:18:37 -0400 Message-ID: <03fa01cad1a6$38c98e30$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03FB_01CAD184.B1B7EE30" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrMWH8S/zO5YJ1JQda+LwGDvqSQagAKe6FaAUdyLhA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Cc: housley@vigilsec.com, ipr-announce@ietf.org Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 14:18:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_03FB_01CAD184.B1B7EE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I work for a large corporation, and understand the importance of IPR to large corporations. I have worked in IETF for 18 years and understand the importance of IPR to IETF standardization efforts. I believe this is the correct forum to discuss specific IPR claims and specific licensing that might impact the usefulness of standards produced by this forum, within the guidelines provided by RFC3669 "Guidelines for Working Groups on Intellectual Property Issues". It is not the correct forum to judge whether the IPR is valid. That is up to the appropriate courts to decide. I believe that it is appropriate for the WG to attempt to get clarification on both IPR claims and licensing terms, to consider whether alternate designs might better serve the Internet community, to consider whether having no standard might better serve the Internet community, and to decide whether the licensing terms mitigate the impact of the known IPR. Recognize that IPR claims might appear at any time during the life of a standard, so trying to pick a design that has **no** IPR encumbrances might not be successful. Deciding whether the licensing terms mitigate the impact of the declared IPR might be a better use of the WG's time. But that is a WG's decision, as reflected in RFC3669. All participants should be very careful to respect each other's viewpoints in the discussions. dbh David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _____ From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Luby, Michael Sent: Thursday, March 25, 2010 9:20 PM To: Vincent Roca; fecframe@ietf.org Cc: housley@vigilsec.com; ipr-announce@ietf.org Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 All, I agree with and respect Stephan's remarks, this is not the forum to discuss specific IPR. Mike On 3/25/10 1:18 PM, "Vincent Roca" wrote: Mike, I discover that QC just updated its previous IPR disclosure against our I-D in: https://datatracker.ietf.org/ipr/1288/ This disclosure refers to draft-roca-fecframe-rs-02, i.e. the latest version where we tried to solve the potential IPR issue as I explained to you in my previous emails (sent before the IPR disclosure update): http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html So I take it as QC's official answer: the issue is not solved in -02 version according to QC! Since it seems I have no choice, let's put everything on the table: ** Concerning US Patent 7,660,245: This patent has three independent claims: 1, 16 and 18. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols. Unless we forgot something, we removed from our I-D all references to this technique, which is sufficient to conclude that version -02 cannot infringe US Patent 7,660,245. ** Concerning Patent 20100050057: This patent has four independent claims: 1, 10, 16 and 24. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols, so my answer is exactly the same. I'd like to understand. *I am doing significant efforts but I now have the feeling this is not reciprocal.* What's wrong? I need an answer. Regards, Vincent On 25/03/10 18:08, IETF Secretariat wrote: > Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine Bouabdallah: > > An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Solomon > Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe-rs) > was submitted to the IETF Secretariat on 2010-03-18 and has been posted on the > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure is > "QUALCOMM Incorporated's Statement about IPR related to > draft-roca-fecframe-rs-02." > > The IETF Secretariat > ------=_NextPart_000_03FB_01CAD184.B1B7EE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: Posting of IPR Disclosure related to QUALCOMM = Incorporated's Statement about IPR related to = draft-roca-fecframe-rs-02

Hi,

I work for a large corporation, and understand = the=20 importance of IPR to large corporations.

I have worked in IETF for 18 years and = understand the=20 importance of IPR to IETF standardization efforts.

I believe this is the correct forum to discuss = specific IPR=20 claims and specific licensing that might impact the usefulness of = standards=20 produced by this forum, within the guidelines provided by RFC3669 = "Guidelines=20 for Working Groups on Intellectual Property Issues". =

It is not the=20 correct forum to judge whether the IPR is valid. That is up to the = appropriate=20 courts to decide.

I believe that it is appropriate for the WG to=20 attempt to get clarification = on both IPR=20 claims and licensing terms, to consider whether=20 alternate designs might better serve the Internet community, to consider whether=20 having no standard might better serve the Internet community, = and=20 to decide whether the licensing terms mitigate the impact of the known = IPR.=20

Recognize that IPR claims might appear at any = time during=20 the life of a standard, so trying to pick a design that has **no** IPR=20 encumbrances might not be successful. Deciding whether the licensing = terms=20 mitigate the impact of the declared IPR might be a better use of the = WG's time.=20 But that is a WG's decision, as reflected in = RFC3669.

All participants should be very careful to = respect each=20 other's viewpoints in the discussions.

dbh

David=20 Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharring= ton@huawei.com

From: fecframe-bounces@ietf.org=20 [mailto:fecframe-bounces@ietf.org] On Behalf Of Luby,=20 Michael
Sent: Thursday, March 25, 2010 9:20 PM
To: = Vincent=20 Roca; fecframe@ietf.org
Cc: housley@vigilsec.com;=20 ipr-announce@ietf.org
Subject: Re: [Fecframe] Posting of IPR = Disclosure related to QUALCOMM Incorporated's Statement about IPR = related to=20 draft-roca-fecframe-rs-02

All,
I agree with and respect = Stephan’s remarks,=20 this is not the forum to discuss specific IPR.
Mike =

On=20 3/25/10 1:18 PM, "Vincent Roca" <vincent.roca@inrialpes.fr>=20 wrote:

Mike,

I discover that QC just = updated its=20 previous IPR disclosure
against our I-D in: https://datatracker.ietf.= org/ipr/1288/

This=20 disclosure refers to draft-roca-fecframe-rs-02, i.e. the
latest = version=20 where we tried to solve the potential IPR issue
as I explained to = you in=20 my previous emails (sent before the
IPR disclosure update):
http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html

So=20 I take it as QC's official answer: the issue is not solved in
-02 = version=20 according to QC!

Since it seems I have no choice, let's = put=20 everything on the
table:

** Concerning US Patent=20 7,660,245:
This patent has three independent claims: 1, 16 and=20 18.
*All of them* are restricted to situations where different=20 source
packets contribute to a different number of source=20 symbols.
Unless we forgot something, we removed from our I-D=20 all
references to this technique, which is sufficient to conclude = that
version -02 cannot infringe US Patent 7,660,245.

**=20 Concerning Patent 20100050057:
This patent has four independent = claims:=20 1, 10, 16 and 24.
*All of them* are restricted to situations = where=20 different source
packets contribute to a different number of = source=20 symbols, so
my answer is exactly the same.

I'd like to = understand. *I am doing significant efforts but
I now have the = feeling=20 this is not reciprocal.* What's wrong?
I need an=20 answer.

Regards,

Vincent

On = 25/03/10 18:08, IETF Secretariat wrote:
> Dear Vincent Roca, = Jerome=20 Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine=20 Bouabdallah:
>
> An IPR disclosure that pertains to your = Internet-Draft entitled "Reed-Solomon
> Forward Error = Correction (FEC)=20 Schemes for FECFRAME" (draft-roca-fecframe-rs)
> was submitted = to the=20 IETF Secretariat on 2010-03-18 and has been posted on the
> = "IETF Page=20 of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.= org/ipr/1288/).=20 The title of the IPR disclosure is
> "QUALCOMM Incorporated's=20 Statement about IPR related to
>=20 draft-roca-fecframe-rs-02."
>
> The IETF = Secretariat
>=20

------=_NextPart_000_03FB_01CAD184.B1B7EE30-- From vincent.roca@inrialpes.fr Thu Apr 1 08:11:54 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38A583A6933 for ; Thu, 1 Apr 2010 08:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.267 X-Spam-Level: X-Spam-Status: No, score=-4.267 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so9L-eF12BfN for ; Thu, 1 Apr 2010 08:11:49 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id 4C7373A692C for ; Thu, 1 Apr 2010 08:11:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,348,1267398000"; d="scan'208,217";a="47872345" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 01 Apr 2010 17:12:18 +0200 Message-ID: <4BB4B7D2.5080606@inrialpes.fr> Date: Thu, 01 Apr 2010 17:12:18 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060907030702050900050802" Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:11:54 -0000 This is a multi-part message in MIME format. --------------060907030702050900050802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Stephan, I'm sorry if my emails are an issue for you, especially if you cannot ignore them. I also have the feeling your problem is more general than this specific discussion (e.g. Scott Bradner, during his IETF77 introduction to the IETF standards process, clearly stated that WG may take IPR into account). I have no solution for you since I need to continue this discussion in the list. Sorry for the inconvenience. Regards, Vincent Le 29/03/2010 16:31, Stephan Wenger a �crit : > Vincent, > I stand to my points. Three more things: > > 1. I'm not with Nokia IPR/legal anymore, I'm now with a > video-conferencing company called Vidyo. My access to legal > resources here is limited. > 2. I have not implied that you are out of policy, although that may > also be the case. I have implied (and state here now directly) > that the way you are working on IPR topic is dangerous to me, to > my employer, possibly to my previous employers, and arguably to > yourself. It's also rude to push information towards people who > have expressed to you many times that they are not interested > in. The reasons for that lack of interest are not your concern. > 3. When patent numbers are involved and details of claim language > are discussed on a public mailing list, there is no such thing > as "ignoring". One may well "notice" (in any sense of this word > you wish to tag to it). > > Regards, > Stephan --------------060907030702050900050802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Stephan,

I'm sorry if my emails are an issue for you, especially if
you cannot ignore them. I also have the feeling your problem
is more general than this specific discussion (e.g. Scott Bradner,
during his IETF77 introduction to the IETF standards process,
clearly stated that WG may take IPR into account).
I have no solution for you since I need to continue this discussion
in the list. Sorry for the inconvenience.

Regards,

Vincent

Le 29/03/2010 16:31, Stephan Wenger a écrit :

Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 Vincent,
I stand to my points. Three more things:

I’m not with Nokia IPR/legal anymore, I’m now with a video-conferencing company called Vidyo. My access to legal resources here is limited.

I have not implied that you are out of policy, although that may also be the case. I have implied (and state here now directly) that the way you are working on IPR topic is dangerous to me, to my employer, possibly to my previous employers, and arguably to yourself. It’s also rude to push information towards people who have expressed to you many times that they are not interested in. The reasons for that lack of interest are not your concern.

When patent numbers are involved and details of claim language are discussed on a public mailing list, there is no such thing as “ignoring”. One may well “notice” (in any sense of this word you wish to tag to it).

Regards,
Stephan

--------------060907030702050900050802-- From vincent.roca@inrialpes.fr Thu Apr 1 08:17:45 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8FA73A6829; Thu, 1 Apr 2010 08:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCFdTE8-+5yg; Thu, 1 Apr 2010 08:17:43 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id EA4473A677C; Thu, 1 Apr 2010 08:17:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,348,1267398000"; d="scan'208";a="47872779" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 01 Apr 2010 17:18:14 +0200 Message-ID: <4BB4B936.70500@inrialpes.fr> Date: Thu, 01 Apr 2010 17:18:14 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: "Luby, Michael" References: , <4BB0ABD1.9050905@inrialpes.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "housley@vigilsec.com" , "ipr-announce@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 15:17:45 -0000 Mike, My intent has never been to convince QC of the negative impacts of patents ;-), therefore I'll just focus on the main topic. I see good points in your answer, In particular when you say: > *** You got an answer, which I'll repeat here: the one issue > that we discussed previously was addressed, but there are other > issues which we have identified that still need to be > considered and addressed. This is exactly my goal: *consider and address the other issues*. I want to understand the situation. According to what I can read, version 02 of our I-D cannot infringe any claim of the two patents since the 7 independent claims all require that "the first number of source symbols is different from the second number of source symbols". This is no longer the case in -02. If I'm wrong, where's my mistake? Which claim(s) do you think version 02 infringes? I want to understand your point of view. Concerning our discussion in RMT last Autumn, I cant' follow you when you say: > *** Nothing was achieved in RMT in my opinion. That was > a huge waste of time and energy in my opinion to try and > resolve the situation, and didn't achieve anything, as still > it is the case that QC has declared IPR on some of your drafts > and you have declared loudly and publicly in many forums that > this is not the case. How is that a good resolution? The one and only reason that led QC to add 10 patents to its IPR disclosure against RFC 5170 is now known. Since the technique that infringes these patents (i.e. "having several symbols per packet") is not mandatory to use, a user can decide whether it's worth using it or not. If it is a waste of time from your point of view, I don't think you'll find many potential users who agree. Here also we see how "unpublished pending patents" can badly interfere with IETF activities. If Digital Fountain had clarified the issue since the beginning (i.e. in December 2007, after IPR Disclosure #908) and pointed out to us where the problem was, the offending technique would have been removed before the RFC is published (as I said this technique is not essential and we can, by increasing the matrix density, achieve good erasure recovery performances even for small blocks). This is precisely why I want to clarify the situation today W.R.T. our FECFRAME I-D. Another point which is, for the moment, of secondary importance IMHO, even if you mentioned it: > *** The main change to the new IPR disclosures (and we > updated them all in RMT and FECFRAME, not just this one) > compared to previous is the licensing terms, that > rationally should put the whole issue to rest. Clearly, > this didn't mollify you, as it seems that any IPR, even > if the licensing terms are quite quite favorable, is > unacceptable in your opinion. At this step of the discussion, we must focus on the main questions: does this I-D infringe any claim? Why? Are there alternatives? Is there any penalty in considering these alternatives, if any? You are trying to reverse the reasoning. This is a mistake IMHO. Licensing conditions are one of the elements to consider once we all perfectly understand the situation, not before. Anyway licensing conditions are never definitive and can be changed at any time (and it already happened 3 times with RFC 5170!). Be assured I want to constructively discuss with you. Best regards, Vincent On 29/03/2010 18:54, Luby, Michael wrote: > Some remarks below. (***) > ________________________________________ > From: Vincent Roca [vincent.roca@inrialpes.fr] > Sent: Monday, March 29, 2010 6:32 AM > To: Luby, Michael > Cc: fecframe@ietf.org; housley@vigilsec.com; ipr-announce@ietf.org > Subject: Re: Posting of IPR Disclosure related to QUALCOMM Incorporated= 's Statement about IPR related to draft-roca-fecframe-rs-02 > > Hello Stephan and Mike, > > > I think your emails deserve an answer. > Generals considerations first, and then I'll focus on > the specific point under discussion. > > -- > > I'm also fed up with all these IPR issues that oblige me to > leave my primary activities all too often. I'm researcher, > not an IPR lawyer and I have no natural inclination for > these legal aspects. > > That being said, I also want my work to be useful to the > whole community (within or outside of the IETF, Nokia and > QC included). From this point of view, if there's an IPR > disclosure and if I have the feeling an alternative > solution exists, I'll examine it instead of "passively > accepting" the situation. In any case be assured my > behavior is only governed by the desire to be useful to > the community. > > *** There is IPR disclosures on many specifications within the IETF, an= d the standards in which they exist are useful to the whole community. Y= our premise is flawed, and thus much of the reasoning below. > > One big difference between you and me is the fact I don't > have any legal department in charge of examining IPR > aspects. If my documents are subject of a disclosure, I > can either ignore it (as many colleagues do) or tackle > its analysis. If I want to achieve my above goal of being > useful to the community, this second option is the only > possible. > > Yes, I'd like we could all work just like 30-40 years ago, > when smart people were eager to design the best possible > Internet, using the best possible techniques, just because > it was the right answer to the situation. It's worth > remembering this heritage. It's perhaps an utopia > today, however I'm doing my best to stick with this > philosophy since I currently have the freedom to do > that. > > *** Much of the best technology used on the Internet has/had IPR, inclu= ding Reed-Solomon codes, all video codecs, etc. > > Finally, you can find many examples of WGs going into this > kind of discussion, e.g. in the informational RFC 3669 > (https://datatracker.ietf.org/doc/rfc3669/). > A few excerpts of the lessons learned: > > o IPR claims should never be disregarded without good cause. Due > diligence should be done to understand the consequences of each > claim. > [...] > o It's sometimes beneficial to push IPR claimants to find out what= > they think their claims cover and what their licensing terms are= =2E > > o Possibilities of prior art should be considered. > > o It's all right, and sometimes beneficial, to discuss IPR claims > and gather information about possible prior art on the group lis= t. > The results of such discussion can be considered when deciding > whether to develop a technology (but remember that neither the > IETF nor any working group takes a stand on such claims as a bod= y, > and the group is not the best place to get legal advice). > > The above sentences are not definite rules, of course, and > each situation is specific and needs to be handled > appropriately. However saying that "[the FECFRAME mailing > list] is not the forum to discuss specific IPR" is a > personal interpretation that is in-line with the IETF > practices. > > > -- > > Now, concerning the topic that triggered this discussion: > > - I've updated the I-D and in theory it's sufficient for > QC to be aware of our attempts to solve the problem; > - However I explicitly told Mike what we've done and > asked him to clarify QC's position. No answer; > - I met Mike just before the fecframe meeting and asked > again the same question. Unless I misunderstood what he > said, I didn't get any answer; > > *** You got an answer, which I'll repeat here: the one issue that we di= scussed previously was addressed, but there are other issues which we hav= e identified that still need to be considered and addressed. > > - the situation was once again explained in my slides. > > I was not there unfortunately, but I didn't see > anything in the Minutes; > - And then came this new IPR disclosure that completely > ignores any effort I've made to try understand the > situation and to solve it. > > *** The main change to the new IPR disclosures (and we updated them all= in RMT and FECFRAME, not just this one) compared to previous is the lice= nsing terms, that rationally should put the whole issue to rest. Clearly= , this didn't mollify you, as it seems that any IPR, even if the licensin= g terms are quite quite favorable, is unacceptable in your opinion. Howe= ver, during the course of the IPR update process, we did reexamine the sp= ec and understood that there were still some technical issues with the cu= rrent draft that probably would have to be changed to be clear of the par= ticular IPR that is declared on the current draft. If I remember correct= ly, you also mentioned that you would be adding some new elements to the = next version of the draft, and be aware and forewarned that these will al= so have to be carefully scrutinized, as part of our obligations, to see i= f there is any necessity to declare additional IPR. > > At this point, I'm now wondering if QC's strategy is not > to leave this point open until everybody forget? Anyway, > if QC does not want to answer, I want it to be clearly > stated and justified. How long it will take me to have > this clarification is not under my control. > > *** This is not nor ever has been QC strategy. > > I'm not responsible of the whole story. Especially as > last year I even made sure that there was no IPR issue > in FECFRAME. Now DF/QC chose the submarine patent > approach ("undisclosed pending patent") and to keep it > secret till it's granted, last month. It's their right but me > and my co-authors are the victims in this story. > > *** It was not a submarine patent, and it is dangerous to allege this. > > > Last but not least... > In all my emails exchanges, I pay attention not to offend > anybody. I don't have the feeling that any email I sent > (including this one) was offending, but if somebody has a > different feeling, then I apologize since this was not my > goal. > > Sorry for this very long email. I hope that you now better > understand my attitude. Stephan, if you are not interested > by my IPR-related emails, which I can understand, then > please ignore them. > > And long life to the IETF that already enabled me to solve > similar issues, without having to waste time, energy and > money in a court, whereas a consensus was easily achievable > as long as both parties are working toward this goal. Last > Autumn discussion with Mike on the RMT mailing list proved > it's possible. Thanks! > > *** Nothing was achieved in RMT in my opinion. That was a huge waste o= f time and energy in my opinion to try and resolve the situation, and did= n't achieve anything, as still it is the case that QC has declared IPR on= some of your drafts and you have declared loudly and publicly in many fo= rums that this is not the case. How is that a good resolution? > > Best regards, > > > Vincent > > > > On 26/03/2010 02:19, Luby, Michael wrote: > All, > I agree with and respect Stephan=92s remarks, this is not the forum to = discuss specific IPR. > Mike > > > On 3/25/10 1:18 PM, "Vincent Roca" wrote: > > Mike, > > I discover that QC just updated its previous IPR disclosure > against our I-D in: https://datatracker.ietf.org/ipr/1288/ > > This disclosure refers to draft-roca-fecframe-rs-02, i.e. the > latest version where we tried to solve the potential IPR issue > as I explained to you in my previous emails (sent before the > IPR disclosure update): > http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html > > So I take it as QC's official answer: the issue is not solved in > -02 version according to QC! > > > Since it seems I have no choice, let's put everything on the > table: > > ** Concerning US Patent 7,660,245: > This patent has three independent claims: 1, 16 and 18. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols. > Unless we forgot something, we removed from our I-D all > references to this technique, which is sufficient to conclude that > version -02 cannot infringe US Patent 7,660,245. > > ** Concerning Patent 20100050057: > This patent has four independent claims: 1, 10, 16 and 24. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols, so > my answer is exactly the same. > > > I'd like to understand. *I am doing significant efforts but > I now have the feeling this is not reciprocal.* What's wrong? > I need an answer. > > > Regards, > > Vincent > > > On 25/03/10 18:08, IETF Secretariat wrote: > =20 >> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, A= mine Bouabdallah: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Reed-= Solomon >> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecfr= ame-rs) >> was submitted to the IETF Secretariat on 2010-03-18 and has been poste= d on the >> "IETF Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclos= ure is >> "QUALCOMM Incorporated's Statement about IPR related to >> draft-roca-fecframe-rs-02." >> >> The IETF Secretariat >> =20 From abegen@cisco.com Sun Apr 4 12:29:59 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8872B3A6964 for ; Sun, 4 Apr 2010 12:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJgm8n3VB4yv for ; Sun, 4 Apr 2010 12:29:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 285D33A69DA for ; Sun, 4 Apr 2010 12:29:55 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFANKFuEurRN+J/2dsb2JhbACDE4xDiyBZcZofiEWPEYErgm5uBIMk X-IronPort-AV: E=Sophos;i="4.51,363,1267401600"; d="scan'208";a="314307973" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 04 Apr 2010 19:29:54 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o34JTswJ003370 for ; Sun, 4 Apr 2010 19:29:54 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 4 Apr 2010 12:29:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sun, 4 Apr 2010 12:30:14 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540BBD060D@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-fecframe-sdp-elements-05 Thread-Index: AcrULQf4xQgkr8q4Rmi9/x7ztqk6pwAABniQ From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 04 Apr 2010 19:29:54.0014 (UTC) FILETIME=[33BD47E0:01CAD42D] Subject: [Fecframe] FW: New Version Notification for draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 19:29:59 -0000 VGhpcyByZXZpc2lvbiBzaW1wbHkgZml4ZWQgdGhlIGJvaWxlcnBsYXRlLiBObyBvdGhlciBjaGFu Z2VzLiBDb3VsZCB3ZSBydW4gdGhlIDJuZCB3Z2xjIG9uIHRoaXMgZHJhZnQ/DQoNClRoYW5rcywN Ci1hY2JlZ2VuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJRVRGIEktRCBT dWJtaXNzaW9uIFRvb2wgW21haWx0bzppZHN1Ym1pc3Npb25AaWV0Zi5vcmddIA0KU2VudDogU3Vu ZGF5LCBBcHJpbCAwNCwgMjAxMCAzOjI5IFBNDQpUbzogQWxpIEMuIEJlZ2VuIChhYmVnZW4pDQpT dWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtZmVjZnJhbWUt c2RwLWVsZW1lbnRzLTA1IA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWZl Y2ZyYW1lLXNkcC1lbGVtZW50cy0wNS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBBbGkgQmVnZW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxl bmFtZToJIGRyYWZ0LWlldGYtZmVjZnJhbWUtc2RwLWVsZW1lbnRzDQpSZXZpc2lvbjoJIDA1DQpU aXRsZToJCSBTRFAgRWxlbWVudHMgZm9yIEZFQyBGcmFtZXdvcmsNCkNyZWF0aW9uX2RhdGU6CSAy MDEwLTA0LTA0DQpXRyBJRDoJCSBmZWNmcmFtZQ0KTnVtYmVyX29mX3BhZ2VzOiAyMQ0KDQpBYnN0 cmFjdDoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSB1c2Ugb2YgU2Vzc2lvbiBEZXNjcmlw dGlvbiBQcm90b2NvbCAoU0RQKQ0KdG8gZGVzY3JpYmUgdGhlIHBhcmFtZXRlcnMgcmVxdWlyZWQg dG8gc2lnbmFsIHRoZSBGb3J3YXJkIEVycm9yDQpDb3JyZWN0aW9uIChGRUMpIEZyYW1ld29yayBD b25maWd1cmF0aW9uIEluZm9ybWF0aW9uIGJldHdlZW4gdGhlDQpzZW5kZXIocykgYW5kIHJlY2Vp dmVyKHMpLiAgVGhpcyBkb2N1bWVudCBhbHNvIHByb3ZpZGVzIGV4YW1wbGVzIHRoYXQNCnNob3cg dGhlIHNlbWFudGljcyBmb3IgZ3JvdXBpbmcgbXVsdGlwbGUgc291cmNlIGFuZCByZXBhaXIgZmxv d3MNCnRvZ2V0aGVyIGZvciB0aGUgYXBwbGljYXRpb25zIHRoYXQgc2ltdWx0YW5lb3VzbHkgdXNl IG11bHRpcGxlDQppbnN0YW5jZXMgb2YgdGhlIEZFQyBGcmFtZXdvcmsuDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCg0K From root@core3.amsl.com Sun Apr 4 12:30:03 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2E4033A69E4; Sun, 4 Apr 2010 12:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100404193003.2E4033A69E4@core3.amsl.com> Date: Sun, 4 Apr 2010 12:30:02 -0700 (PDT) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-sdp-elements-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Apr 2010 19:30:03 -0000 --NextPart 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 : SDP Elements for FEC Framework Author(s) : A. Begen Filename : draft-ietf-fecframe-sdp-elements-05.txt Pages : 21 Date : 2010-04-04 This document specifies the use of Session Description Protocol (SDP) to describe the parameters required to signal the Forward Error Correction (FEC) Framework Configuration Information between the sender(s) and receiver(s). This document also provides examples that show the semantics for grouping multiple source and repair flows together for the applications that simultaneously use multiple instances of the FEC Framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-sdp-elements-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-sdp-elements-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-04122837.I-D@ietf.org> --NextPart-- From luby@qualcomm.com Wed Apr 7 17:39:54 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E353A681C; Wed, 7 Apr 2010 17:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.998 X-Spam-Level: X-Spam-Status: No, score=-103.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SqoNCT2ozdO; Wed, 7 Apr 2010 17:39:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id E0CDB3A67B1; Wed, 7 Apr 2010 17:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1270687172; x=1302223172; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20|CC:=20"fecfram e@ietf.org"=20,=20"housley@vigilsec.co m"=0D=0A=09,=20"ipr-announce@ietf.o rg"=20,=0D=0A=09"Luby,=20Michael" =20|Date:=20Wed,=207=20Apr=202010=2017 :39:29=20-0700|Subject:=20Re:=20Posting=20of=20IPR=20Disc losure=20related=20to=20QUALCOMM=20Incorporated's=0D=0A =20Statement=20about=20IPR=20related=20to=20draft-roca-fe cframe-rs-02|Thread-Topic:=20Posting=20of=20IPR=20Disclos ure=20related=20to=20QUALCOMM=20Incorporated's=0D=0A=20St atement=20about=20IPR=20related=20to=20draft-roca-fecfram e-rs-02|Thread-Index:=20AcrRrpxtQTjKthF1SJKAVXCNETKSkwFBV YYg|Message-ID:=20 |In-Reply-To:=20<4BB4B936.70500@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C7E273D1D2EDlubyqualcommcom_" |MIME-Version:=201.0; bh=oN+Pqkfxfdme/W21P6wz9MQmAkFw2IsP3lopZeAeVHo=; b=c/jfRsnh2+Xtg4eBg7VWkIhEH985TGjAknTpgFB1R8ff0QwKJ9LGywtJ y+lDK3sxTUCxtJXp+AshwHbut5A1L1k5y9GN2tENY/T64FnYdevQi5+Nt WnkkcDq0NNidSf2nmn+Tgs/HLFb1wD7MEFm4dy6EdRk+oEs2xpNiVxl5C c=; X-IronPort-AV: E=McAfee;i="5400,1158,5944"; a="38183776" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 07 Apr 2010 17:39:32 -0700 X-IronPort-AV: E=Sophos;i="4.52,165,1270450800"; d="scan'208,217";a="7993152" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 07 Apr 2010 17:39:32 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 7 Apr 2010 17:39:31 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Wed, 7 Apr 2010 17:39:30 -0700 From: "Luby, Michael" To: Vincent Roca Date: Wed, 7 Apr 2010 17:39:29 -0700 Thread-Topic: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 Thread-Index: AcrRrpxtQTjKthF1SJKAVXCNETKSkwFBVYYg Message-ID: In-Reply-To: <4BB4B936.70500@inrialpes.fr> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7E273D1D2EDlubyqualcommcom_" MIME-Version: 1.0 Cc: "housley@vigilsec.com" , "ipr-announce@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 00:39:54 -0000 --_000_C7E273D1D2EDlubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FECFRAME working group, Vincent has made some points below to which I have responded below (ML). O= n some of these points I think it would be useful to have other inputs from= other members of the FECFRAME working group, or those interested in IPR is= sues in general, rather than have this be just a dialog between two people. Thanks, Mike On 4/1/10 8:18 AM, "Vincent Roca" wrote: Mike, My intent has never been to convince QC of the negative impacts of patents ;-), therefore I'll just focus on the main topic. I see good points in your answer, In particular when you say: > *** You got an answer, which I'll repeat here: the one issue > that we discussed previously was addressed, but there are other > issues which we have identified that still need to be > considered and addressed. This is exactly my goal: *consider and address the other issues*. I want to understand the situation. According to what I can read, version 02 of our I-D cannot infringe any claim of the two patents since the 7 independent claims all require that "the first number of source symbols is different from the second number of source symbols". This is no longer the case in -02. If I'm wrong, where's my mistake? Which claim(s) do you think version 02 infringes? I want to understand your point of view. (ML) As a general policy (at both DF and QC), we declare IPR on an IETF dra= ft/RFC if there is some inventive element described in the draft/RFC that w= as previously described in the specification of an active patent, where we = feel that the element could be the basis of a claim. Otherwise, if we wait= ed till we actually had filed an additional patent with the particular clai= m based on the original patent specification and then after that declared I= PR on an IETF draft/RFC, it might be perceived as a submarine declaration. (ML) Given this, there are other elements, for example in U.S. Patent 76602= 45, that are also included in draft-roca-fecframe-rs-02. As an example of = such an element, placing the SBL in the repair packet FEC Payload ID but no= t in the source packet FEC Payload ID is described in some detail in U.S. P= atent 7660245, and the advantages of doing this are well-described in U.S. = Patent 7660245, but this particular element is not necessarily the basis of= a claim in U.S. Patent 7660245. However, this element is included in draf= t-roca-fecframe-rs-02. There are potentially other elements that are simil= ar, that I would be willing to work with you offline to identify and remove= from the newer versions of draft-roca-fecframe-rs-02, if this is the path = that you and the FECFRAME working group decide to take. Concerning our discussion in RMT last Autumn, I cant' follow you when you say: > *** Nothing was achieved in RMT in my opinion. That was > a huge waste of time and energy in my opinion to try and > resolve the situation, and didn't achieve anything, as still > it is the case that QC has declared IPR on some of your drafts > and you have declared loudly and publicly in many forums that > this is not the case. How is that a good resolution? The one and only reason that led QC to add 10 patents to its IPR disclosure against RFC 5170 is now known. Since the technique that infringes these patents (i.e. "having several symbols per packet") is not mandatory to use, a user can decide whether it's worth using it or not. If it is a waste of time from your point of view, I don't think you'll find many potential users who agree. Here also we see how "unpublished pending patents" can badly interfere with IETF activities. If Digital Fountain had clarified the issue since the beginning (i.e. in December 2007, after IPR Disclosure #908) and pointed out to us where the problem was, the offending technique would have been removed before the RFC is published (as I said this technique is not essential and we can, by increasing the matrix density, achieve good erasure recovery performances even for small blocks). (ML) There is still an IPR declaration against RFC 5170 that was not resolv= ed and I imagine will not be resolved, since for whatever reason you have d= ecided that it is ok not to try and remove that IPR from the RFC 5170. So,= in my mind, resolving one portion of an IPR declaration but still having o= ther IPR declared that is not resolved doesn't really help, since the basic= situation is the same: there is still IPR declared on RFC 5170. This is precisely why I want to clarify the situation today W.R.T. our FECFRAME I-D. Another point which is, for the moment, of secondary importance IMHO, even if you mentioned it: > *** The main change to the new IPR disclosures (and we > updated them all in RMT and FECFRAME, not just this one) > compared to previous is the licensing terms, that > rationally should put the whole issue to rest. Clearly, > this didn't mollify you, as it seems that any IPR, even > if the licensing terms are quite quite favorable, is > unacceptable in your opinion. At this step of the discussion, we must focus on the main questions: does this I-D infringe any claim? Why? Are there alternatives? Is there any penalty in considering these alternatives, if any? You are trying to reverse the reasoning. This is a mistake IMHO. Licensing conditions are one of the elements to consider once we all perfectly understand the situation, not before. (ML) Here is an extract from the email that David Harrington recently sent = out: "Recognize that IPR claims might appear at any time during the life of= a standard, so trying to pick a design that has **no** IPR encumbrances mi= ght not be successful. Deciding whether the licensing terms mitigate the im= pact of the declared IPR might be a better use of the WG's time. But that i= s a WG's decision, as reflected in RFC3669." That was my point. Anyway licensing conditions are never definitive and can be changed at any time (and it already happened 3 times with RFC 5170!). (ML) True about the changes in licensing conditions/terms, and this has bee= n true for all relevant drafts/RFCs in both RMT and FECFRAME with respect t= o DF/QC IPR declarations, but each time they have changed they have become = more favorable, to the point that the licensing terms have become very favo= rable at this point. Thus, a general question for FECFRAME: Is it better = to have drafts/RFCs with no currently known IPR declarations at the expense= of possibly not as good drafts/RFCs in terms of the technology capabilitie= s and efficiencies, or is it better to have drafts/RFCs with IPR declaratio= ns with favorable licensing terms with the advantage of having better draft= s/RFCs in terms of the technology capabilities and efficiencies? This is n= ot an abstract question: this is a question specifically in the context of = this and other drafts within FECFRAME and with respect to the particular I= PR declarations with associated licensing terms that have been made in FECF= RAME. I know how some other IETF working groups have dealt with this, and = it seems to have come out both ways depending on the group and the licensin= g terms, but I'm not sure that FECFRAME has had this discussion at the work= ing group level to decide the path forward. Be assured I want to constructively discuss with you. Best regards, Vincent On 29/03/2010 18:54, Luby, Michael wrote: > Some remarks below. (***) > ________________________________________ > From: Vincent Roca [vincent.roca@inrialpes.fr] > Sent: Monday, March 29, 2010 6:32 AM > To: Luby, Michael > Cc: fecframe@ietf.org; housley@vigilsec.com; ipr-announce@ietf.org > Subject: Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's= Statement about IPR related to draft-roca-fecframe-rs-02 > > Hello Stephan and Mike, > > > I think your emails deserve an answer. > Generals considerations first, and then I'll focus on > the specific point under discussion. > > -- > > I'm also fed up with all these IPR issues that oblige me to > leave my primary activities all too often. I'm researcher, > not an IPR lawyer and I have no natural inclination for > these legal aspects. > > That being said, I also want my work to be useful to the > whole community (within or outside of the IETF, Nokia and > QC included). From this point of view, if there's an IPR > disclosure and if I have the feeling an alternative > solution exists, I'll examine it instead of "passively > accepting" the situation. In any case be assured my > behavior is only governed by the desire to be useful to > the community. > > *** There is IPR disclosures on many specifications within the IETF, and = the standards in which they exist are useful to the whole community. Your = premise is flawed, and thus much of the reasoning below. > > One big difference between you and me is the fact I don't > have any legal department in charge of examining IPR > aspects. If my documents are subject of a disclosure, I > can either ignore it (as many colleagues do) or tackle > its analysis. If I want to achieve my above goal of being > useful to the community, this second option is the only > possible. > > Yes, I'd like we could all work just like 30-40 years ago, > when smart people were eager to design the best possible > Internet, using the best possible techniques, just because > it was the right answer to the situation. It's worth > remembering this heritage. It's perhaps an utopia > today, however I'm doing my best to stick with this > philosophy since I currently have the freedom to do > that. > > *** Much of the best technology used on the Internet has/had IPR, includi= ng Reed-Solomon codes, all video codecs, etc. > > Finally, you can find many examples of WGs going into this > kind of discussion, e.g. in the informational RFC 3669 > (https://datatracker.ietf.org/doc/rfc3669/). > A few excerpts of the lessons learned: > > o IPR claims should never be disregarded without good cause. Due > diligence should be done to understand the consequences of each > claim. > [...] > o It's sometimes beneficial to push IPR claimants to find out what > they think their claims cover and what their licensing terms are. > > o Possibilities of prior art should be considered. > > o It's all right, and sometimes beneficial, to discuss IPR claims > and gather information about possible prior art on the group list. > The results of such discussion can be considered when deciding > whether to develop a technology (but remember that neither the > IETF nor any working group takes a stand on such claims as a body, > and the group is not the best place to get legal advice). > > The above sentences are not definite rules, of course, and > each situation is specific and needs to be handled > appropriately. However saying that "[the FECFRAME mailing > list] is not the forum to discuss specific IPR" is a > personal interpretation that is in-line with the IETF > practices. > > > -- > > Now, concerning the topic that triggered this discussion: > > - I've updated the I-D and in theory it's sufficient for > QC to be aware of our attempts to solve the problem; > - However I explicitly told Mike what we've done and > asked him to clarify QC's position. No answer; > - I met Mike just before the fecframe meeting and asked > again the same question. Unless I misunderstood what he > said, I didn't get any answer; > > *** You got an answer, which I'll repeat here: the one issue that we disc= ussed previously was addressed, but there are other issues which we have id= entified that still need to be considered and addressed. > > - the situation was once again explained in my slides. > > I was not there unfortunately, but I didn't see > anything in the Minutes; > - And then came this new IPR disclosure that completely > ignores any effort I've made to try understand the > situation and to solve it. > > *** The main change to the new IPR disclosures (and we updated them all i= n RMT and FECFRAME, not just this one) compared to previous is the licensin= g terms, that rationally should put the whole issue to rest. Clearly, this= didn't mollify you, as it seems that any IPR, even if the licensing terms = are quite quite favorable, is unacceptable in your opinion. However, durin= g the course of the IPR update process, we did reexamine the spec and under= stood that there were still some technical issues with the current draft th= at probably would have to be changed to be clear of the particular IPR that= is declared on the current draft. If I remember correctly, you also menti= oned that you would be adding some new elements to the next version of the = draft, and be aware and forewarned that these will also have to be carefull= y scrutinized, as part of our obligations, to see if there is any necessity= to declare additional IPR. > > At this point, I'm now wondering if QC's strategy is not > to leave this point open until everybody forget? Anyway, > if QC does not want to answer, I want it to be clearly > stated and justified. How long it will take me to have > this clarification is not under my control. > > *** This is not nor ever has been QC strategy. > > I'm not responsible of the whole story. Especially as > last year I even made sure that there was no IPR issue > in FECFRAME. Now DF/QC chose the submarine patent > approach ("undisclosed pending patent") and to keep it > secret till it's granted, last month. It's their right but me > and my co-authors are the victims in this story. > > *** It was not a submarine patent, and it is dangerous to allege this. > > > Last but not least... > In all my emails exchanges, I pay attention not to offend > anybody. I don't have the feeling that any email I sent > (including this one) was offending, but if somebody has a > different feeling, then I apologize since this was not my > goal. > > Sorry for this very long email. I hope that you now better > understand my attitude. Stephan, if you are not interested > by my IPR-related emails, which I can understand, then > please ignore them. > > And long life to the IETF that already enabled me to solve > similar issues, without having to waste time, energy and > money in a court, whereas a consensus was easily achievable > as long as both parties are working toward this goal. Last > Autumn discussion with Mike on the RMT mailing list proved > it's possible. Thanks! > > *** Nothing was achieved in RMT in my opinion. That was a huge waste of = time and energy in my opinion to try and resolve the situation, and didn't = achieve anything, as still it is the case that QC has declared IPR on some = of your drafts and you have declared loudly and publicly in many forums tha= t this is not the case. How is that a good resolution? > > Best regards, > > > Vincent > > > > On 26/03/2010 02:19, Luby, Michael wrote: > All, > I agree with and respect Stephan's remarks, this is not the forum to disc= uss specific IPR. > Mike > > > On 3/25/10 1:18 PM, "Vincent Roca" wrote: > > Mike, > > I discover that QC just updated its previous IPR disclosure > against our I-D in: https://datatracker.ietf.org/ipr/1288/ > > This disclosure refers to draft-roca-fecframe-rs-02, i.e. the > latest version where we tried to solve the potential IPR issue > as I explained to you in my previous emails (sent before the > IPR disclosure update): > http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html > > So I take it as QC's official answer: the issue is not solved in > -02 version according to QC! > > > Since it seems I have no choice, let's put everything on the > table: > > ** Concerning US Patent 7,660,245: > This patent has three independent claims: 1, 16 and 18. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols. > Unless we forgot something, we removed from our I-D all > references to this technique, which is sufficient to conclude that > version -02 cannot infringe US Patent 7,660,245. > > ** Concerning Patent 20100050057: > This patent has four independent claims: 1, 10, 16 and 24. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols, so > my answer is exactly the same. > > > I'd like to understand. *I am doing significant efforts but > I now have the feeling this is not reciprocal.* What's wrong? > I need an answer. > > > Regards, > > Vincent > > > On 25/03/10 18:08, IETF Secretariat wrote: > >> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Ami= ne Bouabdallah: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Reed-So= lomon >> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecfram= e-rs) >> was submitted to the IETF Secretariat on 2010-03-18 and has been posted = on the >> "IETF Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosur= e is >> "QUALCOMM Incorporated's Statement about IPR related to >> draft-roca-fecframe-rs-02." >> >> The IETF Secretariat >> --_000_C7E273D1D2EDlubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's Sta= tement about IPR related to draft-roca-fecframe-rs-02 FECFRAME working group,
Vincent has made some points below to which I have responded below (ML). &n= bsp;On some of these points I think it would be useful to have other inputs= from other members of the FECFRAME working group, or those interested in I= PR issues in general, rather than have this be just a dialog between two pe= ople.
Thanks, Mike

On 4/1/10 8:18 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote:

Mike,

My intent has never been to convince QC of the negative
impacts of patents ;-), therefore I'll just focus on the main
topic.

I see good points in your answer, In particular when you
say:

> *** You got an answer, which I'll repeat here: the one issue
> that we discussed previously was addressed, but there are other<= BR> > issues which we have identified that still need to be
> considered and addressed.

This is exactly my goal: *consider and address the other
issues*. I want to understand the situation. According to
what I can read, version 02 of our I-D cannot infringe any
claim of the two patents since the 7 independent claims
all require that "the first number of source symbols is
different from the second number of source symbols".
This is no longer the case in -02. If I'm wrong, where's
my mistake? Which claim(s) do you think version 02
infringes? I want to understand your point of view.

(ML) As a general policy (at both DF and QC), we declare IPR on an IETF dra= ft/RFC if there is some inventive element described in the draft/RFC that w= as previously described in the specification of an active patent, where we = feel that the element could be the basis of a claim. Otherwise, if we= waited till we actually had filed an additional patent with the particular= claim based on the original patent specification and then after that decla= red IPR on an IETF draft/RFC, it might be perceived as a submarine declarat= ion.

(ML) Given this, there are other elements, for example in U.S. Patent 76602= 45, that are also included in draft-roca-fecframe-rs-02. As an exampl= e of such an element, placing the SBL in the repair packet FEC Payload ID b= ut not in the source packet FEC Payload ID is described in some detail in U= .S. Patent 7660245, and the advantages of doing this are well-described in = U.S. Patent 7660245, but this particular element is not necessarily the bas= is of a claim in U.S. Patent 7660245. However, this element is includ= ed in draft-roca-fecframe-rs-02. There are potentially other elements= that are similar, that I would be willing to work with you offline to iden= tify and remove from the newer versions of draft-roca-fecframe-rs-02, if th= is is the path that you and the FECFRAME working group decide to take. &nbs= p;

Concerning our discussion in RMT last Autumn, I cant'
follow you when you say:

> *** Nothing was achieved in RMT in my opinion. That was > a huge waste of time and energy in my opinion to try and
> resolve the situation, and didn't achieve anything, as still
> it is the case that QC has declared IPR on some of your drafts > and you have declared loudly and publicly in many forums that > this is not the case. How is that a good resolution?

The one and only reason that led QC to add 10 patents
to its IPR disclosure against RFC 5170 is now known.
Since the technique that infringes these patents (i.e.
"having several symbols per packet") is not mandatory
to use, a user can decide whether it's worth using it or
not. If it is a waste of time from your point of view,
I don't think you'll find many potential users who agree.

Here also we see how "unpublished pending patents"
can badly interfere with IETF activities. If Digital
Fountain had clarified the issue since the beginning
(i.e. in December 2007, after IPR Disclosure #908)
and pointed out to us where the problem was, the
offending technique would have been removed before the
RFC is published (as I said this technique is not
essential and we can, by increasing the matrix density,
achieve good erasure recovery performances even for
small blocks).

(ML) There is still an IPR declaration against RFC 5170 that was not resolv= ed and I imagine will not be resolved, since for whatever reason you have d= ecided that it is ok not to try and remove that IPR from the RFC 5170. &nbs= p;So, in my mind, resolving one portion of an IPR declaration but still hav= ing other IPR declared that is not resolved doesn’t really help, sinc= e the basic situation is the same: there is still IPR declared on RFC 5170.=

This is precisely why I want to clarify the situation
today W.R.T. our FECFRAME I-D.

Another point which is, for the moment, of secondary
importance IMHO, even if you mentioned it:

> *** The main change to the new IPR disclosures (and we
> updated them all in RMT and FECFRAME, not just this one)
> compared to previous is the licensing terms, that
> rationally should put the whole issue to rest. Clearly, > this didn't mollify you, as it seems that any IPR, even
> if the licensing terms are quite quite favorable, is
> unacceptable in your opinion.

At this step of the discussion, we must focus on the
main questions: does this I-D infringe any claim?
Why? Are there alternatives? Is there any penalty in
considering these alternatives, if any?

You are trying to reverse the reasoning. This is a
mistake IMHO. Licensing conditions are one of the
elements to consider once we all perfectly understand
the situation, not before.

(ML) Here is an extract from the email that David Harrington recently sent = out: “Recognize that IPR claims might appear at any ti= me during the life of a standard, so trying to pick a design that has **no*= * IPR encumbrances might not be successful. Deciding whether the licensing = terms mitigate the impact of the declared IPR might be a better use of the = WG's time. But that is a WG's decision, as reflected in RFC3669.” That was my point.

Anyway licensing conditions are never definitive and
can be changed at any time (and it already happened 3
times with RFC 5170!).

(ML) True about the changes in licensing conditions/terms, and this has bee= n true for all relevant drafts/RFCs in both RMT and FECFRAME with respect t= o DF/QC IPR declarations, but each time they have changed they have become = more favorable, to the point that the licensing terms have become very favo= rable at this point. Thus, a general question for FECFRAME: Is = it better to have drafts/RFCs with no currently known IPR declarations at t= he expense of possibly not as good drafts/RFCs in terms of the technology c= apabilities and efficiencies, or is it better to have drafts/RFCs with IPR = declarations with favorable licensing terms with the advantage of having be= tter drafts/RFCs in terms of the technology capabilities and efficiencies? = This is not an abstract question: this is a question specifically in = the context of this and other drafts within FECFRAME and with respect= to the particular IPR declarations with associated licensing terms that ha= ve been made in FECFRAME. I know how some other IETF working groups h= ave dealt with this, and it seems to have come out both ways depending on t= he group and the licensing terms, but I’m not sure that FECFRAME has = had this discussion at the working group level to decide the path forward.<= BR>
Be assured I want to constructively discuss with you.
Best regards,

    Vincent

On 29/03/2010 18:54, Luby, Michael wrote:
> Some remarks below. (***)
> ________________________________________
> From: Vincent Roca [vincent.roca= @inrialpes.fr]
> Sent: Monday, March 29, 2010 6:32 AM
> To: Luby, Michael
> Cc: fecframe@ietf.org; housley@vigilsec.com; ipr-announce@ietf.org
> Subject: Re: Posting of IPR Disclosure related to QUALCOMM Incorporate= d's Statement about IPR related to draft-roca-fecframe-rs-02
>
> Hello Stephan and Mike,
>
>
> I think your emails deserve an answer.
> Generals considerations first, and then I'll focus on
> the specific point under discussion.
>
> --
>
> I'm also fed up with all these IPR issues that oblige me to
> leave my primary activities all too often. I'm researcher,
> not an IPR lawyer and I have no natural inclination for
> these legal aspects.
>
> That being said, I also want my work to be useful to the
> whole community (within or outside of the IETF, Nokia and
> QC included). From this point of view, if there's an IPR
> disclosure and if I have the feeling an alternative
> solution exists, I'll examine it instead of "passively
> accepting" the situation. In any case be assured my
> behavior is only governed by the desire to be useful to
> the community.
>
> *** There is IPR disclosures on many specifications within the IETF, a= nd the standards in which they exist are useful to the whole community. &nb= sp;Your premise is flawed, and thus much of the reasoning below.
>
> One big difference between you and me is the fact I don't
> have any legal department in charge of examining IPR
> aspects. If my documents are subject of a disclosure, I
> can either ignore it (as many colleagues do) or tackle
> its analysis. If I want to achieve my above goal of being
> useful to the community, this second option is the only
> possible.
>
> Yes, I'd like we could all work just like 30-40 years ago,
> when smart people were eager to design the best possible
> Internet, using the best possible techniques, just because
> it was the right answer to the situation. It's worth
> remembering this heritage. It's perhaps an utopia
> today, however I'm doing my best to stick with this
> philosophy since I currently have the freedom to do
> that.
>
> *** Much of the best technology used on the Internet has/had IPR, incl= uding Reed-Solomon codes, all video codecs, etc.
>
> Finally, you can find many examples of WGs going into this
> kind of discussion, e.g. in the informational RFC 3669
> (https://datatra= cker.ietf.org/doc/rfc3669/).
> A few excerpts of the lessons learned:
>
>     o IPR claims should never be disregarded= without good cause. Due
>        diligence should be done to = understand the consequences of each
>        claim.
> [...]
>     o It's sometimes beneficial to push IPR = claimants to find out what
>        they think their claims cove= r and what their licensing terms are.
>
>     o Possibilities of prior art should be c= onsidered.
>
>     o It's all right, and sometimes benefici= al, to discuss IPR claims
>        and gather information about= possible prior art on the group list.
>        The results of such discussi= on can be considered when deciding
>        whether to develop a technol= ogy (but remember that neither the
>        IETF nor any working group t= akes a stand on such claims as a body,
>        and the group is not the bes= t place to get legal advice).
>
> The above sentences are not definite rules, of course, and
> each situation is specific and needs to be handled
> appropriately. However saying that "[the FECFRAME mailing
> list] is not the forum to discuss specific IPR" is a
> personal interpretation that is in-line with the IETF
> practices.
>
>
> --
>
> Now, concerning the topic that triggered this discussion:
>
> - I've updated the I-D and in theory it's sufficient for
>    QC to be aware of our attempts to solve the problem;=
> - However I explicitly told Mike what we've done and
>    asked him to clarify QC's position. No answer;
> - I met Mike just before the fecframe meeting and asked
>    again the same question. Unless I misunderstood what= he
>    said, I didn't get any answer;
>
> *** You got an answer, which I'll repeat here: the one issue that we d= iscussed previously was addressed, but there are other issues which we have= identified that still need to be considered and addressed.
>
> - the situation was once again explained in my slides.
>
>   I was not there unfortunately, but I didn't see
>    anything in the Minutes;
> - And then came this new IPR disclosure that completely
>    ignores any effort I've made to try understand the >    situation and to solve it.
>
> *** The main change to the new IPR disclosures (and we updated them al= l in RMT and FECFRAME, not just this one) compared to previous is the licen= sing terms, that rationally should put the whole issue to rest. Clear= ly, this didn't mollify you, as it seems that any IPR, even if the licensin= g terms are quite quite favorable, is unacceptable in your opinion. H= owever, during the course of the IPR update process, we did reexamine the s= pec and understood that there were still some technical issues with the cur= rent draft that probably would have to be changed to be clear of the partic= ular IPR that is declared on the current draft. If I remember correct= ly, you also mentioned that you would be adding some new elements to the ne= xt version of the draft, and be aware and forewarned that these will also h= ave to be carefully scrutinized, as part of our obligations, to see if ther= e is any necessity to declare additional IPR.
>
> At this point, I'm now wondering if QC's strategy is not
> to leave this point open until everybody forget? Anyway,
> if QC does not want to answer, I want it to be clearly
> stated and justified. How long it will take me to have
> this clarification is not under my control.
>
> *** This is not nor ever has been QC strategy.
>
> I'm not responsible of the whole story. Especially as
> last year I even made sure that there was no IPR issue
> in FECFRAME. Now DF/QC chose the submarine patent
> approach ("undisclosed pending patent") and to keep it
> secret till it's granted, last month. It's their right but me > and my co-authors are the victims in this story.
>
> *** It was not a submarine patent, and it is dangerous to allege this.=
>
>
> Last but not least...
> In all my emails exchanges, I pay attention not to offend
> anybody. I don't have the feeling that any email I sent
> (including this one) was offending, but if somebody has a
> different feeling, then I apologize since this was not my
> goal.
>
> Sorry for this very long email. I hope that you now better
> understand my attitude. Stephan, if you are not interested
> by my IPR-related emails, which I can understand, then
> please ignore them.
>
> And long life to the IETF that already enabled me to solve
> similar issues, without having to waste time, energy and
> money in a court, whereas a consensus was easily achievable
> as long as both parties are working toward this goal. Last
> Autumn discussion with Mike on the RMT mailing list proved
> it's possible. Thanks!
>
> *** Nothing was achieved in RMT in my opinion. That was a huge w= aste of time and energy in my opinion to try and resolve the situation, and= didn't achieve anything, as still it is the case that QC has declared IPR = on some of your drafts and you have declared loudly and publicly in many fo= rums that this is not the case. How is that a good resolution?
>
> Best regards,
>
>
>      Vincent
>
>
>
> On 26/03/2010 02:19, Luby, Michael wrote:
> All,
> I agree with and respect Stephan’s remarks, this is not the foru= m to discuss specific IPR.
> Mike
>
>
> On 3/25/10 1:18 PM, "Vincent Roca"<vincent.roca@inrialpes.fr> wrote:
>
> Mike,
>
> I discover that QC just updated its previous IPR disclosure
> against our I-D in:    https://datatracker.ietf.org/ipr/1288/
>
> This disclosure refers to draft-roca-fecframe-rs-02, i.e. the
> latest version where we tried to solve the potential IPR issue
> as I explained to you in my previous emails (sent before the
> IPR disclosure update):
> http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.ht= ml
>
> So I take it as QC's official answer: the issue is not solved in
> -02 version according to QC!
>
>
> Since it seems I have no choice, let's put everything on the
> table:
>
> ** Concerning US Patent 7,660,245:
> This patent has three independent claims: 1, 16 and 18.
> *All of them* are restricted to situations where different source
> packets contribute to a different number of source symbols.
> Unless we forgot something, we removed from our I-D all
> references to this technique, which is sufficient to conclude that
> version -02 cannot infringe US Patent 7,660,245.
>
> ** Concerning Patent 20100050057:
> This patent has four independent claims: 1, 10, 16 and 24.
> *All of them* are restricted to situations where different source
> packets contribute to a different number of source symbols, so
> my answer is exactly the same.
>
>
> I'd like to understand. *I am doing significant efforts but
> I now have the feeling this is not reciprocal.* What's wrong?
> I need an answer.
>
>
> Regards,
>
>    Vincent
>
>
> On 25/03/10 18:08, IETF Secretariat wrote:
>
>> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunch= e, Amine Bouabdallah:
>>
>> An IPR disclosure that pertains to your Internet-Draft entitled &q= uot;Reed-Solomon
>> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-r= oca-fecframe-rs)
>> was submitted to the IETF Secretariat on 2010-03-18 and has been p= osted on the
>> "IETF Page of Intellectual Property Rights Disclosures"<= BR> >> (https://datatr= acker.ietf.org/ipr/1288/). The title of the IPR disclosure is
>> "QUALCOMM Incorporated's Statement about IPR related to
>> draft-roca-fecframe-rs-02."
>>
>> The IETF Secretariat
>>

--_000_C7E273D1D2EDlubyqualcommcom_-- From vincent.roca@inrialpes.fr Tue Apr 13 05:25:54 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C00593A6826; Tue, 13 Apr 2010 05:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[AWL=-2.029, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXnVGaL0ibP2; Tue, 13 Apr 2010 05:25:40 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id B9D243A67A2; Tue, 13 Apr 2010 05:25:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.52,197,1270418400"; d="scan'208,217";a="56962389" Received: from vpnloria27.inrialpes.fr (HELO visiteur10.visiteurs.inrialpes.fr) ([194.199.16.155]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 13 Apr 2010 14:25:29 +0200 Message-ID: <4BC462B8.8030307@inrialpes.fr> Date: Tue, 13 Apr 2010 14:25:28 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "housley@vigilsec.com" , "ipr-announce@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 12:25:54 -0000 Mike, all,

>     (ML) As a general policy (at both DF and QC), we declare IPR
> on an IETF draft/RFC if there is some inventive element described
> in the draft/RFC that was previously described in the
> specification of an active patent, where we feel that the element
> could be the basis of a claim. Otherwise, if we waited till we
> actually had filed an additional patent with the particular claim
> based on the original patent specification and then after that
> declared IPR on an IETF draft/RFC, it might be perceived as a
> submarine declaration.

Okay, I agree with this position in general.

I also understand you're acknowledging the fact version -02 has
definitively solved any issue W.R.T. the *claims* of the two
patents mentions in the IPR disclosure. Good.

Two additional comments:
- Your position makes sense iff you let the authors know the exact
situation, i.e. the fact their document may infringe a *future*
patent, continuation of the one being listed in the IPR disclosure,
without necessarily infringing any existing claim.
In our case, it was not clear until recently and from this point
of view, our discussion was more than required.

- without any further information from your side, the situation is
rather unhealthy, since we, the authors, have no objective way
to determine:
(1) what are the "inventive elements" of the patent description
that will be the basis of futures claims in future patent
application(s), and
(2) the context under which you these claims will apply, which
is equally important.

>     (ML) Given this, there are other elements, for example in U.S.
> Patent 7660245, that are also included in draft-roca-fecframe-rs-02.
> As an example of such an element, placing the SBL in the repair
> packet FEC Payload ID but not in the source packet FEC Payload ID
> is described in some detail in U.S. Patent 7660245, and the
> advantages of doing this are well-described in U.S. Patent 7660245,
> but this particular element is not necessarily the basis of a claim
> in U.S. Patent 7660245. However, this element is included in
> draft-roca-fecframe-rs-02. There are potentially other elements
> that are similar, that I would be willing to work with you offline
> to identify and remove from the newer versions of
> draft-roca-fecframe-rs-02, if this is the path that you and the
> FECFRAME working group decide to take.

We are making progress... Of course I accept your proposal.
Let's discuss off-list and come back with an analysis of the
situation. And if anybody is interested, he can join the
discussion.

>     (ML) Here is an extract from the email that David Harrington
> recently sent out: “Recognize that IPR claims might appear at
> any time during the life of a standard, so trying to pick a design
> that has **no** IPR encumbrances might not be successful. Deciding
> whether the licensing terms mitigate the impact of the declared
> IPR might be a better use of the WG's time. But that is a WG's
> decision, as reflected in RFC3669.” That was my point.

I think the authors (and the WG) do not have the needed elements
(e.g. the exhaustive list of techniques that might infringe
future QC patents). This is IMHO a prerequisite to judge whether
or not the current licensing terms mitigate or not the situation.
Besides, we are still in an early phase of the IETF work, and
changing the I-D content, even significantly, is usual, no matter
the reasons. This is my point.

And of course, as David H. reminded us, IPR disclosures from
other companies might appear in the future. But it's a different topic.

Regards,

   Vincent

On 08/04/10 02:39, Luby, Michael wrote:

Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 FECFRAME working group,
Vincent has made some points below to which I have responded below (ML). On some of these points I think it would be useful to have other inputs from other members of the FECFRAME working group, or those interested in IPR issues in general, rather than have this be just a dialog between two people.
Thanks, Mike

On 4/1/10 8:18 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote:

Mike,

My intent has never been to convince QC of the negative
impacts of patents ;-), therefore I'll just focus on the main
topic.

I see good points in your answer, In particular when you
say:

> *** You got an answer, which I'll repeat here: the one issue
> that we discussed previously was addressed, but there are other
> issues which we have identified that still need to be
> considered and addressed.

This is exactly my goal: *consider and address the other
issues*. I want to understand the situation. According to
what I can read, version 02 of our I-D cannot infringe any
claim of the two patents since the 7 independent claims
all require that "the first number of source symbols is
different from the second number of source symbols".
This is no longer the case in -02. If I'm wrong, where's
my mistake? Which claim(s) do you think version 02
infringes? I want to understand your point of view.

(ML) As a general policy (at both DF and QC), we declare IPR on an IETF draft/RFC if there is some inventive element described in the draft/RFC that was previously described in the specification of an active patent, where we feel that the element could be the basis of a claim. Otherwise, if we waited till we actually had filed an additional patent with the particular claim based on the original patent specification and then after that declared IPR on an IETF draft/RFC, it might be perceived as a submarine declaration.

(ML) Given this, there are other elements, for example in U.S. Patent 7660245, that are also included in draft-roca-fecframe-rs-02. As an example of such an element, placing the SBL in the repair packet FEC Payload ID but not in the source packet FEC Payload ID is described in some detail in U.S. Patent 7660245, and the advantages of doing this are well-described in U.S. Patent 7660245, but this particular element is not necessarily the basis of a claim in U.S. Patent 7660245. However, this element is included in draft-roca-fecframe-rs-02. There are potentially other elements that are similar, that I would be willing to work with you offline to identify and remove from the newer versions of draft-roca-fecframe-rs-02, if this is the path that you and the FECFRAME working group decide to take.

Concerning our discussion in RMT last Autumn, I cant'
follow you when you say:

> *** Nothing was achieved in RMT in my opinion. That was
> a huge waste of time and energy in my opinion to try and
> resolve the situation, and didn't achieve anything, as still
> it is the case that QC has declared IPR on some of your drafts
> and you have declared loudly and publicly in many forums that
> this is not the case. How is that a good resolution?

The one and only reason that led QC to add 10 patents
to its IPR disclosure against RFC 5170 is now known.
Since the technique that infringes these patents (i.e.
"having several symbols per packet") is not mandatory
to use, a user can decide whether it's worth using it or
not. If it is a waste of time from your point of view,
I don't think you'll find many potential users who agree.

Here also we see how "unpublished pending patents"
can badly interfere with IETF activities. If Digital
Fountain had clarified the issue since the beginning
(i.e. in December 2007, after IPR Disclosure #908)
and pointed out to us where the problem was, the
offending technique would have been removed before the
RFC is published (as I said this technique is not
essential and we can, by increasing the matrix density,
achieve good erasure recovery performances even for
small blocks).

(ML) There is still an IPR declaration against RFC 5170 that was not resolved and I imagine will not be resolved, since for whatever reason you have decided that it is ok not to try and remove that IPR from the RFC 5170. So, in my mind, resolving one portion of an IPR declaration but still having other IPR declared that is not resolved doesn’t really help, since the basic situation is the same: there is still IPR declared on RFC 5170.

This is precisely why I want to clarify the situation
today W.R.T. our FECFRAME I-D.

Another point which is, for the moment, of secondary
importance IMHO, even if you mentioned it:

> *** The main change to the new IPR disclosures (and we
> updated them all in RMT and FECFRAME, not just this one)
> compared to previous is the licensing terms, that
> rationally should put the whole issue to rest. Clearly,
> this didn't mollify you, as it seems that any IPR, even
> if the licensing terms are quite quite favorable, is
> unacceptable in your opinion.

At this step of the discussion, we must focus on the
main questions: does this I-D infringe any claim?
Why? Are there alternatives? Is there any penalty in
considering these alternatives, if any?

You are trying to reverse the reasoning. This is a
mistake IMHO. Licensing conditions are one of the
elements to consider once we all perfectly understand
the situation, not before.

(ML) Here is an extract from the email that David Harrington recently sent out: “Recognize that IPR claims might appear at any time during the life of a standard, so trying to pick a design that has **no** IPR encumbrances might not be successful. Deciding whether the licensing terms mitigate the impact of the declared IPR might be a better use of the WG's time. But that is a WG's decision, as reflected in RFC3669.” That was my point.

Anyway licensing conditions are never definitive and
can be changed at any time (and it already happened 3
times with RFC 5170!).

(ML) True about the changes in licensing conditions/terms, and this has been true for all relevant drafts/RFCs in both RMT and FECFRAME with respect to DF/QC IPR declarations, but each time they have changed they have become more favorable, to the point that the licensing terms have become very favorable at this point. Thus, a general question for FECFRAME: Is it better to have drafts/RFCs with no currently known IPR declarations at the expense of possibly not as good drafts/RFCs in terms of the technology capabilities and efficiencies, or is it better to have drafts/RFCs with IPR declarations with favorable licensing terms with the advantage of having better drafts/RFCs in terms of the technology capabilities and efficiencies? This is not an abstract question: this is a question specifically in the context of this and other drafts within FECFRAME and with respect to the particular IPR declarations with associated licensing terms that have been made in FECFRAME. I know how some other IETF working groups have dealt with this, and it seems to have come out both ways depending on the group and the licensing terms, but I’m not sure that FECFRAME has had this discussion at the working group level to decide the path forward.

Be assured I want to constructively discuss with you.
Best regards,

    Vincent

On 29/03/2010 18:54, Luby, Michael wrote:
> Some remarks below. (***)
> ________________________________________
> From: Vincent Roca [vincent.roca@inrialpes.fr]
> Sent: Monday, March 29, 2010 6:32 AM
> To: Luby, Michael
> Cc: fecframe@ietf.org; housley@vigilsec.com; ipr-announce@ietf.org
> Subject: Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02
>
> Hello Stephan and Mike,
>
>
> I think your emails deserve an answer.
> Generals considerations first, and then I'll focus on
> the specific point under discussion.
>
> --
>
> I'm also fed up with all these IPR issues that oblige me to
> leave my primary activities all too often. I'm researcher,
> not an IPR lawyer and I have no natural inclination for
> these legal aspects.
>
> That being said, I also want my work to be useful to the
> whole community (within or outside of the IETF, Nokia and
> QC included). From this point of view, if there's an IPR
> disclosure and if I have the feeling an alternative
> solution exists, I'll examine it instead of "passively
> accepting" the situation. In any case be assured my
> behavior is only governed by the desire to be useful to
> the community.
>
> *** There is IPR disclosures on many specifications within the IETF, and the standards in which they exist are useful to the whole community. Your premise is flawed, and thus much of the reasoning below.
>
> One big difference between you and me is the fact I don't
> have any legal department in charge of examining IPR
> aspects. If my documents are subject of a disclosure, I
> can either ignore it (as many colleagues do) or tackle
> its analysis. If I want to achieve my above goal of being
> useful to the community, this second option is the only
> possible.
>
> Yes, I'd like we could all work just like 30-40 years ago,
> when smart people were eager to design the best possible
> Internet, using the best possible techniques, just because
> it was the right answer to the situation. It's worth
> remembering this heritage. It's perhaps an utopia
> today, however I'm doing my best to stick with this
> philosophy since I currently have the freedom to do
> that.
>
> *** Much of the best technology used on the Internet has/had IPR, including Reed-Solomon codes, all video codecs, etc.
>
> Finally, you can find many examples of WGs going into this
> kind of discussion, e.g. in the informational RFC 3669
> (https://datatracker.ietf.org/doc/rfc3669/).
> A few excerpts of the lessons learned:
>
>     o IPR claims should never be disregarded without good cause. Due
>        diligence should be done to understand the consequences of each
>        claim.
> [...]
>     o It's sometimes beneficial to push IPR claimants to find out what
>        they think their claims cover and what their licensing terms are.
>
>     o Possibilities of prior art should be considered.
>
>     o It's all right, and sometimes beneficial, to discuss IPR claims
>        and gather information about possible prior art on the group list.
>        The results of such discussion can be considered when deciding
>        whether to develop a technology (but remember that neither the
>        IETF nor any working group takes a stand on such claims as a body,
>        and the group is not the best place to get legal advice).
>
> The above sentences are not definite rules, of course, and
> each situation is specific and needs to be handled
> appropriately. However saying that "[the FECFRAME mailing
> list] is not the forum to discuss specific IPR" is a
> personal interpretation that is in-line with the IETF
> practices.
>
>
> --
>
> Now, concerning the topic that triggered this discussion:
>
> - I've updated the I-D and in theory it's sufficient for
>    QC to be aware of our attempts to solve the problem;
> - However I explicitly told Mike what we've done and
>    asked him to clarify QC's position. No answer;
> - I met Mike just before the fecframe meeting and asked
>    again the same question. Unless I misunderstood what he
>    said, I didn't get any answer;
>
> *** You got an answer, which I'll repeat here: the one issue that we discussed previously was addressed, but there are other issues which we have identified that still need to be considered and addressed.
>
> - the situation was once again explained in my slides.
>
>   I was not there unfortunately, but I didn't see
>    anything in the Minutes;
> - And then came this new IPR disclosure that completely
>    ignores any effort I've made to try understand the
>    situation and to solve it.
>
> *** The main change to the new IPR disclosures (and we updated them all in RMT and FECFRAME, not just this one) compared to previous is the licensing terms, that rationally should put the whole issue to rest. Clearly, this didn't mollify you, as it seems that any IPR, even if the licensing terms are quite quite favorable, is unacceptable in your opinion. However, during the course of the IPR update process, we did reexamine the spec and understood that there were still some technical issues with the current draft that probably would have to be changed to be clear of the particular IPR that is declared on the current draft. If I remember correctly, you also mentioned that you would be adding some new elements to the next version of the draft, and be aware and forewarned that these will also have to be carefully scrutinized, as part of our obligations, to see if there is any necessity to declare additional IPR.
>
> At this point, I'm now wondering if QC's strategy is not
> to leave this point open until everybody forget? Anyway,
> if QC does not want to answer, I want it to be clearly
> stated and justified. How long it will take me to have
> this clarification is not under my control.
>
> *** This is not nor ever has been QC strategy.
>
> I'm not responsible of the whole story. Especially as
> last year I even made sure that there was no IPR issue
> in FECFRAME. Now DF/QC chose the submarine patent
> approach ("undisclosed pending patent") and to keep it
> secret till it's granted, last month. It's their right but me
> and my co-authors are the victims in this story.
>
> *** It was not a submarine patent, and it is dangerous to allege this.
>
>
> Last but not least...
> In all my emails exchanges, I pay attention not to offend
> anybody. I don't have the feeling that any email I sent
> (including this one) was offending, but if somebody has a
> different feeling, then I apologize since this was not my
> goal.
>
> Sorry for this very long email. I hope that you now better
> understand my attitude. Stephan, if you are not interested
> by my IPR-related emails, which I can understand, then
> please ignore them.
>
> And long life to the IETF that already enabled me to solve
> similar issues, without having to waste time, energy and
> money in a court, whereas a consensus was easily achievable
> as long as both parties are working toward this goal. Last
> Autumn discussion with Mike on the RMT mailing list proved
> it's possible. Thanks!
>
> *** Nothing was achieved in RMT in my opinion. That was a huge waste of time and energy in my opinion to try and resolve the situation, and didn't achieve anything, as still it is the case that QC has declared IPR on some of your drafts and you have declared loudly and publicly in many forums that this is not the case. How is that a good resolution?
>
> Best regards,
>
>
>      Vincent
>
>
>
> On 26/03/2010 02:19, Luby, Michael wrote:
> All,
> I agree with and respect Stephan’s remarks, this is not the forum to discuss specific IPR.
> Mike
>
>
> On 3/25/10 1:18 PM, "Vincent Roca"<vincent.roca@inrialpes.fr> wrote:
>
> Mike,
>
> I discover that QC just updated its previous IPR disclosure
> against our I-D in:    https://datatracker.ietf.org/ipr/1288/
>
> This disclosure refers to draft-roca-fecframe-rs-02, i.e. the
> latest version where we tried to solve the potential IPR issue
> as I explained to you in my previous emails (sent before the
> IPR disclosure update):
> http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html
>
> So I take it as QC's official answer: the issue is not solved in
> -02 version according to QC!
>
>
> Since it seems I have no choice, let's put everything on the
> table:
>
> ** Concerning US Patent 7,660,245:
> This patent has three independent claims: 1, 16 and 18.
> *All of them* are restricted to situations where different source
> packets contribute to a different number of source symbols.
> Unless we forgot something, we removed from our I-D all
> references to this technique, which is sufficient to conclude that
> version -02 cannot infringe US Patent 7,660,245.
>
> ** Concerning Patent 20100050057:
> This patent has four independent claims: 1, 10, 16 and 24.
> *All of them* are restricted to situations where different source
> packets contribute to a different number of source symbols, so
> my answer is exactly the same.
>
>
> I'd like to understand. *I am doing significant efforts but
> I now have the feeling this is not reciprocal.* What's wrong?
> I need an answer.
>
>
> Regards,
>
>    Vincent
>
>
> On 25/03/10 18:08, IETF Secretariat wrote:
>
>> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine Bouabdallah:
>>
>> An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Solomon
>> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe-rs)
>> was submitted to the IETF Secretariat on 2010-03-18 and has been posted on the
>> "IETF Page of Intellectual Property Rights Disclosures"
>> (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure is
>> "QUALCOMM Incorporated's Statement about IPR related to
>> draft-roca-fecframe-rs-02."
>>
>> The IETF Secretariat
>>

From gjshep@gmail.com Wed Apr 14 10:07:41 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE26D3A6804 for ; Wed, 14 Apr 2010 10:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X8uJObSdwtY for ; Wed, 14 Apr 2010 10:07:40 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id E38A33A6359 for ; Wed, 14 Apr 2010 10:07:40 -0700 (PDT) Received: by pwj2 with SMTP id 2so318779pwj.31 for ; Wed, 14 Apr 2010 10:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:received :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=axuqRjbEfkPj5Cd4E187O0fvXX3F6E9iMtqDCG3Acp4=; b=ibYjelyfsHSf+wprrb7B8AkNCfYnuSxT7XATNWho4lVS28qtCnqLJ0IFBYHgEGdTxQ ky+cKAcOmG3TCcKUTDzoNSCV5kaL/8xn1hOTnUB+fZMWEyPwymvGBoeQAs8pThYj5PmC AGtd8QWp4Se2ArBV5YOqYfw6HK6mY7ALBdKJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; b=SXM+0fAygm/tHbTP8F3Z1/daZyO50gHWqg9b6PzGFrOUUz/pegFA4joLis6oyi/LHr ZFKePXfhMfV/kmrI3ZOfnG2fiJB43NkSsev/0PnLyStYNvKnqv/JHvrNY2GbsleMKmIV VS5OeQpXczSUUB/QqMsd64u6M980o8Cf8BaYA= MIME-Version: 1.0 Received: by 10.231.145.65 with HTTP; Wed, 14 Apr 2010 10:07:32 -0700 (PDT) Date: Wed, 14 Apr 2010 10:07:32 -0700 Received: by 10.115.39.21 with SMTP id r21mr7201007waj.155.1271264852330; Wed, 14 Apr 2010 10:07:32 -0700 (PDT) Message-ID: From: Greg Shepherd To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 17:07:42 -0000 Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have no corrections to the document please send to the list your approval of the document as is. And let's do this quickly. Please send comments to the list by end-of-day Friday, April 23. Thanks!, Greg On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) w= rote: > This revision simply fixed the boilerplate. No other changes. Could we ru= n the 2nd wglc on this draft? > > Thanks, > -acbegen > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Sunday, April 04, 2010 3:29 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for draft-ietf-fecframe-sdp-elements-05 > > > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has been su= ccessfully submitted by Ali Begen and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-ietf-fecframe-sdp-elements > Revision: =A0 =A0 =A0 =A005 > Title: =A0 =A0 =A0 =A0 =A0 SDP Elements for FEC Framework > Creation_date: =A0 2010-04-04 > WG ID: =A0 =A0 =A0 =A0 =A0 fecframe > Number_of_pages: 21 > > Abstract: > This document specifies the use of Session Description Protocol (SDP) > to describe the parameters required to signal the Forward Error > Correction (FEC) Framework Configuration Information between the > sender(s) and receiver(s). =A0This document also provides examples that > show the semantics for grouping multiple source and repair flows > together for the applications that simultaneously use multiple > instances of the FEC Framework. > > > > The IETF Secretariat. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From gjshep@gmail.com Tue Apr 20 10:43:35 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82F5628C180 for ; Tue, 20 Apr 2010 10:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7qoeUP-fwcW for ; Tue, 20 Apr 2010 10:43:34 -0700 (PDT) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id 3A4AA28C125 for ; Tue, 20 Apr 2010 10:43:32 -0700 (PDT) Received: by pzk12 with SMTP id 12so4487587pzk.32 for ; Tue, 20 Apr 2010 10:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MmxFlBgArqkb3wFNuegg/U5M6ZId/IW731PBUvUJYKE=; b=ar9ZLa2vbIyXPNRs+s0FnnlPPXjr591ozKurjpuS448WNzwntEaLbknkopdLLixHPw AMyvlBHMbX5LsY7Paia05vF39FCtupNyw8Rdtp1esOAqTiTTJgsm+0bP8bVwYg8thg6g PL3m63dvg6MHC+6b0uGV7PhnyX2p6MccTomjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; b=ZgBHHJZQL3+utBdn/PeTY+ShaUFzujHIHw+uThMJwGKEShgfyus0h5FzH02i5CsD1/ aLQnfSOC+9MV3RxgOI7OV4j/DENfV5SY2nEkKimJS9F4P4MlRwH6WPu/DqtfKDpKJN3e 7vzf7cS/YXR1gLhmJrbxAtIQ5dFxyWdZlsuMo= MIME-Version: 1.0 Received: by 10.142.144.4 with HTTP; Tue, 20 Apr 2010 10:43:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Apr 2010 10:43:20 -0700 Received: by 10.142.59.5 with SMTP id h5mr2974318wfa.185.1271785400994; Tue, 20 Apr 2010 10:43:20 -0700 (PDT) Message-ID: From: Greg Shepherd To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 17:43:35 -0000 Please folks!! We can't honestly progress this doc without feedback from the group. Read and respond this week and we can work toward completing this goals of this group and moving on. Thanks!, Greg On Wed, Apr 14, 2010 at 10:07 AM, Greg Shepherd wrote: > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 > > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have > no corrections to the document please send to the list your approval > of the document as is. > > And let's do this quickly. Please send comments to the list by > end-of-day Friday, April 23. > > Thanks!, > Greg > > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) = wrote: >> This revision simply fixed the boilerplate. No other changes. Could we r= un the 2nd wglc on this draft? >> >> Thanks, >> -acbegen >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: Sunday, April 04, 2010 3:29 PM >> To: Ali C. Begen (abegen) >> Subject: New Version Notification for draft-ietf-fecframe-sdp-elements-0= 5 >> >> >> A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has been s= uccessfully submitted by Ali Begen and posted to the IETF repository. >> >> Filename: =A0 =A0 =A0 =A0draft-ietf-fecframe-sdp-elements >> Revision: =A0 =A0 =A0 =A005 >> Title: =A0 =A0 =A0 =A0 =A0 SDP Elements for FEC Framework >> Creation_date: =A0 2010-04-04 >> WG ID: =A0 =A0 =A0 =A0 =A0 fecframe >> Number_of_pages: 21 >> >> Abstract: >> This document specifies the use of Session Description Protocol (SDP) >> to describe the parameters required to signal the Forward Error >> Correction (FEC) Framework Configuration Information between the >> sender(s) and receiver(s). =A0This document also provides examples that >> show the semantics for grouping multiple source and repair flows >> together for the applications that simultaneously use multiple >> instances of the FEC Framework. >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> > From orlyp@radvision.com Thu Apr 22 02:57:20 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C0CB3A677D for ; Thu, 22 Apr 2010 02:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wvxv79KkykU9 for ; Thu, 22 Apr 2010 02:57:19 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id C7FBF3A690C for ; Thu, 22 Apr 2010 02:57:18 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o3M9uGSt025788 for fecframe@ietf.org; Thu, 22 Apr 2010 12:56:16 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o3M9uGn9025780 for ; Thu, 22 Apr 2010 12:56:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Date: Thu, 22 Apr 2010 12:57:02 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Thread-Index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0Qg References: From: "Orly Peck" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id o3M9uGn9025780 Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 09:57:20 -0000 Hi, Here are my comments to draft-ietf-fecframe-sdp-elements-05: 1) section 4.6 - Repair Window - " Assuming that there is no issue of delay variation, the FEC decoder SHOULD NOT wait longer than the repair window since additional waiting would not help the recovery process." I think that the assumption that there is no issue of delay variation is irrelevant for most cases. I think the Repair Window should be defined (as I mentioned at the last IETF meeting) as the MINIMUM time that the receiver should wait for the repair packets, as the sender only knows the time that spans between the source packets and the generation of the repair packets. This comment was accepted also by Mark Watson for draft-ietf-fecframe-framework-05. 2) same section - typo: mismatchs = mismatches. Thanks, Orly Peck. -----Original Message----- From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg Shepherd Sent: Wednesday, April 14, 2010 8:08 PM To: Ali C. Begen (abegen) Cc: fecframe@ietf.org Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have no corrections to the document please send to the list your approval of the document as is. And let's do this quickly. Please send comments to the list by end-of-day Friday, April 23. Thanks!, Greg On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) wrote: > This revision simply fixed the boilerplate. No other changes. Could we run the 2nd wglc on this draft? > > Thanks, > -acbegen > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Sunday, April 04, 2010 3:29 PM > To: Ali C. Begen (abegen) > Subject: New Version Notification for draft-ietf-fecframe-sdp-elements-05 > > > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has been successfully submitted by Ali Begen and posted to the IETF repository. > > Filename: � � � �draft-ietf-fecframe-sdp-elements > Revision: � � � �05 > Title: � � � � � SDP Elements for FEC Framework > Creation_date: � 2010-04-04 > WG ID: � � � � � fecframe > Number_of_pages: 21 > > Abstract: > This document specifies the use of Session Description Protocol (SDP) > to describe the parameters required to signal the Forward Error > Correction (FEC) Framework Configuration Information between the > sender(s) and receiver(s). �This document also provides examples that > show the semantics for grouping multiple source and repair flows > together for the applications that simultaneously use multiple > instances of the FEC Framework. > > > > The IETF Secretariat. > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe From abegen@cisco.com Thu Apr 22 04:15:27 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BECA33A6A3C for ; Thu, 22 Apr 2010 04:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ga-AYpdSP54 for ; Thu, 22 Apr 2010 04:15:26 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B4DCD3A6AB1 for ; Thu, 22 Apr 2010 04:15:26 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAArNz0urR7Ht/2dsb2JhbACcInGjOppThQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,255,1270425600"; d="scan'208";a="186838600" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2010 11:15:17 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MBFHoD016528; Thu, 22 Apr 2010 11:15:17 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 04:15:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 04:15:16 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540BEE655B@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 thread-index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAARP8DA= References:

From: "Ali C. Begen (abegen)" To: "Orly Peck" , X-OriginalArrivalTime: 22 Apr 2010 11:15:17.0062 (UTC) FILETIME=[16554660:01CAE20D] Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:15:28 -0000 Thanks for the review. Good catch for both. Will make the changes after = wglc closes. -acbegen > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Orly Peck > Sent: Thursday, April 22, 2010 5:57 AM > To: fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > Hi, > Here are my comments to draft-ietf-fecframe-sdp-elements-05: >=20 > 1) section 4.6 - Repair Window - " Assuming that there is no issue of = delay variation, the FEC decoder > SHOULD NOT wait longer than the repair window since additional waiting = would not help the recovery > process." >=20 > I think that the assumption that there is no issue of delay variation = is irrelevant for most cases. > I think the Repair Window should be defined (as I mentioned at the = last IETF meeting) as the MINIMUM > time that the receiver should wait for the repair packets, as the = sender only knows the time that > spans between the source packets and the generation of the repair = packets. > This comment was accepted also by Mark Watson for = draft-ietf-fecframe-framework-05. >=20 > 2) same section - typo: mismatchs =3D mismatches. >=20 > Thanks, > Orly Peck. >=20 >=20 > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Wednesday, April 14, 2010 8:08 PM > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org > Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 >=20 > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have > no corrections to the document please send to the list your approval > of the document as is. >=20 > And let's do this quickly. Please send comments to the list by > end-of-day Friday, April 23. >=20 > Thanks!, > Greg >=20 > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) = wrote: > > This revision simply fixed the boilerplate. No other changes. Could = we run the 2nd wglc on this > draft? > > > > Thanks, > > -acbegen > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Sunday, April 04, 2010 3:29 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for = draft-ietf-fecframe-sdp-elements-05 > > > > > > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has = been successfully submitted by Ali > Begen and posted to the IETF repository. > > > > Filename: =A0 =A0 =A0 =A0draft-ietf-fecframe-sdp-elements > > Revision: =A0 =A0 =A0 =A005 > > Title: =A0 =A0 =A0 =A0 =A0 SDP Elements for FEC Framework > > Creation_date: =A0 2010-04-04 > > WG ID: =A0 =A0 =A0 =A0 =A0 fecframe > > Number_of_pages: 21 > > > > Abstract: > > This document specifies the use of Session Description Protocol = (SDP) > > to describe the parameters required to signal the Forward Error > > Correction (FEC) Framework Configuration Information between the > > sender(s) and receiver(s). =A0This document also provides examples = that > > show the semantics for grouping multiple source and repair flows > > together for the applications that simultaneously use multiple > > instances of the FEC Framework. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From csp@csperkins.org Thu Apr 22 07:40:52 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97203A6BAB for ; Thu, 22 Apr 2010 07:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBQzn8lX4nGw for ; Thu, 22 Apr 2010 07:40:51 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id F13CC28C1CF for ; Thu, 22 Apr 2010 07:37:12 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1O4xWY-00015U-jg; Thu, 22 Apr 2010 14:37:02 +0000 Message-Id: <2B082CC2-F95A-42D4-AC14-699A0421344A@csperkins.org> From: Colin Perkins To: gjshep@gmail.com In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Apr 2010 15:36:52 +0100 References: X-Mailer: Apple Mail (2.936) Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 14:40:52 -0000 A nit: the examples in section 5.3 include white-space between the FEC attribute names and their parameters, but the ABNF doesn't seem to allow this. Colin On 14 Apr 2010, at 18:07, Greg Shepherd wrote: > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 > > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have > no corrections to the document please send to the list your approval > of the document as is. > > And let's do this quickly. Please send comments to the list by > end-of-day Friday, April 23. > > Thanks!, > Greg > > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) > wrote: >> This revision simply fixed the boilerplate. No other changes. Could >> we run the 2nd wglc on this draft? >> >> Thanks, >> -acbegen >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: Sunday, April 04, 2010 3:29 PM >> To: Ali C. Begen (abegen) >> Subject: New Version Notification for draft-ietf-fecframe-sdp- >> elements-05 >> >> >> A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has >> been successfully submitted by Ali Begen and posted to the IETF >> repository. >> >> Filename: draft-ietf-fecframe-sdp-elements >> Revision: 05 >> Title: SDP Elements for FEC Framework >> Creation_date: 2010-04-04 >> WG ID: fecframe >> Number_of_pages: 21 >> >> Abstract: >> This document specifies the use of Session Description Protocol (SDP) >> to describe the parameters required to signal the Forward Error >> Correction (FEC) Framework Configuration Information between the >> sender(s) and receiver(s). This document also provides examples that >> show the semantics for grouping multiple source and repair flows >> together for the applications that simultaneously use multiple >> instances of the FEC Framework. >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe -- Colin Perkins http://csperkins.org/ From abegen@cisco.com Thu Apr 22 08:54:11 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223883A6BEA for ; Thu, 22 Apr 2010 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h40yiV0OKs0Q for ; Thu, 22 Apr 2010 08:54:10 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CA3133A6BB2 for ; Thu, 22 Apr 2010 08:54:09 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPsN0EurR7Ht/2dsb2JhbACcJ3GlM5pIhQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,257,1270425600"; d="scan'208";a="119167219" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2010 15:53:56 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MFrrPM023668; Thu, 22 Apr 2010 15:53:56 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 08:53:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 08:53:47 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540BEE65F3@xmb-sjc-215.amer.cisco.com> In-Reply-To: <2B082CC2-F95A-42D4-AC14-699A0421344A@csperkins.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 thread-index: AcriKUe3uwz7MubsRtSB3bsdCj5bIAACrAhw References: <2B082CC2-F95A-42D4-AC14-699A0421344A@csperkins.org> From: "Ali C. Begen (abegen)" To: "Colin Perkins" , X-OriginalArrivalTime: 22 Apr 2010 15:53:54.0677 (UTC) FILETIME=[02CEE250:01CAE234] Cc: fecframe@ietf.org Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 15:54:11 -0000 Good catch. Thanks and it is fixed. -acbegen > -----Original Message----- > From: Colin Perkins [mailto:csp@csperkins.org] > Sent: Thursday, April 22, 2010 10:37 AM > To: gjshep@gmail.com > Cc: Ali C. Begen (abegen); fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > A nit: the examples in section 5.3 include white-space between the FEC > attribute names and their parameters, but the ABNF doesn't seem to > allow this. >=20 > Colin >=20 >=20 >=20 > On 14 Apr 2010, at 18:07, Greg Shepherd wrote: > > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 > > > > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you = have > > no corrections to the document please send to the list your approval > > of the document as is. > > > > And let's do this quickly. Please send comments to the list by > > end-of-day Friday, April 23. > > > > Thanks!, > > Greg > > > > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) = > > wrote: > >> This revision simply fixed the boilerplate. No other changes. Could > >> we run the 2nd wglc on this draft? > >> > >> Thanks, > >> -acbegen > >> > >> -----Original Message----- > >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > >> Sent: Sunday, April 04, 2010 3:29 PM > >> To: Ali C. Begen (abegen) > >> Subject: New Version Notification for draft-ietf-fecframe-sdp- > >> elements-05 > >> > >> > >> A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has > >> been successfully submitted by Ali Begen and posted to the IETF > >> repository. > >> > >> Filename: draft-ietf-fecframe-sdp-elements > >> Revision: 05 > >> Title: SDP Elements for FEC Framework > >> Creation_date: 2010-04-04 > >> WG ID: fecframe > >> Number_of_pages: 21 > >> > >> Abstract: > >> This document specifies the use of Session Description Protocol = (SDP) > >> to describe the parameters required to signal the Forward Error > >> Correction (FEC) Framework Configuration Information between the > >> sender(s) and receiver(s). This document also provides examples = that > >> show the semantics for grouping multiple source and repair flows > >> together for the applications that simultaneously use multiple > >> instances of the FEC Framework. > >> > >> > >> > >> The IETF Secretariat. > >> > >> > >> _______________________________________________ > >> Fecframe mailing list > >> Fecframe@ietf.org > >> https://www.ietf.org/mailman/listinfo/fecframe > >> > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe >=20 >=20 >=20 > -- > Colin Perkins > http://csperkins.org/ >=20 >=20 From abegen@cisco.com Thu Apr 22 09:34:45 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE98928C185 for ; Thu, 22 Apr 2010 09:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.241 X-Spam-Level: X-Spam-Status: No, score=-10.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B7F4UJdwWlp for ; Thu, 22 Apr 2010 09:34:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 83D9C3A6A59 for ; Thu, 22 Apr 2010 09:33:51 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABwX0EurRN+J/2dsb2JhbACcJ3GmGppHhQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,257,1270425600"; d="scan'208";a="319531359" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2010 16:33:41 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3MGXflT019391; Thu, 22 Apr 2010 16:33:41 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 09:33:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 09:33:02 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6633@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 thread-index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhA= References:

From: "Ali C. Begen (abegen)" To: "Orly Peck" , X-OriginalArrivalTime: 22 Apr 2010 16:33:41.0916 (UTC) FILETIME=[91B6A5C0:01CAE239] Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:34:45 -0000 Is the WG happy with the text below? -acbegen An FEC encoder processes a block of source packets and generates a = number of repair packets, which are then transmitted within a certain = duration. At the receiver side, the FEC decoder tries to decode all the = packets received within the repair window to recover the missing = packets, if there are any. Repair window stands for the time that spans = the source packets and the corresponding repair packets. It defines the = minimum time which the receiver SHOULD wait for the repair packets. > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Orly Peck > Sent: Thursday, April 22, 2010 5:57 AM > To: fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > Hi, > Here are my comments to draft-ietf-fecframe-sdp-elements-05: >=20 > 1) section 4.6 - Repair Window - " Assuming that there is no issue of = delay variation, the FEC decoder > SHOULD NOT wait longer than the repair window since additional waiting = would not help the recovery > process." >=20 > I think that the assumption that there is no issue of delay variation = is irrelevant for most cases. > I think the Repair Window should be defined (as I mentioned at the = last IETF meeting) as the MINIMUM > time that the receiver should wait for the repair packets, as the = sender only knows the time that > spans between the source packets and the generation of the repair = packets. > This comment was accepted also by Mark Watson for = draft-ietf-fecframe-framework-05. >=20 > 2) same section - typo: mismatchs =3D mismatches. >=20 > Thanks, > Orly Peck. >=20 >=20 > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On = Behalf Of Greg Shepherd > Sent: Wednesday, April 14, 2010 8:08 PM > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org > Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 >=20 > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have > no corrections to the document please send to the list your approval > of the document as is. >=20 > And let's do this quickly. Please send comments to the list by > end-of-day Friday, April 23. >=20 > Thanks!, > Greg >=20 > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) = wrote: > > This revision simply fixed the boilerplate. No other changes. Could = we run the 2nd wglc on this > draft? > > > > Thanks, > > -acbegen > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Sunday, April 04, 2010 3:29 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for = draft-ietf-fecframe-sdp-elements-05 > > > > > > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has = been successfully submitted by Ali > Begen and posted to the IETF repository. > > > > Filename: =A0 =A0 =A0 =A0draft-ietf-fecframe-sdp-elements > > Revision: =A0 =A0 =A0 =A005 > > Title: =A0 =A0 =A0 =A0 =A0 SDP Elements for FEC Framework > > Creation_date: =A0 2010-04-04 > > WG ID: =A0 =A0 =A0 =A0 =A0 fecframe > > Number_of_pages: 21 > > > > Abstract: > > This document specifies the use of Session Description Protocol = (SDP) > > to describe the parameters required to signal the Forward Error > > Correction (FEC) Framework Configuration Information between the > > sender(s) and receiver(s). =A0This document also provides examples = that > > show the semantics for grouping multiple source and repair flows > > together for the applications that simultaneously use multiple > > instances of the FEC Framework. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Thu Apr 22 09:44:46 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 141DF3A6BFE for ; Thu, 22 Apr 2010 09:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5YC03Fc2Iii for ; Thu, 22 Apr 2010 09:44:42 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id CC49128C185 for ; Thu, 22 Apr 2010 09:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1271954652; x=1303490652; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20Orly =20Peck=0D=0A=09,=20"fecframe@ietf.o rg"=20|Date:=20Thu,=2022=20Apr=202010 =2009:44:08=20-0700|Subject:=20Re:=20[Fecframe]=20WGLC=20 -=20draft-ietf-fecframe-sdp-elements-05|Thread-Topic:=20[ Fecframe]=20WGLC=20-=20draft-ietf-fecframe-sdp-elements-0 5|Thread-Index:=20Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9 nZhAAAG4EDw=3D=3D|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D54 0BEE6633@xmb-sjc-215.amer.cisco.com>|Accept-Language:=20e n-US|Content-Language:=20en|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20multipart/alternative=3B=0D=0A=09boundar y=3D"_000_C7F5CAE8D9EDlubyqualcommcom_"|MIME-Version:=201 .0; bh=+1uinLJGoV4Fv/wlVywLl3HoAvPban6tcNzXMGI08Fc=; b=mTwNKne8cHagEcJZghyIxrz9uEbkV8BaiEUYdYdb7W4ThXOFBHgHMmQj Fk2jd4vMQUbsZhMyDScVn8y8gld/k3K4CvrseaFn/D/7IGdJEz4rAF9rL 4zQOLiL8+C8UMQf3IClfegl6sbYZH2J3AkLTvdHVA/j9gbrI+LRYMQbYI 8=; X-IronPort-AV: E=McAfee;i="5400,1158,5960"; a="39375804" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 22 Apr 2010 09:44:11 -0700 X-IronPort-AV: E=Sophos;i="4.52,257,1270450800"; d="scan'208,217";a="14618957" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 22 Apr 2010 09:44:11 -0700 Received: from nasanexhc07.na.qualcomm.com (172.30.39.6) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 22 Apr 2010 09:44:11 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhc07.na.qualcomm.com (172.30.39.6) with Microsoft SMTP Server (TLS) id 14.0.689.0; Thu, 22 Apr 2010 09:44:11 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 22 Apr 2010 09:44:11 -0700 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , Orly Peck , "fecframe@ietf.org" Date: Thu, 22 Apr 2010 09:44:08 -0700 Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Thread-Index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDw== Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6633@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7F5CAE8D9EDlubyqualcommcom_" MIME-Version: 1.0 Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:44:46 -0000 --_000_C7F5CAE8D9EDlubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Repair window from the receiver perspective doesn't seem very well defined = in this text. Is it specified somewhere else in the spec what the repair w= indow is from the receiver perspective, i.e., how does the receiver know wh= en the repair window starts and how does the receiver know the duration of = the repair window (is it signaled?). On 4/22/10 9:33 AM, "Ali C. Begen (abegen)" wrote: Is the WG happy with the text below? -acbegen An FEC encoder processes a block of source packets and generates a number o= f repair packets, which are then transmitted within a certain duration. At = the receiver side, the FEC decoder tries to decode all the packets received= within the repair window to recover the missing packets, if there are any.= Repair window stands for the time that spans the source packets and the co= rresponding repair packets. It defines the minimum time which the receiver = SHOULD wait for the repair packets. > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Beh= alf Of Orly Peck > Sent: Thursday, April 22, 2010 5:57 AM > To: fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > Hi, > Here are my comments to draft-ietf-fecframe-sdp-elements-05: > > 1) section 4.6 - Repair Window - " Assuming that there is no issue of del= ay variation, the FEC decoder > SHOULD NOT wait longer than the repair window since additional waiting wo= uld not help the recovery > process." > > I think that the assumption that there is no issue of delay variation is = irrelevant for most cases. > I think the Repair Window should be defined (as I mentioned at the last I= ETF meeting) as the MINIMUM > time that the receiver should wait for the repair packets, as the sender = only knows the time that > spans between the source packets and the generation of the repair packets= . > This comment was accepted also by Mark Watson for draft-ietf-fecframe-fra= mework-05. > > 2) same section - typo: mismatchs =3D mismatches. > > Thanks, > Orly Peck. > > > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Beh= alf Of Greg Shepherd > Sent: Wednesday, April 14, 2010 8:08 PM > To: Ali C. Begen (abegen) > Cc: fecframe@ietf.org > Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 > > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have > no corrections to the document please send to the list your approval > of the document as is. > > And let's do this quickly. Please send comments to the list by > end-of-day Friday, April 23. > > Thanks!, > Greg > > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) = wrote: > > This revision simply fixed the boilerplate. No other changes. Could we = run the 2nd wglc on this > draft? > > > > Thanks, > > -acbegen > > > > -----Original Message----- > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > Sent: Sunday, April 04, 2010 3:29 PM > > To: Ali C. Begen (abegen) > > Subject: New Version Notification for draft-ietf-fecframe-sdp-elements-= 05 > > > > > > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has been = successfully submitted by Ali > Begen and posted to the IETF repository. > > > > Filename: draft-ietf-fecframe-sdp-elements > > Revision: 05 > > Title: SDP Elements for FEC Framework > > Creation_date: 2010-04-04 > > WG ID: fecframe > > Number_of_pages: 21 > > > > Abstract: > > This document specifies the use of Session Description Protocol (SDP) > > to describe the parameters required to signal the Forward Error > > Correction (FEC) Framework Configuration Information between the > > sender(s) and receiver(s). This document also provides examples that > > show the semantics for grouping multiple source and repair flows > > together for the applications that simultaneously use multiple > > instances of the FEC Framework. > > > > > > > > The IETF Secretariat. > > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe _______________________________________________ Fecframe mailing list Fecframe@ietf.org https://www.ietf.org/mailman/listinfo/fecframe --_000_C7F5CAE8D9EDlubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Repair window from the receiver perspective doesn’t seem very w= ell defined in this text. Is it specified somewhere else in the spec = what the repair window is from the receiver perspective, i.e., how does the= receiver know when the repair window starts and how does the receiver know= the duration of the repair window (is it signaled?).

On 4/22/10 9:33 AM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

Is the WG happy with the text below?

-acbegen

An FEC encoder processes a block of source packets and generates a number o= f repair packets, which are then transmitted within a certain duration. At = the receiver side, the FEC decoder tries to decode all the packets received= within the repair window to recover the missing packets, if there are any.= Repair window stands for the time that spans the source packets and the co= rresponding repair packets. It defines the minimum time which the receiver = SHOULD wait for the repair packets.

> -----Original Message-----
> From: fecframe-bounces@ietf.org<= /a> [mailto:fecframe-bounces@i= etf.org] On Behalf Of Orly Peck
> Sent: Thursday, April 22, 2010 5:57 AM
> To: fecframe@ietf.org
> Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
>
> Hi,
> Here are my comments to draft-ietf-fecframe-sdp-elements-05:
>
> 1) section 4.6 - Repair Window - " Assuming that there is no issu= e of delay variation, the FEC decoder
> SHOULD NOT wait longer than the repair window since additional waiting= would not help the recovery
> process."
>
> I think that the assumption that there is no issue of delay variation = is irrelevant for most cases.
> I think the Repair Window should be defined (as I mentioned at the las= t IETF meeting) as the MINIMUM
> time that the receiver should wait for the repair packets, as the send= er only knows the time that
> spans between the source packets and the generation of the repair pack= ets.
> This comment was accepted also by Mark Watson for draft-ietf-fecframe-= framework-05.
>
> 2) same section - typo: mismatchs =3D mismatches.
>
> Thanks,
> Orly Peck.
>
>
> -----Original Message-----
> From: fecframe-bounces@ietf.org<= /a> [mailto:fecframe-bounces@i= etf.org] On Behalf Of Greg Shepherd
> Sent: Wednesday, April 14, 2010 8:08 PM
> To: Ali C. Begen (abegen)
> Cc: fecframe@ietf.org
> Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
>
> Working Group Last Call for draft-ietf-fecframe-sdp-elements-05
>
> PLEASE READ AND COMMENT. As I said in the WG meeting, even if you have=
> no corrections to the document please send to the list your approval > of the document as is.
>
> And let's do this quickly. Please send comments to the list by
> end-of-day Friday, April 23.
>
> Thanks!,
> Greg
>
> On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:
> > This revision simply fixed the boilerplate. No other changes. Cou= ld we run the 2nd wglc on this
> draft?
> >
> > Thanks,
> > -acbegen
> >
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> > Sent: Sunday, April 04, 2010 3:29 PM
> > To: Ali C. Begen (abegen)
> > Subject: New Version Notification for draft-ietf-fecframe-sdp-ele= ments-05
> >
> >
> > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has= been successfully submitted by Ali
> Begen and posted to the IETF repository.
> >
> > Filename: =A0 =A0 =A0 =A0draft-ietf-fecframe-sdp-elements
> > Revision: =A0 =A0 =A0 =A005
> > Title: =A0 =A0 =A0 =A0 =A0 SDP Elements for FEC Framework
> > Creation_date: =A0 2010-04-04
> > WG ID: =A0 =A0 =A0 =A0 =A0 fecframe
> > Number_of_pages: 21
> >
> > Abstract:
> > This document specifies the use of Session Description Protocol (= SDP)
> > to describe the parameters required to signal the Forward Error > > Correction (FEC) Framework Configuration Information between the<= BR> > > sender(s) and receiver(s). =A0This document also provides example= s that
> > show the semantics for grouping multiple source and repair flows<= BR> > > together for the applications that simultaneously use multiple > > instances of the FEC Framework.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> > _______________________________________________
> > Fecframe mailing list
> > Fecframe@ietf.org
> > https:= //www.ietf.org/mailman/listinfo/fecframe
> >
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www= .ietf.org/mailman/listinfo/fecframe
>
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www= .ietf.org/mailman/listinfo/fecframe
_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf= .org/mailman/listinfo/fecframe

--_000_C7F5CAE8D9EDlubyqualcommcom_-- From abegen@cisco.com Thu Apr 22 12:28:50 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76F263A68B3 for ; Thu, 22 Apr 2010 12:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.251 X-Spam-Level: X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1UHUxGDMOof for ; Thu, 22 Apr 2010 12:28:49 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 975753A6924 for ; Thu, 22 Apr 2010 12:12:07 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANc80EurR7Ht/2dsb2JhbACcJ3Gmepo5hQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,258,1270425600"; d="scan'208";a="119247296" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2010 19:11:52 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3MJBqTo016954; Thu, 22 Apr 2010 19:11:52 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 12:11:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 12:11:41 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 thread-index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDwAFFLjg References: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6633@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , "Orly Peck" , X-OriginalArrivalTime: 22 Apr 2010 19:11:52.0570 (UTC) FILETIME=[AA9585A0:01CAE24F] Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:28:50 -0000 I suppose the receiver can only start counting when it received the = first packet in a source block (it can make adjustments if there were = missing packets at the beginning of the block). And yes, this is specified in the SDP description. When it is signaled = there, the sender conforms to it and the receiver knows about it. -acbegen > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, April 22, 2010 12:44 PM > To: Ali C. Begen (abegen); Orly Peck; fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > Repair window from the receiver perspective doesn=92t seem very well = defined in this text. Is it > specified somewhere else in the spec what the repair window is from = the receiver perspective, i.e., > how does the receiver know when the repair window starts and how does = the receiver know the duration > of the repair window (is it signaled?). >=20 >=20 > On 4/22/10 9:33 AM, "Ali C. Begen (abegen)" wrote: >=20 >=20 >=20 > Is the WG happy with the text below? >=20 > -acbegen >=20 > An FEC encoder processes a block of source packets and generates a = number of repair packets, > which are then transmitted within a certain duration. At the receiver = side, the FEC decoder tries to > decode all the packets received within the repair window to recover = the missing packets, if there are > any. Repair window stands for the time that spans the source packets = and the corresponding repair > packets. It defines the minimum time which the receiver SHOULD wait = for the repair packets. >=20 > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On Behalf Of Orly Peck > > Sent: Thursday, April 22, 2010 5:57 AM > > To: fecframe@ietf.org > > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > > > Hi, > > Here are my comments to draft-ietf-fecframe-sdp-elements-05: > > > > 1) section 4.6 - Repair Window - " Assuming that there is no issue = of delay variation, the FEC > decoder > > SHOULD NOT wait longer than the repair window since additional = waiting would not help the > recovery > > process." > > > > I think that the assumption that there is no issue of delay = variation is irrelevant for most > cases. > > I think the Repair Window should be defined (as I mentioned at the = last IETF meeting) as the > MINIMUM > > time that the receiver should wait for the repair packets, as the = sender only knows the time > that > > spans between the source packets and the generation of the repair = packets. > > This comment was accepted also by Mark Watson for = draft-ietf-fecframe-framework-05. > > > > 2) same section - typo: mismatchs =3D mismatches. > > > > Thanks, > > Orly Peck. > > > > > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] = On Behalf Of Greg Shepherd > > Sent: Wednesday, April 14, 2010 8:08 PM > > To: Ali C. Begen (abegen) > > Cc: fecframe@ietf.org > > Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > > > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 > > > > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you = have > > no corrections to the document please send to the list your = approval > > of the document as is. > > > > And let's do this quickly. Please send comments to the list by > > end-of-day Friday, April 23. > > > > Thanks!, > > Greg > > > > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) = wrote: > > > This revision simply fixed the boilerplate. No other changes. = Could we run the 2nd wglc on > this > > draft? > > > > > > Thanks, > > > -acbegen > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: Sunday, April 04, 2010 3:29 PM > > > To: Ali C. Begen (abegen) > > > Subject: New Version Notification for = draft-ietf-fecframe-sdp-elements-05 > > > > > > > > > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt has = been successfully > submitted by Ali > > Begen and posted to the IETF repository. > > > > > > Filename: draft-ietf-fecframe-sdp-elements > > > Revision: 05 > > > Title: SDP Elements for FEC Framework > > > Creation_date: 2010-04-04 > > > WG ID: fecframe > > > Number_of_pages: 21 > > > > > > Abstract: > > > This document specifies the use of Session Description Protocol = (SDP) > > > to describe the parameters required to signal the Forward Error > > > Correction (FEC) Framework Configuration Information between the > > > sender(s) and receiver(s). This document also provides examples = that > > > show the semantics for grouping multiple source and repair flows > > > together for the applications that simultaneously use multiple > > > instances of the FEC Framework. > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 >=20 From luby@qualcomm.com Thu Apr 22 12:29:27 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779E43A69D5 for ; Thu, 22 Apr 2010 12:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuQlllMzO4RO for ; Thu, 22 Apr 2010 12:29:23 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 3FD1128C24F for ; Thu, 22 Apr 2010 12:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1271963614; x=1303499614; h=from:to:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version; z=From:=20"Luby,=20Michael"=20|To:=20"A li=20C.=20Begen=20(abegen)"=20,=20Orly =20Peck=0D=0A=09,=20"fecframe@ietf.o rg"=20|Date:=20Thu,=2022=20Apr=202010 =2012:13:30=20-0700|Subject:=20Re:=20[Fecframe]=20WGLC=20 -=20draft-ietf-fecframe-sdp-elements-05|Thread-Topic:=20[ Fecframe]=20WGLC=20-=20draft-ietf-fecframe-sdp-elements-0 5|Thread-Index:=20Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9 nZhAAAG4EDwAFFLjgAAAiucE=3D|Message-ID:=20|In-Reply-To:=20<04CAD96D4C5A3D48B19192 48A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com> |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C7F5EDEADA17lubyqualcommcom_" |MIME-Version:=201.0; bh=xBZkyvh9/ilI1Z3CbbaxPyCesPjHdKAES6U1jHLYnY4=; b=xBY6y4WvmjoZRDyoI697YaCA0/gETfR0+laRfnWG/FXAPE3REIpkengR OVTfJm8z8jvKgjBy3m3Xvom5mtZBfrVutLUB7ETUQCpZW5i78R9OUX7ds fUqi3gDiJmhPtV/3RSaKwnB8cy06ykQGQj4zcKcWHjmWpB3MP0gDndJba A=; X-IronPort-AV: E=McAfee;i="5400,1158,5960"; a="39387729" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine02.qualcomm.com with ESMTP; 22 Apr 2010 12:13:34 -0700 X-IronPort-AV: E=Sophos;i="4.52,254,1270450800"; d="scan'208,217";a="22591653" Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 22 Apr 2010 12:13:34 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 22 Apr 2010 12:13:32 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Thu, 22 Apr 2010 12:13:32 -0700 From: "Luby, Michael" To: "Ali C. Begen (abegen)" , Orly Peck , "fecframe@ietf.org" Date: Thu, 22 Apr 2010 12:13:30 -0700 Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Thread-Index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDwAFFLjgAAAiucE= Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7F5EDEADA17lubyqualcommcom_" MIME-Version: 1.0 Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:29:27 -0000 --_000_C7F5EDEADA17lubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ok, it seems that if the receiver SHOULD do something then the text should = explain how it should do that. On 4/22/10 12:11 PM, "Ali C. Begen (abegen)" wrote: I suppose the receiver can only start counting when it received the first p= acket in a source block (it can make adjustments if there were missing pack= ets at the beginning of the block). And yes, this is specified in the SDP description. When it is signaled ther= e, the sender conforms to it and the receiver knows about it. -acbegen > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, April 22, 2010 12:44 PM > To: Ali C. Begen (abegen); Orly Peck; fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > Repair window from the receiver perspective doesn't seem very well define= d in this text. Is it > specified somewhere else in the spec what the repair window is from the r= eceiver perspective, i.e., > how does the receiver know when the repair window starts and how does the= receiver know the duration > of the repair window (is it signaled?). > > > On 4/22/10 9:33 AM, "Ali C. Begen (abegen)" wrote: > > > > Is the WG happy with the text below? > > -acbegen > > An FEC encoder processes a block of source packets and generates a = number of repair packets, > which are then transmitted within a certain duration. At the receiver sid= e, the FEC decoder tries to > decode all the packets received within the repair window to recover the m= issing packets, if there are > any. Repair window stands for the time that spans the source packets and = the corresponding repair > packets. It defines the minimum time which the receiver SHOULD wait for t= he repair packets. > > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org= ] On Behalf Of Orly Peck > > Sent: Thursday, April 22, 2010 5:57 AM > > To: fecframe@ietf.org > > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-0= 5 > > > > Hi, > > Here are my comments to draft-ietf-fecframe-sdp-elements-05: > > > > 1) section 4.6 - Repair Window - " Assuming that there is no issu= e of delay variation, the FEC > decoder > > SHOULD NOT wait longer than the repair window since additional wa= iting would not help the > recovery > > process." > > > > I think that the assumption that there is no issue of delay varia= tion is irrelevant for most > cases. > > I think the Repair Window should be defined (as I mentioned at th= e last IETF meeting) as the > MINIMUM > > time that the receiver should wait for the repair packets, as the= sender only knows the time > that > > spans between the source packets and the generation of the repair= packets. > > This comment was accepted also by Mark Watson for draft-ietf-fecf= rame-framework-05. > > > > 2) same section - typo: mismatchs =3D mismatches. > > > > Thanks, > > Orly Peck. > > > > > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org= ] On Behalf Of Greg Shepherd > > Sent: Wednesday, April 14, 2010 8:08 PM > > To: Ali C. Begen (abegen) > > Cc: fecframe@ietf.org > > Subject: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > > > Working Group Last Call for draft-ietf-fecframe-sdp-elements-05 > > > > PLEASE READ AND COMMENT. As I said in the WG meeting, even if you= have > > no corrections to the document please send to the list your appro= val > > of the document as is. > > > > And let's do this quickly. Please send comments to the list by > > end-of-day Friday, April 23. > > > > Thanks!, > > Greg > > > > On Sun, Apr 4, 2010 at 12:30 PM, Ali C. Begen (abegen) wrote: > > > This revision simply fixed the boilerplate. No other changes. C= ould we run the 2nd wglc on > this > > draft? > > > > > > Thanks, > > > -acbegen > > > > > > -----Original Message----- > > > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > > > Sent: Sunday, April 04, 2010 3:29 PM > > > To: Ali C. Begen (abegen) > > > Subject: New Version Notification for draft-ietf-fecframe-sdp-e= lements-05 > > > > > > > > > A new version of I-D, draft-ietf-fecframe-sdp-elements-05.txt h= as been successfully > submitted by Ali > > Begen and posted to the IETF repository. > > > > > > Filename: draft-ietf-fecframe-sdp-elements > > > Revision: 05 > > > Title: SDP Elements for FEC Framework > > > Creation_date: 2010-04-04 > > > WG ID: fecframe > > > Number_of_pages: 21 > > > > > > Abstract: > > > This document specifies the use of Session Description Protocol= (SDP) > > > to describe the parameters required to signal the Forward Error > > > Correction (FEC) Framework Configuration Information between th= e > > > sender(s) and receiver(s). This document also provides example= s that > > > show the semantics for grouping multiple source and repair flow= s > > > together for the applications that simultaneously use multiple > > > instances of the FEC Framework. > > > > > > > > > > > > The IETF Secretariat. > > > > > > > > > _______________________________________________ > > > Fecframe mailing list > > > Fecframe@ietf.org > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > > > > _______________________________________________ > > Fecframe mailing list > > Fecframe@ietf.org > > https://www.ietf.org/mailman/listinfo/fecframe > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > > --_000_C7F5EDEADA17lubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Ok, it seems that if the receiver SHOULD do something then the text s= hould explain how it should do that.

On 4/22/10 12:11 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

I suppose the receiver can only start count= ing when it received the first packet in a source block (it can make adjust= ments if there were missing packets at the beginning of the block).

And yes, this is specified in the SDP description. When it is signaled ther= e, the sender conforms to it and the receiver knows about it.

-acbegen

> -----Original Message-----
> From: Luby, Michael [mailto:luby@= qualcomm.com]
> Sent: Thursday, April 22, 2010 12:44 PM
> To: Ali C. Begen (abegen); Orly Peck; fe= cframe@ietf.org
> Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05
>
> Repair window from the receiver perspective doesn’t seem very we= ll defined in this text. Is it
> specified somewhere else in the spec what the repair window is from th= e receiver perspective, i.e.,
> how does the receiver know when the repair window starts and how does = the receiver know the duration
> of the repair window (is it signaled?).
>
>
> On 4/22/10 9:33 AM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:
>
>
>
>       Is the WG happy with the text belo= w?
>
>       -acbegen
>
>       An FEC encoder processes a block o= f source packets and generates a number of repair packets,
> which are then transmitted within a certain duration. At the receiver = side, the FEC decoder tries to
> decode all the packets received within the repair window to recover th= e missing packets, if there are
> any. Repair window stands for the time that spans the source packets a= nd the corresponding repair
> packets. It defines the minimum time which the receiver SHOULD wait fo= r the repair packets.
>
>       > -----Original Message----- >       > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Orly Pec= k
>       > Sent: Thursday, April 22, 201= 0 5:57 AM
>       > To: fecframe@ietf.org
>       > Subject: Re: [Fecframe] WGLC = - draft-ietf-fecframe-sdp-elements-05
>       >
>       > Hi,
>       > Here are my comments to draft= -ietf-fecframe-sdp-elements-05:
>       >
>       > 1) section 4.6 - Repair Windo= w - " Assuming that there is no issue of delay variation, the FEC
> decoder
>       > SHOULD NOT wait longer than t= he repair window since additional waiting would not help the
> recovery
>       > process."
>       >
>       > I think that the assumption t= hat there is no issue of delay variation is irrelevant for most
> cases.
>       > I think the Repair Window sho= uld be defined (as I mentioned at the last IETF meeting) as the
> MINIMUM
>       > time that the receiver should= wait for the repair packets, as the sender only knows the time
> that
>       > spans between the source pack= ets and the generation of the repair packets.
>       > This comment was accepted als= o by Mark Watson for draft-ietf-fecframe-framework-05.
>       >
>       > 2) same section - typo: misma= tchs =3D mismatches.
>       >
>       > Thanks,
>       > Orly Peck.
>       >
>       >
>       > -----Original Message----- >       > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Greg She= pherd
>       > Sent: Wednesday, April 14, 20= 10 8:08 PM
>       > To: Ali C. Begen (abegen)
>       > Cc: fecframe@ietf.org
>       > Subject: [Fecframe] WGLC - dr= aft-ietf-fecframe-sdp-elements-05
>       >
>       > Working Group Last Call for d= raft-ietf-fecframe-sdp-elements-05
>       >
>       > PLEASE READ AND COMMENT. As I= said in the WG meeting, even if you have
>       > no corrections to the documen= t please send to the list your approval
>       > of the document as is.
>       >
>       > And let's do this quickly. Pl= ease send comments to the list by
>       > end-of-day Friday, April 23.<= BR> >       >
>       > Thanks!,
>       > Greg
>       >
>       > On Sun, Apr 4, 2010 at 12:30 = PM, Ali C. Begen (abegen) <abegen@cisco.com= > wrote:
>       > > This revision simply fix= ed the boilerplate. No other changes. Could we run the 2nd wglc on
> this
>       > draft?
>       > >
>       > > Thanks,
>       > > -acbegen
>       > >
>       > > -----Original Message---= --
>       > > From: IETF I-D Submissio= n Tool [mailto:idsubmission@ietf.o= rg]
>       > > Sent: Sunday, April 04, = 2010 3:29 PM
>       > > To: Ali C. Begen (abegen= )
>       > > Subject: New Version Not= ification for draft-ietf-fecframe-sdp-elements-05
>       > >
>       > >
>       > > A new version of I-D, dr= aft-ietf-fecframe-sdp-elements-05.txt has been successfully
> submitted by Ali
>       > Begen and posted to the IETF = repository.
>       > >
>       > > Filename:   &n= bsp;    draft-ietf-fecframe-sdp-elements
>       > > Revision:   &n= bsp;    05
>       > > Title:    = ;       SDP Elements for FEC Framework >       > > Creation_date: &nb= sp;2010-04-04
>       > > WG ID:    = ;       fecframe
>       > > Number_of_pages: 21
>       > >
>       > > Abstract:
>       > > This document specifies = the use of Session Description Protocol (SDP)
>       > > to describe the paramete= rs required to signal the Forward Error
>       > > Correction (FEC) Framewo= rk Configuration Information between the
>       > > sender(s) and receiver(s= ). This document also provides examples that
>       > > show the semantics for g= rouping multiple source and repair flows
>       > > together for the applica= tions that simultaneously use multiple
>       > > instances of the FEC Fra= mework.
>       > >
>       > >
>       > >
>       > > The IETF Secretariat. >       > >
>       > >
>       > > ________________________= _______________________
>       > > Fecframe mailing list >       > > Fecframe@ietf.org
>       > > https://www.ietf.org/mailman/listinfo/fe= cframe
>       > >
>       > _____________________________= __________________
>       > Fecframe mailing list
>       > Fecframe@ietf.org
>       > https://www.ietf.org/mailman/listinfo/fecfram= e
>       >
>       > _____________________________= __________________
>       > Fecframe mailing list
>       > Fecframe@ietf.org
>       > https://www.ietf.org/mailman/listinfo/fecfram= e
>       __________________________________= _____________
>       Fecframe mailing list
>       Fecf= rame@ietf.org
>       https://www.ietf.org/mailman/listinfo/fecframe=
>
>

--_000_C7F5EDEADA17lubyqualcommcom_-- From abegen@cisco.com Thu Apr 22 12:58:39 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9A03A67E9 for ; Thu, 22 Apr 2010 12:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI87IwjL0E4F for ; Thu, 22 Apr 2010 12:58:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4752A3A6359 for ; Thu, 22 Apr 2010 12:58:03 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGJH0EurR7Hu/2dsb2JhbACcKXGmeZo7hQ8EgzQ X-IronPort-AV: E=Sophos;i="4.52,258,1270425600"; d="scan'208";a="119275561" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 22 Apr 2010 19:57:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o3MJvr6R019087; Thu, 22 Apr 2010 19:57:53 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Apr 2010 12:57:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 12:57:24 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6791@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 thread-index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDwAFFLjgAAAiucEAAQCJwA== References: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Luby, Michael" , "Orly Peck" , X-OriginalArrivalTime: 22 Apr 2010 19:57:53.0583 (UTC) FILETIME=[1846ABF0:01CAE256] Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:58:39 -0000 OK, what about this (section 4.6): Repair window is the time that spans an FEC block, which consists of the = source block and the corresponding repair packets. =20 At the sender side, the FEC encoder processes a block of source packets = and generates a number of repair packets, which are then transmitted = within a certain duration not larger than the value of the repair = window. At the receiver side, the FEC decoder should wait at least for = the duration of the repair window after getting the first packet in an = FEC block to allow all the repair packets to arrive (The waiting time = can be adjusted if there are mising packets at the beginning of the FEC = block). The FEC decoder may start decoding the already received packets = sooner, however, it SHOULD NOT register an FEC decoding failure until it = waits at least for the repair-window duration. -acbegen > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, April 22, 2010 3:14 PM > To: Ali C. Begen (abegen); Orly Peck; fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > Ok, it seems that if the receiver SHOULD do something then the text = should explain how it should do > that.=20 From orlyp@radvision.com Sun Apr 25 00:14:00 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524E63A6839 for ; Sun, 25 Apr 2010 00:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efFRhlBX0vFK for ; Sun, 25 Apr 2010 00:13:59 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id E98053A67A1 for ; Sun, 25 Apr 2010 00:13:56 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o3P7Cpv1019389 for fecframe@ietf.org; Sun, 25 Apr 2010 10:12:51 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o3P7CakM019368; Sun, 25 Apr 2010 10:12:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Apr 2010 10:13:24 +0300 Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6791@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Thread-Index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDwAFFLjgAAAiucEAAQCJwAB8j3ig References: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540BEE6791@xmb-sjc-215.amer.cisco.com> From: "Orly Peck" To: "Ali C. Begen (abegen)" , "Luby, Michael" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id o3P7CakM019368 Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 07:14:00 -0000 Two things that you may consider adding to the text: 1) The Repair-Window impacts the maximum number of source packets in a FEC block. 2) I think it might be useful to add the option for the sender and receiver to negotiate this value with SDP offer-answer. Thanks, Orly Peck. -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Thursday, April 22, 2010 10:57 PM To: Luby, Michael; Orly Peck; fecframe@ietf.org Subject: RE: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 OK, what about this (section 4.6): Repair window is the time that spans an FEC block, which consists of the source block and the corresponding repair packets. At the sender side, the FEC encoder processes a block of source packets and generates a number of repair packets, which are then transmitted within a certain duration not larger than the value of the repair window. At the receiver side, the FEC decoder should wait at least for the duration of the repair window after getting the first packet in an FEC block to allow all the repair packets to arrive (The waiting time can be adjusted if there are mising packets at the beginning of the FEC block). The FEC decoder may start decoding the already received packets sooner, however, it SHOULD NOT register an FEC decoding failure until it waits at least for the repair-window duration. -acbegen > -----Original Message----- > From: Luby, Michael [mailto:luby@qualcomm.com] > Sent: Thursday, April 22, 2010 3:14 PM > To: Ali C. Begen (abegen); Orly Peck; fecframe@ietf.org > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > Ok, it seems that if the receiver SHOULD do something then the text should explain how it should do > that. From abegen@cisco.com Mon Apr 26 07:14:41 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3033A6BB8 for ; Mon, 26 Apr 2010 07:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.341 X-Spam-Level: X-Spam-Status: No, score=-9.341 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc+UA0gYHhYV for ; Mon, 26 Apr 2010 07:14:38 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 57A953A6B9B for ; Mon, 26 Apr 2010 07:13:49 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIY81UurR7H+/2dsb2JhbACcO3GnDZldhQwEgzk X-IronPort-AV: E=Sophos;i="4.52,273,1270425600"; d="scan'208";a="320430496" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 26 Apr 2010 14:13:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o3QEDYK1002843; Mon, 26 Apr 2010 14:13:34 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Apr 2010 07:13:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2010 07:13:38 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6E19@xmb-sjc-215.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Thread-Index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDwAFFLjgAAAiucEAAQCJwAB8j3igAEENBUA= References: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540BEE6791@xmb-sjc-215.amer.cisco.com> From: "Ali C. Begen (abegen)" To: "Orly Peck" , "Luby, Michael" , X-OriginalArrivalTime: 26 Apr 2010 14:13:34.0567 (UTC) FILETIME=[A831FF70:01CAE54A] Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 14:14:41 -0000 > Two things that you may consider adding to the text: >=20 > 1) The Repair-Window impacts the maximum number of source packets in a > FEC block. This was implied but I am fine with making it explicit.=20 > 2) I think it might be useful to add the option for the sender and > receiver to negotiate this value with SDP offer-answer. I believe the way it works is that the sender makes multiple offers with = different RW values (or other parameters) and the client chooses the one = it likes, or probably can make a counter proposal. Do we need additional text for this? -acbegen =20 > Thanks, > Orly Peck. >=20 > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Thursday, April 22, 2010 10:57 PM > To: Luby, Michael; Orly Peck; fecframe@ietf.org > Subject: RE: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 >=20 > OK, what about this (section 4.6): >=20 > Repair window is the time that spans an FEC block, which consists of = the > source block and the corresponding repair packets. >=20 > At the sender side, the FEC encoder processes a block of source = packets > and generates a number of repair packets, which are then transmitted > within a certain duration not larger than the value of the repair > window. At the receiver side, the FEC decoder should wait at least for > the duration of the repair window after getting the first packet in an > FEC block to allow all the repair packets to arrive (The waiting time > can be adjusted if there are mising packets at the beginning of the = FEC > block). The FEC decoder may start decoding the already received = packets > sooner, however, it SHOULD NOT register an FEC decoding failure until = it > waits at least for the repair-window duration. >=20 > -acbegen >=20 > > -----Original Message----- > > From: Luby, Michael [mailto:luby@qualcomm.com] > > Sent: Thursday, April 22, 2010 3:14 PM > > To: Ali C. Begen (abegen); Orly Peck; fecframe@ietf.org > > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > > > Ok, it seems that if the receiver SHOULD do something then the text > should explain how it should do > > that. >=20 From orlyp@radvision.com Mon Apr 26 10:13:59 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3534128C18C for ; Mon, 26 Apr 2010 10:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4UAKTybWRd3 for ; Mon, 26 Apr 2010 10:13:58 -0700 (PDT) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 4137628C1D3 for ; Mon, 26 Apr 2010 10:12:10 -0700 (PDT) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o3QHB4Qx006932 for fecframe@ietf.org; Mon, 26 Apr 2010 20:11:04 +0300 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o3QHB0KA006920; Mon, 26 Apr 2010 20:11:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Apr 2010 20:11:47 +0300 Message-ID: In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6E19@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 Thread-Index: Acrb9QQp22mDNdW8SzaLsxCj0gCHzAGBq0QgAA9nZhAAAG4EDwAFFLjgAAAiucEAAQCJwAB8j3igAEENBUAABjuRgA== References: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com><04CAD96D4C5A3D48B1919248A8FE0D540BEE6791@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540BEE6E19@xmb-sjc-215.amer.cisco.com> From: "Orly Peck" To: "Ali C. Begen (abegen)" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id o3QHB0KA006920 Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 17:13:59 -0000 -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] Sent: Monday, April 26, 2010 5:14 PM To: Orly Peck; Luby, Michael; fecframe@ietf.org Subject: RE: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > Two things that you may consider adding to the text: > > 1) The Repair-Window impacts the maximum number of source packets in a > FEC block. This was implied but I am fine with making it explicit. [Orly Peck] ok > 2) I think it might be useful to add the option for the sender and > receiver to negotiate this value with SDP offer-answer. I believe the way it works is that the sender makes multiple offers with different RW values (or other parameters) and the client chooses the one it likes, or probably can make a counter proposal. Do we need additional text for this? [Orly Peck] if this is obvious then I guess no additional text is needed. -acbegen > Thanks, > Orly Peck. > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Thursday, April 22, 2010 10:57 PM > To: Luby, Michael; Orly Peck; fecframe@ietf.org > Subject: RE: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > OK, what about this (section 4.6): > > Repair window is the time that spans an FEC block, which consists of the > source block and the corresponding repair packets. > > At the sender side, the FEC encoder processes a block of source packets > and generates a number of repair packets, which are then transmitted > within a certain duration not larger than the value of the repair > window. At the receiver side, the FEC decoder should wait at least for > the duration of the repair window after getting the first packet in an > FEC block to allow all the repair packets to arrive (The waiting time > can be adjusted if there are mising packets at the beginning of the FEC > block). The FEC decoder may start decoding the already received packets > sooner, however, it SHOULD NOT register an FEC decoding failure until it > waits at least for the repair-window duration. > > -acbegen > > > -----Original Message----- > > From: Luby, Michael [mailto:luby@qualcomm.com] > > Sent: Thursday, April 22, 2010 3:14 PM > > To: Ali C. Begen (abegen); Orly Peck; fecframe@ietf.org > > Subject: Re: [Fecframe] WGLC - draft-ietf-fecframe-sdp-elements-05 > > > > Ok, it seems that if the receiver SHOULD do something then the text > should explain how it should do > > that. > From ietfdbh@comcast.net Tue Apr 27 10:43:26 2010 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF283A6922 for ; Tue, 27 Apr 2010 10:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.275 X-Spam-Level: X-Spam-Status: No, score=-0.275 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJiywoNKjAIG for ; Tue, 27 Apr 2010 10:43:25 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by core3.amsl.com (Postfix) with ESMTP id 88DC53A6874 for ; Tue, 27 Apr 2010 10:43:25 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA11.westchester.pa.mail.comcast.net with comcast id AdRV1e00k0Fqzac5BhjD0b; Tue, 27 Apr 2010 17:43:14 +0000 Received: from Harrington73653 ([67.189.235.106]) by omta08.westchester.pa.mail.comcast.net with comcast id AhjD1e0062JQnJT3UhjDR8; Tue, 27 Apr 2010 17:43:13 +0000 From: "David Harrington" To: "'Orly Peck'" , "'Ali C. Begen $abegen$'" , References: <04CAD96D4C5A3D48B1919248A8FE0D540BEE6757@xmb-sjc-215.amer.cisco.com><04CAD96D4C5A3D48B1919248A8FE0D540BEE6791@xmb-sjc-215.amer.cisco.com><04CAD96D4C5A3D48B1919248A8FE0D540BEE6E19@xmb-sjc-215.amer.cisco.com>