From watson@qualcomm.com  Tue Jan  5 18:36:01 2010
Return-Path: <watson@qualcomm.com>
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 E679F28C113 for <fecframe@core3.amsl.com>; Tue,  5 Jan 2010 18:36:01 -0800 (PST)
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 704iD3HIujMl for <fecframe@core3.amsl.com>; Tue,  5 Jan 2010 18:35:54 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id C8DE228C110 for <fecframe@ietf.org>; Tue,  5 Jan 2010 18:35:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1262745353; x=1294281353; 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"Watson,=20Mark"=20<watson@qualcomm.com>|To:=20" Ali=20C.=20Begen=20(abegen)"=20<abegen@cisco.com>,=0D=0A =20=20=20=20=20=20=20=20"fecframe@ietf.org"=0D=0A=09<fecf rame@ietf.org>|Date:=20Tue,=205=20Jan=202010=2018:35:42 =20-0800|Subject:=20Re:=20[Fecframe]=20Review=20for=20dra ft-ietf-fecframe-raptor-01|Thread-Topic:=20[Fecframe]=20R eview=20for=20draft-ietf-fecframe-raptor-01|Thread-Index: =20AcpYytE8kvmuKdUwTmCg6CvJecOy4g1rh+GG|Message-ID:=20<C7 6936FE.36906%watson@qualcomm.com>|In-Reply-To:=20<04CAD96 D4C5A3D48B1919248A8FE0D540A84366F@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_C76936FE36906watsonqualcommcom_" |MIME-Version:=201.0; bh=Yz/ShTQgcGNaq4cXiGqDA8s5zGukUHiSkWEwmCOfxEc=; b=lHtD/yCBNouH/Rqsu2zq+LS4oN8p360j/jELEg0qeDYe/MMHeKjiye8r eu8uDj7BaNi037t4kTGyia7S3+aMF+AIx/AsIZhuaz1Utb3wKY+TgZ5KE 9+sPB5LJteW1O/OolcFb9wLa35r8IoeOVpiBJlv5pOCHPq/IhU/JCn5aV s=;
X-IronPort-AV: E=McAfee;i="5400,1158,5852"; a="31463132"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 05 Jan 2010 18:35:47 -0800
Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o062Zl2j012149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <fecframe@ietf.org>; Tue, 5 Jan 2010 18:35:47 -0800
X-IronPort-AV: E=Sophos;i="4.49,226,1262592000"; d="scan'208,217";a="29696156"
Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 05 Jan 2010 18:35:46 -0800
Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 5 Jan 2010 18:35:46 -0800
Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Tue, 5 Jan 2010 18:35:46 -0800
From: "Watson, Mark" <watson@qualcomm.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "fecframe@ietf.org" <fecframe@ietf.org>
Date: Tue, 5 Jan 2010 18:35:42 -0800
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-raptor-01
Thread-Index: AcpYytE8kvmuKdUwTmCg6CvJecOy4g1rh+GG
Message-ID: <C76936FE.36906%watson@qualcomm.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A84366F@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_C76936FE36906watsonqualcommcom_"
MIME-Version: 1.0
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-raptor-01
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2010 02:36:02 -0000

--_000_C76936FE36906watsonqualcommcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ali, all,

Sorry for the small delay.

My responses to your comments are inline below with the exception of the la=
st one regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion o=
n that. I am confused about what "multiple distinct elements" means in the =
SDP elements draft: you define the FSSI it to be just *CHAR - no notion of =
'element' is defined.

A consequence of this decision is that the FEC Framework must require FEC S=
chemes to define a text format for the SS-FSSI and FSSI (so I need to add t=
hat) and furthermore that this format must not include the ';' character or=
 Carriage Return (otherwise things become ambiguous in the SDP case). This =
seems a little arbitrary (SDP-specific encoding requirements polluting the =
FEC framework), but I guess that's my fault for missing the discussion.

What did you decide regarding binary encodings ? Must FEC Schemes define th=
ese or must all CDPs provide for text transport ?

...Mark

On 10/29/09 12:05 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

- Abstract says " An RTP Payload Type is defined for this latter case. " I'=
d suggest to remove this sentence as this draft does not provide the payloa=
d format.

MW: ok

- Also in the abstract and introduction, it says two FEC schemes are define=
d. In the Raptor RTP draft, it said three. You might wanna fix it for consi=
stency.

MW: Ok, there are three.

- Introduction:

   Per the FEC Framework requirements, the sender MUST transmit the
   source and repair packets in different source and repair flows,
   respectively.

In case of RTP transport, source and repair data can be in different RTP st=
reams, where they are SSRC multiplexed in the same RTP session. From outsid=
e, they look like a single UDP flow. The sentence above contradicts with th=
is. I suggest to change it as follows:

   Per the FEC Framework requirements, the sender MUST transmit the
   source and repair packets in different source and repair streams,
   respectively.

MW: I suggest "Per the FEC Framework requirements, the sender MUST transmit=
 the source and repair packets in different source and repair flows, or in =
the case RTP transport is used for Repair packets, in different RTP streams=
."

Accordingly, the definitions (source and repair flow) will need to be chang=
ed as well in section 4.

MW: ok

- I admit that I did not check all the definitions/formulas in sections 6-8=
 in detail.

- Section 8.2.4. What about the length of the RTP header extensions?

MW: Good point. In DVB the X bit was not allowed to be set, so the header e=
xtension was not mentioned. I will add it.

- Section 9: No specific security considerations?

MW: Not that I can think of. We define here specific encodings and packet f=
ormats but the same security issues apply however this information is encod=
ed and are dealt with in the FEC framework. I will add a note to this effec=
t.

- Section 10: I suggest to reference 4756bis instead of 4756 and update the=
 semantics accordingly. Also "a=3Drepair-window: 200" should be "a=3Drepair=
-window:200" (remove the space).

MW: Ok.

...Mark

- As agreed in the last meeting, the current SDP elements draft says:

   The variable-length SS-FSSI and FSSI containers transmit the
   information in textual representation and MAY contain multiple
   distinct elements.  For the fully-specified FEC schemes, a full
   description of these elements for both containers MUST be provided.

This will require some changes in the SDP example. The draft also needs to =
explain the elements that will be used in this textual representation.

HTH,
-acbegen




_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe


--_000_C76936FE36906watsonqualcommcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Fecframe] Review for draft-ietf-fecframe-raptor-01</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Ali, all,<BR>
<BR>
Sorry for the small delay.<BR>
<BR>
My responses to your comments are inline below with the exception of the la=
st one regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion o=
n that. I am confused about what &#8220;multiple distinct elements&#8221; m=
eans in the SDP elements draft: you define the FSSI it to be just *CHAR &#8=
211; no notion of &#8216;element&#8217; is defined.<BR>
<BR>
A consequence of this decision is that the FEC Framework must require FEC S=
chemes to define a text format for the SS-FSSI and FSSI (so I need to add t=
hat) and furthermore that this format must not include the &#8216;;&#8217; =
character or Carriage Return (otherwise things become ambiguous in the SDP =
case). This seems a little arbitrary (SDP-specific encoding requirements po=
lluting the FEC framework), but I guess that&#8217;s my fault for missing t=
he discussion.<BR>
<BR>
What did you decide regarding binary encodings ? Must FEC Schemes define th=
ese or must all CDPs provide for text transport ?<BR>
<BR>
...Mark<BR>
<BR>
On 10/29/09 12:05 PM, &quot;Ali C. Begen (abegen)&quot; &lt;<a href=3D"abeg=
en@cisco.com">abegen@cisco.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>- Abstract says &quot; An RTP Payload Type =
is defined for this latter case. &quot; I'd suggest to remove this sentence=
 as this draft does not provide the payload format.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: ok<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Also in the abstract and introduction, it says two FEC schemes are define=
d. In the Raptor RTP draft, it said three. You might wanna fix it for consi=
stency.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Ok, there are three.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Introduction:<BR>
<BR>
&nbsp;&nbsp;&nbsp;Per the FEC Framework requirements, the sender MUST trans=
mit the<BR>
&nbsp;&nbsp;&nbsp;source and repair packets in different source and repair =
flows,<BR>
&nbsp;&nbsp;&nbsp;respectively.<BR>
<BR>
In case of RTP transport, source and repair data can be in different RTP st=
reams, where they are SSRC multiplexed in the same RTP session. From outsid=
e, they look like a single UDP flow. The sentence above contradicts with th=
is. I suggest to change it as follows:<BR>
<BR>
&nbsp;&nbsp;&nbsp;Per the FEC Framework requirements, the sender MUST trans=
mit the<BR>
&nbsp;&nbsp;&nbsp;source and repair packets in different source and repair =
streams,<BR>
&nbsp;&nbsp;&nbsp;respectively.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: I suggest &#8220;Per the FEC Framework=
 requirements, the sender MUST transmit the source and repair packets in di=
fferent source and repair flows, or in the case RTP transport is used for R=
epair packets, in different RTP streams.&#8221;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
Accordingly, the definitions (source and repair flow) will need to be chang=
ed as well in section 4.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: ok<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- I admit that I did not check all the definitions/formulas in sections 6-8=
 in detail.<BR>
<BR>
- Section 8.2.4. What about the length of the RTP header extensions?<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Good point. In DVB the X bit was not a=
llowed to be set, so the header extension was not mentioned. I will add it.=
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 9: No specific security considerations?<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Not that I can think of. We define her=
e specific encodings and packet formats but the same security issues apply =
however this information is encoded and are dealt with in the FEC framework=
. I will add a note to this effect. <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 10: I suggest to reference 4756bis instead of 4756 and update the=
 semantics accordingly. Also &quot;a=3Drepair-window: 200&quot; should be &=
quot;a=3Drepair-window:200&quot; (remove the space).<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Ok.<BR>
<BR>
...Mark<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- As agreed in the last meeting, the current SDP elements draft says:<BR>
<BR>
&nbsp;&nbsp;&nbsp;The variable-length SS-FSSI and FSSI containers transmit =
the<BR>
&nbsp;&nbsp;&nbsp;information in textual representation and MAY contain mul=
tiple<BR>
&nbsp;&nbsp;&nbsp;distinct elements. &nbsp;For the fully-specified FEC sche=
mes, a full<BR>
&nbsp;&nbsp;&nbsp;description of these elements for both containers MUST be=
 provided.<BR>
<BR>
This will require some changes in the SDP example. The draft also needs to =
explain the elements that will be used in this textual representation.<BR>
<BR>
HTH,<BR>
-acbegen<BR>
<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
Fecframe mailing list<BR>
<a href=3D"Fecframe@ietf.org">Fecframe@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/fecframe">https://www.ietf=
.org/mailman/listinfo/fecframe</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C76936FE36906watsonqualcommcom_--

From watson@qualcomm.com  Wed Jan  6 18:39:10 2010
Return-Path: <watson@qualcomm.com>
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 2A9FA3A6868 for <fecframe@core3.amsl.com>; Wed,  6 Jan 2010 18:39:10 -0800 (PST)
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 7pPiUlRjX4QQ for <fecframe@core3.amsl.com>; Wed,  6 Jan 2010 18:39:01 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 99ADB3A6945 for <fecframe@ietf.org>; Wed,  6 Jan 2010 18:39:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1262831940; x=1294367940; 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"Watson,=20Mark"=20<watson@qualcomm.com>|To:=20" Ali=20C.=20Begen=20(abegen)"=20<abegen@cisco.com>,=0D=0A =20=20=20=20=20=20=20=20"fecframe@ietf.org"=0D=0A=09<fecf rame@ietf.org>|Date:=20Wed,=206=20Jan=202010=2018:38:55 =20-0800|Subject:=20Re:=20[Fecframe]=20Review=20for=20dra ft-ietf-fecframe-rtp-raptor-02|Thread-Topic:=20[Fecframe] =20Review=20for=20draft-ietf-fecframe-rtp-raptor-02 |Thread-Index:=20AcpXi3s0CQY7ynlsQyqxaZIfFXdzQQ3txMCi |Message-ID:=20<C76A893F.369BC%watson@qualcomm.com> |In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D540A843093 @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=09boundar y=3D"_000_C76A893F369BCwatsonqualcommcom_"|MIME-Version: =201.0; bh=U/PDHM8paLbPpf26P48WRkf7eCku2RJEgkfc4gK8mq4=; b=XL5TIHBFAoq/89KCEPAWo9NcL1+nB5HrpI8G9FF9L67H3Me+OhCyv6YU lA0OA4vx7hUgiIsU8p9AILn27Ah6rqkILj4M37nz/qx+bQTUQcb79ROcW Cw9+yIV5oWHAEMVsCH3MZLgZDSzjIL9qYWl6Hv3pOJECm/fXKi++wjp9G g=;
X-IronPort-AV: E=McAfee;i="5400,1158,5853"; a="31534914"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP; 06 Jan 2010 18:39:00 -0800
Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o072cxVN021285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <fecframe@ietf.org>; Wed, 6 Jan 2010 18:39:00 -0800
X-IronPort-AV: E=Sophos;i="4.49,233,1262592000"; d="scan'208,217";a="30031431"
Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 06 Jan 2010 18:38:59 -0800
Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 6 Jan 2010 18:38:59 -0800
Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Wed, 6 Jan 2010 18:38:58 -0800
Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Wed, 6 Jan 2010 18:38:58 -0800
From: "Watson, Mark" <watson@qualcomm.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "fecframe@ietf.org" <fecframe@ietf.org>
Date: Wed, 6 Jan 2010 18:38:55 -0800
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
Thread-Index: AcpXi3s0CQY7ynlsQyqxaZIfFXdzQQ3txMCi
Message-ID: <C76A893F.369BC%watson@qualcomm.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540A843093@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_C76A893F369BCwatsonqualcommcom_"
MIME-Version: 1.0
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2010 02:39:10 -0000

--_000_C76A893F369BCwatsonqualcommcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ali,

Again, sorry for the slight delay ...

Comments inline...


On 10/27/09 9:59 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

Here is the list of my comments for this draft. As I mentioned earlier, thi=
s draft should be reviewed by AVT as well.

- RFC 3550 needs to be cited in the introduction section and in other relev=
ant places.

MW: Presuably only on the first mention of RTP ?

- Section 3: "... In this case, in the language of the FEC Framework, there=
 is no explicit FEC Source Payload Id." --> "... there is no (need for) exp=
licit ..."

MW: I suggest "In this case, in the language of the FEC Framework, there is=
 no need for an explicit FEC Source Payload Id and it is therefore not incl=
uded in the packets."

- Section 4.1, Market bit: I believe "shall" should be "SHALL" in this sent=
ence.

MW: Ok

- Section 4.1: What about the other fields in the RTP header? If there are =
no specific usage rules, a note saying that RFC 3550 rules shall apply shou=
ld be added.

MW: Ok

- Section 4.2 and 4.3: This is the part that needs some work. I don't think=
 we can simply refer to the framework and fecframe-raptor drafts and leave =
these parts (which are the most critical sections in a payload draft) empty=
. First of all, why is there a reference to the framework draft? Secondly, =
this section needs to make it clear that the payload draft is for the last =
FEC scheme introduced in the fecframe-raptor draft (Section 8).

In the current draft, it says there is no (FEC) payload header. So, I guess=
 everything goes into the RTP payload. However, IMO it is better to introdu=
ce the Repair FEC Payload ID (section 8.1.3 of the fecframe-raptor draft) a=
s the FEC payload header, and then put the repair symbols as the RTP payloa=
d. This makes it a better representation and easier for others to visualize=
 the encoding/decoding ops.

MW: I disagree on these two points. The FEC Framework clearly defines the F=
EC Repair Payload, making reference to the details which must be filled in =
by an FEC Scheme. So the Framework, together with an FEC Scheme, fully defi=
nes the FEC Repair Payload for that scheme and all that remains is for us t=
o say where in the RTP packet the FEC Repair Payload appears. Making refere=
nce to the internal structure of the FEC Repair Payload (Repair FEC Payload=
 Id etc.) would be duplicate specification.

The payload format defined here could be used with any of the schemes defin=
ed in the Raptor FEC Schemes document.

- Are there any requirements for max-sbl and symbol-size parameters? If yes=
, they must be stated in every subsection of 6.3.

MW: The requirements are in the FEC Schemes and should not be duplicated he=
re.

- Search for " definedf" and replace it with " defined".

MW: Ok

- Section 5: Are not there any special considerations for Raptor FEC? The C=
C section in the framework is pretty generic IMO. Some specific guidelines,=
 if any, would be appropriate to put here. And this section should be moved=
 to the end.

MW: I can't think of anything that is specific to Raptor.

- Section 7: The mapping to the SDP parameters should be explained. There i=
s a boilerplate for it. Just apply it to your document.

- Section 8 and 9: I am pretty sure there are some offer/answer model and d=
eclarative SDP considerations. Again, there is a boilerplate for it, but it=
 must be modified a little bit to fit to the specifics of this payload form=
at.

MW: Where can I get the boilerplate ? I took the specification format from =
Magnus' "how to", but I didn't see additional boilerplate for these section=
s.

- Section 10: Before IANA considerations, I was hoping to have a section de=
scribing the "Protection and Recovery Procedures." The protection part expl=
ains how the repair packets are constructed. This can be kept brief with pr=
oper references to the fecframe-raptor draft, but there should sufficient t=
ext that gives a general idea to the readers. For the recovery procedures, =
they should be detailed more since even the other draft does not explain th=
is AFAICT.

MW: Again, all this is covered by the combination of FEC Framework and the =
FEC Schemes and included by reference. I know that in the case of the XOR c=
ode you did not make use of the FEC Framework, and chose to define everythi=
ng in the RTP Payload format, but here we are compliant to the framework an=
d the RTP Payload Format need only define how the data is mapped to RTP pac=
kets and address and RTP-specific considerations. It is not a stand-alone d=
ocument.

- An SDP example showing the RTP format parameters is essential.

MW: Ok.

- Section 11: There is a boilerplate for security considerations section an=
d all RTP payload format drafts use it. That should be included here.

MW: Let me know where, although I don't see that there could be any Raptor-=
specific security considerations.

...Mark

HTH,
-acbegen
_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe


--_000_C76A893F369BCwatsonqualcommcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Hi Ali,<BR>
<BR>
Again, sorry for the slight delay ...<BR>
<BR>
Comments inline...<BR>
<BR>
<BR>
On 10/27/09 9:59 PM, &quot;Ali C. Begen (abegen)&quot; &lt;<a href=3D"abege=
n@cisco.com">abegen@cisco.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>Here is the list of my comments for this dr=
aft. As I mentioned earlier, this draft should be reviewed by AVT as well.<=
BR>
<BR>
- RFC 3550 needs to be cited in the introduction section and in other relev=
ant places.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Presuably only on the first mention of=
 RTP ?<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 3: &quot;... In this case, in the language of the FEC Framework, =
there is no explicit FEC Source Payload Id.&quot; --&gt; &quot;... there is=
 no (need for) explicit ...&quot;<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: I suggest &#8220;In this case, in the =
language of the FEC Framework, there is no need for an explicit FEC Source =
Payload Id and it is therefore not included in the packets.&#8221;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 4.1, Market bit: I believe &quot;shall&quot; should be &quot;SHAL=
L&quot; in this sentence.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Ok<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 4.1: What about the other fields in the RTP header? If there are =
no specific usage rules, a note saying that RFC 3550 rules shall apply shou=
ld be added.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Ok<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 4.2 and 4.3: This is the part that needs some work. I don't think=
 we can simply refer to the framework and fecframe-raptor drafts and leave =
these parts (which are the most critical sections in a payload draft) empty=
. First of all, why is there a reference to the framework draft? Secondly, =
this section needs to make it clear that the payload draft is for the last =
FEC scheme introduced in the fecframe-raptor draft (Section 8).<BR>
<BR>
In the current draft, it says there is no (FEC) payload header. So, I guess=
 everything goes into the RTP payload. However, IMO it is better to introdu=
ce the Repair FEC Payload ID (section 8.1.3 of the fecframe-raptor draft) a=
s the FEC payload header, and then put the repair symbols as the RTP payloa=
d. This makes it a better representation and easier for others to visualize=
 the encoding/decoding ops.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: I disagree on these two points. The FE=
C Framework clearly defines the FEC Repair Payload, making reference to the=
 details which must be filled in by an FEC Scheme. So the Framework, togeth=
er with an FEC Scheme, fully defines the FEC Repair Payload for that scheme=
 and all that remains is for us to say where in the RTP packet the FEC Repa=
ir Payload appears. Making reference to the internal structure of the FEC R=
epair Payload (Repair FEC Payload Id etc.) would be duplicate specification=
. <BR>
<BR>
The payload format defined here could be used with any of the schemes defin=
ed in the Raptor FEC Schemes document.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Are there any requirements for max-sbl and symbol-size parameters? If yes=
, they must be stated in every subsection of 6.3.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: The requirements are in the FEC Scheme=
s and should not be duplicated here.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Search for &quot; definedf&quot; and replace it with &quot; defined&quot;=
.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Ok<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 5: Are not there any special considerations for Raptor FEC? The C=
C section in the framework is pretty generic IMO. Some specific guidelines,=
 if any, would be appropriate to put here. And this section should be moved=
 to the end.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: I can&#8217;t think of anything that i=
s specific to Raptor.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 7: The mapping to the SDP parameters should be explained. There i=
s a boilerplate for it. Just apply it to your document.<BR>
<BR>
- Section 8 and 9: I am pretty sure there are some offer/answer model and d=
eclarative SDP considerations. Again, there is a boilerplate for it, but it=
 must be modified a little bit to fit to the specifics of this payload form=
at.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Where can I get the boilerplate ? I to=
ok the specification format from Magnus&#8217; &#8220;how to&#8221;, but I =
didn&#8217;t see additional boilerplate for these sections.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 10: Before IANA considerations, I was hoping to have a section de=
scribing the &quot;Protection and Recovery Procedures.&quot; The protection=
 part explains how the repair packets are constructed. This can be kept bri=
ef with proper references to the fecframe-raptor draft, but there should su=
fficient text that gives a general idea to the readers. For the recovery pr=
ocedures, they should be detailed more since even the other draft does not =
explain this AFAICT.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Again, all this is covered by the comb=
ination of FEC Framework and the FEC Schemes and included by reference. I k=
now that in the case of the XOR code you did not make use of the FEC Framew=
ork, and chose to define everything in the RTP Payload format, but here we =
are compliant to the framework and the RTP Payload Format need only define =
how the data is mapped to RTP packets and address and RTP-specific consider=
ations. It is not a stand-alone document. <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- An SDP example showing the RTP format parameters is essential.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Ok.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
- Section 11: There is a boilerplate for security considerations section an=
d all RTP payload format drafts use it. That should be included here.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Let me know where, although I don&#821=
7;t see that there could be any Raptor-specific security considerations.<BR=
>
<BR>
...Mark<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
HTH,<BR>
-acbegen<BR>
_______________________________________________<BR>
Fecframe mailing list<BR>
<a href=3D"Fecframe@ietf.org">Fecframe@ietf.org</a><BR>
<a href=3D"https://www.ietf.org/mailman/listinfo/fecframe">https://www.ietf=
.org/mailman/listinfo/fecframe</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C76A893F369BCwatsonqualcommcom_--

From csp@csperkins.org  Thu Jan  7 01:26:53 2010
Return-Path: <csp@csperkins.org>
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 1635728C187; Thu,  7 Jan 2010 01:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.607
X-Spam-Level: 
X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 d2wJdA4rsKAk; Thu,  7 Jan 2010 01:26:51 -0800 (PST)
Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 7B28328C18D; Thu,  7 Jan 2010 01:26:49 -0800 (PST)
Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.10]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1NSodj-0002tp-hn; Thu, 07 Jan 2010 09:26:47 +0000
Message-Id: <7FD57461-C976-4D0F-97BD-E1352C4FE46C@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
To: Ali C. Begen (abegen) <abegen@cisco.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540ADA8D02@xmb-sjc-215.amer.cisco.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 6 Jan 2010 11:55:41 +0200
References: <20091130153551.901C53A6A91@core3.amsl.com> <469A2FE6-ED68-428D-BF20-625B087103F1@csperkins.org> <04CAD96D4C5A3D48B1919248A8FE0D540ADA8D02@xmb-sjc-215.amer.cisco.com>
X-Mailer: Apple Mail (2.936)
Cc: IETF Discussion Mailing List <ietf@ietf.org>, fecframe@ietf.org
Subject: Re: [Fecframe] Last Call: draft-ietf-fecframe-dvb-al-fec (DVB-IPTVApplication-Layer Hybrid FEC Protection) to Informational RFC
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2010 09:26:53 -0000

Thanks. The updated draft looks good.
Colin


On 14 Dec 2009, at 20:55, Ali C. Begen (abegen) wrote:

> Sounds like a good suggestion. We will make the text change after  
> the LC ends.
>
> Thanks.
> -acbegen
>
>> -----Original Message-----
>> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org]  
>> On Behalf Of Colin
>> Perkins
>> Sent: Monday, December 14, 2009 11:48 AM
>> To: fecframe@ietf.org
>> Cc: IETF Discussion Mailing List
>> Subject: Re: [Fecframe] Last Call: draft-ietf-fecframe-dvb-al-fec  
>> (DVB-IPTVApplication-
>> Layer Hybrid FEC Protection) to Informational RFC
>>
>> On 30 Nov 2009, at 15:35, The IESG wrote:
>>> The IESG has received a request from the FEC Framework WG (fecframe)
>>> to
>>> consider the following document:
>>>
>>> - 'DVB-IPTV Application-Layer Hybrid FEC Protection '
>>>  <draft-ietf-fecframe-dvb-al-fec-03.txt> as an Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and  
>>> solicits
>>> final comments on this action.  Please send substantive comments to
>>> the
>>> ietf@ietf.org mailing lists by 2009-12-14. Exceptionally,
>>> comments may be sent to iesg@ietf.org instead. In either case,  
>>> please
>>> retain the beginning of the Subject line to allow automated sorting.
>>>
>>> The file can be obtained via
>>> http://www.ietf.org/internet-drafts/draft-ietf-fecframe-dvb-al-fec-03.txt
>>
>> I understand, from previous conversations with the author, that the
>> aim of this draft is "to explain how one can use IETF specs to
>> implement AL-FEC protocol". That's a fine goal, and this draft does a
>> reasonable job in providing such an explanation.
>>
>> However, I believe - as I previously stated in the working group -
>> that the relationship between this draft and the DVB AL-FEC
>> specification is not clearly defined.  While the abstract is
>> reasonably clear on the relationship, the title and introduction
>> suggest that this draft is the DVB AL-FEC protocol, rather than being
>> implementation guidelines for the DVB AL-FEC protocol. One way to
>> address this might be to change the title of the draft to "Guidelines
>> for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection",
>> and to add a few clarifying sentences to the introduction.
>>
>> I have no problems with the technical content of the draft.
>>
>> --
>> Colin Perkins
>> http://csperkins.org/
>>
>>
>>
>> _______________________________________________
>> 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 root@core3.amsl.com  Fri Jan  8 07:30:04 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: fecframe@ietf.org
Delivered-To: fecframe@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id E5D2E3A6818; Fri,  8 Jan 2010 07:30:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100108153003.E5D2E3A6818@core3.amsl.com>
Date: Fri,  8 Jan 2010 07:30:02 -0800 (PST)
Cc: fecframe@ietf.org
Subject: [Fecframe] I-D Action:draft-ietf-fecframe-interleaved-fec-scheme-08.txt
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 15:30:04 -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           : RTP Payload Format for 1-D Interleaved Parity FEC
	Author(s)       : A. Begen
	Filename        : draft-ietf-fecframe-interleaved-fec-scheme-08.txt
	Pages           : 32
	Date            : 2010-01-08

This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP.  The 1-D interleaved parity
code is a systematic code, where a number of repair symbols are
generated from a set of source symbols and sent in a repair flow
separate from the source flow that carries the source symbols.  The
1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of reasonable complexity.  The new payload
format defined in this document is used (with some exceptions) as a
part of the DVB Application-layer FEC specification.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 12, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-08.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-interleaved-fec-scheme-08.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-01-08072253.I-D@ietf.org>


--NextPart--

From vincent.roca@inrialpes.fr  Fri Jan  8 13:23:39 2010
Return-Path: <vincent.roca@inrialpes.fr>
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 29F183A68C0 for <fecframe@core3.amsl.com>; Fri,  8 Jan 2010 13:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.649
X-Spam-Level: 
X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_66=0.6, 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 BKd-H9Pi+GTW for <fecframe@core3.amsl.com>; Fri,  8 Jan 2010 13:23:37 -0800 (PST)
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 1DED03A6896 for <fecframe@ietf.org>; Fri,  8 Jan 2010 13:23:36 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.49,244,1262559600"; d="scan'208";a="44489802"
Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-pro-de-roca.local) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 08 Jan 2010 22:23:32 +0100
Message-ID: <4B47A253.5080806@inrialpes.fr>
Date: Fri, 08 Jan 2010 22:23:31 +0100
From: Vincent Roca <vincent.roca@inrialpes.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: fecframe@ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Fecframe] review of draft-ietf-fecframe-framework-05
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2010 21:23:39 -0000

Mark, all,

Here is a review of draft-ietf-fecframe-framework-05.
It *includes and replaces* the comments I've sent at
the end of October.

Cheers,

     Vincent


** Abstract:


- typo: "This document describes for a framework" -> remove "for"


** Section 2:


- 'Transport protocol' is defined as "the protocol used for transport of
   the source data flow". This is misleading since it is also used to
   transport the *repair* data flow.

- 'Application Data Unit' is defined WRT the transport layer: "Data used
   as the payload for the transport layer". This is misleading, since in
   a FECFRAME system, the transport layer will also carry repair symbols.
   IMHO, the ADU should be defined WRT to the application, e.g.:

    Application Data Unit (ADU):  at a sender (resp. receiver), a unit of
       data coming from (resp. given to) the media delivery application.
       Depending on the use-case, an ADU can use an RTP encapsulation.

   I also suggest you add a sentence like: "The Source data flow consists
   of ADUs" (either here or in the definition of 'Source data flow').

- 'FEC Code' definition mentions it can be used to be resilient to
   *corruptions*. I understand that this is for the general case, however
   it has been clearly stated in Introduction that we are only considering
   the case of erasures! This is therefore misleading.

- 'Source Block' is defined as "the group of source data packets which
   are to be FEC protected as a single block". But nowhere the notion of
   "source data packets" has been defined. I suggest to refer to ADUs
   instead.

   IMHO the term "source block" is confusing because it's overloaded.
   It is primarily a term used by FEC codes (i.e. a set of source symbols
   over which FEC encoding takes place). Using the same term in the
   context of the FEC framework creates confusion, especially as some
   FEC Schemes may define several source blocks from a single ADU block
   (e.g. our Reed-Solomon I-D).

   For clarification purposes I suggest to use the term of ADU block in
   this I-D and to keep the traditional meaning of "source block".
   If you agree, there are many locations (e.g. section 5 and 6) that
   refer to source blocks.

- FEC Payload ID and the Source|Repair FEC Payload IDs: These three
   definitions refer resp. to packet|source packet|repair packet. But the
   notion of packet has not been defined. I suggest to add:

    FEC Source Packet:  at a sender (resp. receiver) a data packet submitted
       to (resp. received from) the Transport protocol. It contains an ADU
       along with its optional Source FEC Payload ID, if any.

    FEC Repair Packet:  at a sender (resp. receiver) a repair packet 
submitted
       to (resp. received from) the Transport protocol. It contains a repair
       symbol along with its Repair FEC Payload ID and possibly RTP header.

- IMHO you should add a few definitions coming from [RFC5052] for
   clarity. E.g. the definition of a 'Source block' should appear here.
   There's an example in draft-roca-fecframe-rs-01.txt (sorry, the same
   reference once again ;-)) where we split definitions between those that
   are FEC Scheme specific and those that are FEC Framework specific.
   I think it would help.


** Section 4:


- p.10, end of 1st paragraph: I don't understand the sentence:
    "In this case the interface to the FEC Framework, at
     least for the repair flows, can be thought of as equivalent to that
     between RTP and users of RTP."

   Which "interface to the FEC Framework" does it refer to? The one with
   overlying protocols (e.g. RTP) or the one with underlying ones (e.g.
   UDP)? In any case FEC repair packets with RTP framing won't reach the
   application, so I don't see the relationships with the "users of RTP".
   I suggest to remove the sentence altogether.

- p.10: it is said:
    "the FEC Framework passes groups of transport packet payloads
     to the FEC Scheme for FEC Encoding."

   What does "transport packet payloads" mean? I suggest instead 'ADUs'.
   Moreover: Encoding -> encoding.

- p.10: In sentence:

    "The FEC Scheme returns FEC
     repair packet payloads, encoded FEC Payload ID information for each
     of the repair packets and, in some cases, encoded FEC Payload ID
     information for each of the source packets."

   "encoded FEC Payload ID" -> "repair FEC Payload ID".
   I also suggest to simplify a bit (see comment for Fig. 2 concerning
   the use of "repair symbol"):

    "The FEC Scheme returns repair symbols with their associated
     Repair FEC Payload ID, and in some case the Source FEC Payload ID,
     depending on the FEC Scheme."

- p.10: there is no reason to use "'" in the following sentence since
   Source data flow and Repair data flow have been formally defined in
   Section 2.
    "... and the
     relationship(s) between these 'source' and 'repair' flows..."

- p.11 and fig 1:
   The notion of "transport flow" has not been defined. Use "Source data
   flow" or (better IMHO) "ADU flow" instead. And there are many other
   instances of "transport flow(s)" in the document that need to be
   corrected.

- p.11:  It is said:
    "From the FEC
     Framework point of view, RTP source flows are sequences of UDP packet
     payloads like any other protocol over UDP."

   It might be another protocol than UDP, right? I know RTP/DCCP has been
   discussed at IETF in the past. I don't know the current status.

- p.11, typo: "the the repair payload" -> "the repair payload".
   And in the same sentence, *repair* data is not necessarily *parity*
   data. It depends on the FEC code being used. The term "parity" appears
   two other times in this paragraph.

- Fig 1: I suggest you add "example" in the figure caption to highlight
   the fact RTP is not a mandatory part of the architecture, and similarly
   that you add the "optional" keyword in the top RTP box.
   Change "Transport flows" by either Source data flow(s) or ADU flow(s).


** Section 5:


- Section 5.1 p.14: you refer to "encoded FEC Payload IDs" with both
   FEC source and repair packets. By "encoded" I understand that it is
   stored in a FEC Scheme specific format that does not have to be
   understood by the FEC Framework. I'd rather say in the two bullets
   something like:

   o  optionally, FEC Payload IDs (encoded according to a FEC Scheme
      specific format) for each of...

- a detail, p14: "source Application Data Units" -> "Application Data Units"
   (it's sufficient).

- Section 5.1 says that a CDP MAY define the mapping between ADUs and
   a source block (I prefer "an ADU block" as said above).
   You should also say that a FEC Scheme MAY also define this mapping,
   or at least provide some rules (e.g. a limit on the maximum source
   block size (k) which will limit the maximum ADU block size).
   More generally, the CDP versus FEC Scheme responsibilities in terms
   of what is defined where are not clear, at least for me.

- Section 5.2, bottom of p.16:
     "...on the eventual IP FEC Source Packet..."
   What is an IP FEC Source Packet? I guess you mean "an IP datagram
   carrying a FEC source packet".

- Fig. 2: What is the "Repair transport payload"?  This is not defined
   in section 2. I guess this payload plus the Repair FEC Payload ID form
   the transport payload.
   I suggest you use the term "repair symbol" (which should be
   defined in Section 2 too) instead.

- Fig. 3: Similarly, I don't like "Repair RTP payloads" since this
   name refers to the RTP box below rather than to the FEC Scheme that
   produced this unit of data. I'd rather say: "repair symbol".

   And another remark: step 6 creates the FEC repair packet, but RTP
   framing happens later, after step 7'.
   In my understanding, an FEC repair packet already includes the RTP
   header, isn't it?

- Section 5.3, step 4:
   The algorithm that is described is the one where all the ADUs of an
   ADU block are kept by the FEC framework until it is known that either
   all the ADUs are available (received or decoded), or that no additional
   FEC repair packet will be received for this block in case one or several
   ADUs are missing. This technique corresponds to the strategy where
   the FEC framework performs buffering and in-order delivery of the
   available ADUs to the application (discussion of section 5.1). This
   should be clearly mentioned.

   Additionally, step 4 requires that the received FEC source and repair
   packets be kept in the FEC framework during (at most) the ADU block
   reception duration. This is not mentioned explicitly. I'd like to
   see a loop somewhere in this description.

   In step 5 there a missing final "s" in Units, 1st line.

- Section 5.3, p.21:
   Instead of "source packets" or "original source packets", you should
   use ADUs.

   Additionally:
   The way this paragraph is currently written is strange since what
   you say in the last sentence ("Alternatively, buffering...") is
   exactly what has been detailed before in the algorithm.
   I suggest you just explain here that other strategies are possible
   that do not necessarily rely on buffering unlike what has been presented
   just before. But in any case the FEC framework/scheme usually needs to
   keep a copy of the FEC source/repair packets of the current block (for
   decoding purposes), even if ADUs are given to the application as soon as
   possible.


** Section 6:


I didn't read, sorry.


** Section 7:


- typos: "recieved", "inaccuate".

- It is said:
     New applications which require such feedback SHOULD use RTP/RTCP
    [RFC3550].

   Isn't "SHOULD" a little bit too strong here? I agree it's a convenient,
   on-the-shelf, solution, but alternatives may exist.


** Globally, I have the feeling that the use of RTP for the repair data
   flow is not sufficiently motivated. There's a small paragraph in the
   introduction to say that a motivation is to use "RTP instrumentation".
   Later on, in section 4 (Architecture), it is said that the source and
   repair data flows can be multiplexed on the same UDP flow (1st 
paragraph).
   There are two additional paragraphs in section 4 to explain what the
   RTP repair data packet consists in and the fact it's decoupled from the
   source data flow.

   I'd like to see a sub-section that explains clearly, in a single place,
   all the motivations for using an RTP framing with repair packets
   (in particular the backward compatibility benefits, the possibility
   to multiplex the various flows on the same UDP flow, etc.).


** To finish: the FECFRAME group should probably be thanked too in
   section 12 ;-)



From abegen@cisco.com  Sat Jan  9 17:08:25 2010
Return-Path: <abegen@cisco.com>
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 5507A3A69AE for <fecframe@core3.amsl.com>; Sat,  9 Jan 2010 17:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 9ecD2gzKpKEL for <fecframe@core3.amsl.com>; Sat,  9 Jan 2010 17:08:24 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 783DC3A6407 for <fecframe@ietf.org>; Sat,  9 Jan 2010 17:08:24 -0800 (PST)
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: ApoEAHq3SEurR7Hu/2dsb2JhbADAepNLhC8E
X-IronPort-AV: E=Sophos;i="4.49,248,1262563200"; d="scan'208";a="286572919"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 10 Jan 2010 01:08:22 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o0A18MCo027499; Sun, 10 Jan 2010 01:08:22 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);  Sat, 9 Jan 2010 17:08:22 -0800
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: Sat, 9 Jan 2010 17:08:23 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540AFD8433@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <C76936FE.36906%watson@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-raptor-01
Thread-Index: AcpYytE8kvmuKdUwTmCg6CvJecOy4g1rh+GGAB3OdzA=
References: <04CAD96D4C5A3D48B1919248A8FE0D540A84366F@xmb-sjc-215.amer.cisco.com> <C76936FE.36906%watson@qualcomm.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Watson, Mark" <watson@qualcomm.com>, <fecframe@ietf.org>
X-OriginalArrivalTime: 10 Jan 2010 01:08:22.0786 (UTC) FILETIME=[67993620:01CA9191]
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-raptor-01
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jan 2010 01:08:25 -0000

Hi Mark,

> My responses to your comments are inline below with the exception of =
the last one
> regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion on =
that. I am confused
> about what =93multiple distinct elements=94 means in the SDP elements =
draft: you define the
> FSSI it to be just *CHAR =96 no notion of =91element=92 is defined.

Here is an example from the SDP draft:

        a=3Dfec-repair-flow: encoding-id=3D0; ss-fssi=3Dn:7,k:5

n, k are distinct elements, and the ss-fssi is a *char.

>=20
> A consequence of this decision is that the FEC Framework must require =
FEC Schemes to
> define a text format for the SS-FSSI and FSSI (so I need to add that) =
and furthermore that
> this format must not include the =91;=92 character or Carriage Return =
(otherwise things become
> ambiguous in the SDP case). This seems a little arbitrary =
(SDP-specific encoding
> requirements polluting the FEC framework), but I guess that=92s my =
fault for missing the
> discussion.

I believe this was voted in Stockholm and I had sent an email in the =
list.
=20
> What did you decide regarding binary encodings ? Must FEC Schemes =
define these or must all
> CDPs provide for text transport ?

All need to provide text transport.
=20
> 	In case of RTP transport, source and repair data can be in different =
RTP streams,
> where they are SSRC multiplexed in the same RTP session. From outside, =
they look like a
> single UDP flow. The sentence above contradicts with this. I suggest =
to change it as
> follows:
>=20
> 	   Per the FEC Framework requirements, the sender MUST transmit the
> 	   source and repair packets in different source and repair streams,
> 	   respectively.
>=20
>=20
>=20
> MW: I suggest =93Per the FEC Framework requirements, the sender MUST =
transmit the source and
> repair packets in different source and repair flows, or in the case =
RTP transport is used
> for Repair packets, in different RTP streams.=94

Sure, it should be "repair packets" not "Repair packets". Also you might =
wanna divide this into two sentences rather than a big sentence.
=20
> 	- Section 8.2.4. What about the length of the RTP header extensions?
>=20
>=20
>=20
> MW: Good point. In DVB the X bit was not allowed to be set, so the =
header extension was
> not mentioned. I will add it.

OK.
=20
>=20
>=20
> 	- Section 9: No specific security considerations?
>=20
>=20
>=20
> MW: Not that I can think of. We define here specific encodings and =
packet formats but the
> same security issues apply however this information is encoded and are =
dealt with in the
> FEC framework. I will add a note to this effect.
>=20

Good idea.=20

-acbegen

From abegen@cisco.com  Sat Jan  9 17:14:33 2010
Return-Path: <abegen@cisco.com>
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 0AD4B3A69B7 for <fecframe@core3.amsl.com>; Sat,  9 Jan 2010 17:14:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 HUgJHFch-ZT4 for <fecframe@core3.amsl.com>; Sat,  9 Jan 2010 17:14:32 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E80A33A69AE for <fecframe@ietf.org>; Sat,  9 Jan 2010 17:14:31 -0800 (PST)
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: ApoEAOO4SEurRN+J/2dsb2JhbADAfJNJhC8E
X-IronPort-AV: E=Sophos;i="4.49,248,1262563200"; d="scan'208";a="130911615"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Jan 2010 01:14:30 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0A1EU3D016390; Sun, 10 Jan 2010 01:14:30 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);  Sat, 9 Jan 2010 17:14:30 -0800
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: Sat, 9 Jan 2010 17:14:28 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540AFD8434@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <C76A893F.369BC%watson@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
Thread-Index: AcpXi3s0CQY7ynlsQyqxaZIfFXdzQQ3txMCiAE2XZlA=
References: <04CAD96D4C5A3D48B1919248A8FE0D540A843093@xmb-sjc-215.amer.cisco.com> <C76A893F.369BC%watson@qualcomm.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Watson, Mark" <watson@qualcomm.com>, <fecframe@ietf.org>
X-OriginalArrivalTime: 10 Jan 2010 01:14:30.0157 (UTC) FILETIME=[429193D0:01CA9192]
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Jan 2010 01:14:33 -0000

> MW: Presuably only on the first mention of RTP ?

Sure but also whenever it feels appropriate.
 =20
>=20
> 	- Section 3: "... In this case, in the language of the FEC Framework, =
there is no
> explicit FEC Source Payload Id." --> "... there is no (need for) =
explicit ..."
>=20
>=20
>=20
> MW: I suggest =93In this case, in the language of the FEC Framework, =
there is no need for an
> explicit FEC Source Payload Id and it is therefore not included in the =
packets.=94

Sounds good.
=20
> 	- Section 4.2 and 4.3: This is the part that needs some work. I don't =
think we can
> simply refer to the framework and fecframe-raptor drafts and leave =
these parts (which are
> the most critical sections in a payload draft) empty. First of all, =
why is there a
> reference to the framework draft? Secondly, this section needs to make =
it clear that the
> payload draft is for the last FEC scheme introduced in the =
fecframe-raptor draft (Section
> 8).
>=20
> 	In the current draft, it says there is no (FEC) payload header. So, I =
guess
> everything goes into the RTP payload. However, IMO it is better to =
introduce the Repair
> FEC Payload ID (section 8.1.3 of the fecframe-raptor draft) as the FEC =
payload header, and
> then put the repair symbols as the RTP payload. This makes it a better =
representation and
> easier for others to visualize the encoding/decoding ops.
>=20
>=20
>=20
> MW: I disagree on these two points. The FEC Framework clearly defines =
the FEC Repair
> Payload, making reference to the details which must be filled in by an =
FEC Scheme. So the
> Framework, together with an FEC Scheme, fully defines the FEC Repair =
Payload for that
> scheme and all that remains is for us to say where in the RTP packet =
the FEC Repair
> Payload appears. Making reference to the internal structure of the FEC =
Repair Payload
> (Repair FEC Payload Id etc.) would be duplicate specification.

Fine for me. But, I must say this looked strange (or somewhat empty) to =
me the first time I read.=20

>=20
> The payload format defined here could be used with any of the schemes =
defined in the
> Raptor FEC Schemes document.

This was not clear to me. I thought RTP transport only applied to the =
single-sequenced flows. This seems to be what the fecframe-raptor is =
saying, too.
=20
>=20
>=20
> 	- Are there any requirements for max-sbl and symbol-size parameters? =
If yes, they
> must be stated in every subsection of 6.3.
>=20
>=20
>=20
> MW: The requirements are in the FEC Schemes and should not be =
duplicated here.

I=92d imagine you would get a similar comment from IESG on this. This is =
the payload format registration so IMO it should have all the reqs, =
exceptions, magical numbers, etc.
=20
> 	- Section 7: The mapping to the SDP parameters should be explained. =
There is a
> boilerplate for it. Just apply it to your document.
>=20
> 	- Section 8 and 9: I am pretty sure there are some offer/answer model =
and declarative
> SDP considerations. Again, there is a boilerplate for it, but it must =
be modified a little
> bit to fit to the specifics of this payload format.
>=20
>=20
>=20
> MW: Where can I get the boilerplate ? I took the specification format =
from Magnus=92 =93how
> to=94, but I didn=92t see additional boilerplate for these sections.

Just check one of the recent payload format registrations.=20
http://www.ietf.org/rfc/rfc5577.txt
Or more relevantly, check=20
http://tools.ietf.org/html/draft-ietf-fecframe-1d2d-parity-scheme-01 =20

=20
> 	- Section 11: There is a boilerplate for security considerations =
section and all RTP
> payload format drafts use it. That should be included here.
>=20
>=20
>=20
> MW: Let me know where, although I don=92t see that there could be any =
Raptor-specific
> security considerations.

See the refs above.
=20
-acbegen


From wwwrun@core3.amsl.com  Mon Jan 11 09:10:13 2010
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: fecframe@ietf.org
Delivered-To: fecframe@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id C3BED3A6941; Mon, 11 Jan 2010 09:10:13 -0800 (PST)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20100111171013.C3BED3A6941@core3.amsl.com>
Date: Mon, 11 Jan 2010 09:10:13 -0800 (PST)
Cc: fecframe chair <fecframe-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, fecframe mailing list <fecframe@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Fecframe] Document Action: 'Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection' to Informational RFC
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 17:10:13 -0000

The IESG has approved the following document:

- 'Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC 
   Protection '
   <draft-ietf-fecframe-dvb-al-fec-04.txt> as an Informational RFC


This document is the product of the FEC Framework Working Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-dvb-al-fec-04.txt

Technical Summary
The Annex E of the DVB-IPTV technical specification defines an
optional Application-layer Forward Error Correction (AL-FEC) protocol
to protect the streaming media carried over RTP transport. The
DVB-IPTV AL-FEC protocol uses two layers for FEC protection: 1-D
parity code base layer, and a Raptor code enhancement layer. By
offering a layered approach, the DVB-IPTV AL-FEC protocol offers a
good protection against both bursty and random packet loss at a cost
of decent complexity. This document describes how one can implement
the DVB-IPTV AL-FEC protocol by using the 1-D interleaved parity code
and the Raptor code which are specified in separate documents

Working Group Summary
There were no seriously contentious issues during the WG process. The
only controversy stemmed from some individuals who did the work in
SMPTE and defied this approach in the DVB spec, who felt the IETF
should not be doing this work. But there were industry requests for an
IETF definition of the DVB spec and so this work progressed.

Document Quality
Any DVB-compliant implementation will be compliant with the DVP-IPTV
AL-FEC specification as well.

Personal
Document Shepherd – Greg Shepherd
Responsible Area Director - Magnus Westerlund


From watson@qualcomm.com  Mon Jan 11 09:43:59 2010
Return-Path: <watson@qualcomm.com>
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 4BCB93A687D for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 09:43:59 -0800 (PST)
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 A2VILplphkuV for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 09:43:52 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 66B113A67E6 for <fecframe@ietf.org>; Mon, 11 Jan 2010 09:43:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1263231830; x=1294767830; 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"Watson,=20Mark"=20<watson@qualcomm.com>|To:=20" Ali=20C.=20Begen=20(abegen)"=20<abegen@cisco.com>,=0D=0A =20=20=20=20=20=20=20=20"fecframe@ietf.org"=0D=0A=09<fecf rame@ietf.org>|Date:=20Mon,=2011=20Jan=202010=2009:43:30 =20-0800|Subject:=20Re:=20[Fecframe]=20Review=20for=20dra ft-ietf-fecframe-raptor-01|Thread-Topic:=20[Fecframe]=20R eview=20for=20draft-ietf-fecframe-raptor-01|Thread-Index: =20AcpYytE8kvmuKdUwTmCg6CvJecOy4g1rh+GGAB3OdzAA/Vrr8w=3D =3D|Message-ID:=20<C770A342.36B14%watson@qualcomm.com> |In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D540AFD8433 @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=09boundar y=3D"_000_C770A34236B14watsonqualcommcom_"|MIME-Version: =201.0; bh=3gxyqKcVXdRwRVxwKs/+NUb5aw1eI0H5DQNGfW/gSc0=; b=bE4a0D4v14grJMpgSSzqlhOKDdQeCoRVYFQCOznX4CKzkL6Mpd+qsti+ Y3c3G4ecisjsP8ZsRiAxDAF4gmRkt2PnvmFEj1tChVJL9OZMLS/1AaYUg nLji1+EikKyGuumVnwWahi0Q2FXSbvcvi/Sb686sHROTzczAzmqbfTri6 Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,5858"; a="31780636"
Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 11 Jan 2010 09:43:32 -0800
Received: from ironrogue.qualcomm.com (ironrogue.qualcomm.com [129.46.61.164]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0BHhWA8023298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <fecframe@ietf.org>; Mon, 11 Jan 2010 09:43:32 -0800
X-IronPort-AV: E=Sophos;i="4.49,257,1262592000"; d="scan'208,217";a="30637170"
Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 11 Jan 2010 09:43:32 -0800
Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 11 Jan 2010 09:43:31 -0800
Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Mon, 11 Jan 2010 09:43:31 -0800
From: "Watson, Mark" <watson@qualcomm.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "fecframe@ietf.org" <fecframe@ietf.org>
Date: Mon, 11 Jan 2010 09:43:30 -0800
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-raptor-01
Thread-Index: AcpYytE8kvmuKdUwTmCg6CvJecOy4g1rh+GGAB3OdzAA/Vrr8w==
Message-ID: <C770A342.36B14%watson@qualcomm.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540AFD8433@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_C770A34236B14watsonqualcommcom_"
MIME-Version: 1.0
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-raptor-01
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 17:43:59 -0000

--_000_C770A34236B14watsonqualcommcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ali,

See inline...

...Mark

On 1/9/10 5:08 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

Hi Mark,

> My responses to your comments are inline below with the exception of the =
last one
> regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion on tha=
t. I am confused
> about what "multiple distinct elements" means in the SDP elements draft: =
you define the
> FSSI it to be just *CHAR - no notion of 'element' is defined.

Here is an example from the SDP draft:

        a=3Dfec-repair-flow: encoding-id=3D0; ss-fssi=3Dn:7,k:5

n, k are distinct elements, and the ss-fssi is a *char.

Yes, well, I can see that because I am a human being with some reasonably a=
dvanced cognitive functions ;-) But there is no sense of element defined in=
 a formal sense that I could implement.

The options are to define some kind of syntax (e.g. comma-separated list of=
 <name> ":" <value> pairs) that all FEC Schemes must use, or to leave it as=
 an opaque field for the FEC Scheme to define the syntax, subject to the fr=
aming rules imposed by the attribute definition.

>
> A consequence of this decision is that the FEC Framework must require FEC=
 Schemes to
> define a text format for the SS-FSSI and FSSI (so I need to add that) and=
 furthermore that
> this format must not include the ';' character or Carriage Return (otherw=
ise things become
> ambiguous in the SDP case). This seems a little arbitrary (SDP-specific e=
ncoding
> requirements polluting the FEC framework), but I guess that's my fault fo=
r missing the
> discussion.

I believe this was voted in Stockholm and I had sent an email in the list.

I don't believe the details above were addressed.

> What did you decide regarding binary encodings ? Must FEC Schemes define =
these or must all
> CDPs provide for text transport ?

All need to provide text transport.

So, this change needs to be made in the Framework.

>       In case of RTP transport, source and repair data can be in differen=
t RTP streams,
> where they are SSRC multiplexed in the same RTP session. From outside, th=
ey look like a
> single UDP flow. The sentence above contradicts with this. I suggest to c=
hange it as
> follows:
>
>          Per the FEC Framework requirements, the sender MUST transmit the
>          source and repair packets in different source and repair streams=
,
>          respectively.
>
>
>
> MW: I suggest "Per the FEC Framework requirements, the sender MUST transm=
it the source and
> repair packets in different source and repair flows, or in the case RTP t=
ransport is used
> for Repair packets, in different RTP streams."

Sure, it should be "repair packets" not "Repair packets". Also you might wa=
nna divide this into two sentences rather than a big sentence.

>       - Section 8.2.4. What about the length of the RTP header extensions=
?
>
>
>
> MW: Good point. In DVB the X bit was not allowed to be set, so the header=
 extension was
> not mentioned. I will add it.

OK.

>
>
>       - Section 9: No specific security considerations?
>
>
>
> MW: Not that I can think of. We define here specific encodings and packet=
 formats but the
> same security issues apply however this information is encoded and are de=
alt with in the
> FEC framework. I will add a note to this effect.
>

Good idea.

-acbegen


--_000_C770A34236B14watsonqualcommcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Fecframe] Review for draft-ietf-fecframe-raptor-01</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Hi Ali,<BR>
<BR>
See inline...<BR>
<BR>
...Mark<BR>
<BR>
On 1/9/10 5:08 PM, &quot;Ali C. Begen (abegen)&quot; &lt;<a href=3D"abegen@=
cisco.com">abegen@cisco.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>Hi Mark,<BR>
<BR>
&gt; My responses to your comments are inline below with the exception of t=
he last one<BR>
&gt; regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion on =
that. I am confused<BR>
&gt; about what &#8220;multiple distinct elements&#8221; means in the SDP e=
lements draft: you define the<BR>
&gt; FSSI it to be just *CHAR &#8211; no notion of &#8216;element&#8217; is=
 defined.<BR>
<BR>
Here is an example from the SDP draft:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a=3Dfec-repair-flow: encodi=
ng-id=3D0; ss-fssi=3Dn:7,k:5<BR>
<BR>
n, k are distinct elements, and the ss-fssi is a *char.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>Yes, well, <B>I </B>can see that because I=
 am a human being with some reasonably advanced cognitive functions ;-) But=
 there is no sense of element defined in a formal sense that I could implem=
ent.<BR>
<BR>
The options are to define some kind of syntax (e.g. comma-separated list of=
 &lt;name&gt; &#8220;:&#8221; &lt;value&gt; pairs) that all FEC Schemes mus=
t use, or to leave it as an opaque field for the FEC Scheme to define the s=
yntax, subject to the framing rules imposed by the attribute definition.<BR=
>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
&gt;<BR>
&gt; A consequence of this decision is that the FEC Framework must require =
FEC Schemes to<BR>
&gt; define a text format for the SS-FSSI and FSSI (so I need to add that) =
and furthermore that<BR>
&gt; this format must not include the &#8216;;&#8217; character or Carriage=
 Return (otherwise things become<BR>
&gt; ambiguous in the SDP case). This seems a little arbitrary (SDP-specifi=
c encoding<BR>
&gt; requirements polluting the FEC framework), but I guess that&#8217;s my=
 fault for missing the<BR>
&gt; discussion.<BR>
<BR>
I believe this was voted in Stockholm and I had sent an email in the list.<=
BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>I don&#8217;t believe the details above we=
re addressed.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
&gt; What did you decide regarding binary encodings ? Must FEC Schemes defi=
ne these or must all<BR>
&gt; CDPs provide for text transport ?<BR>
<BR>
All need to provide text transport.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>So, this change needs to be made in the Fr=
amework.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;In case of RTP transport, source a=
nd repair data can be in different RTP streams,<BR>
&gt; where they are SSRC multiplexed in the same RTP session. From outside,=
 they look like a<BR>
&gt; single UDP flow. The sentence above contradicts with this. I suggest t=
o change it as<BR>
&gt; follows:<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Per the FEC Fram=
ework requirements, the sender MUST transmit the<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;source and repai=
r packets in different source and repair streams,<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;respectively.<BR=
>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; MW: I suggest &#8220;Per the FEC Framework requirements, the sender MU=
ST transmit the source and<BR>
&gt; repair packets in different source and repair flows, or in the case RT=
P transport is used<BR>
&gt; for Repair packets, in different RTP streams.&#8221;<BR>
<BR>
Sure, it should be &quot;repair packets&quot; not &quot;Repair packets&quot=
;. Also you might wanna divide this into two sentences rather than a big se=
ntence.<BR>
<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Section 8.2.4. What about the le=
ngth of the RTP header extensions?<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; MW: Good point. In DVB the X bit was not allowed to be set, so the hea=
der extension was<BR>
&gt; not mentioned. I will add it.<BR>
<BR>
OK.<BR>
<BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Section 9: No specific security =
considerations?<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; MW: Not that I can think of. We define here specific encodings and pac=
ket formats but the<BR>
&gt; same security issues apply however this information is encoded and are=
 dealt with in the<BR>
&gt; FEC framework. I will add a note to this effect.<BR>
&gt;<BR>
<BR>
Good idea.<BR>
<BR>
-acbegen<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C770A34236B14watsonqualcommcom_--

From abegen@cisco.com  Mon Jan 11 12:02:48 2010
Return-Path: <abegen@cisco.com>
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 29B993A6926 for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 12:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 jn3i+CgjB1ot for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 12:02:47 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 06DF33A68F3 for <fecframe@ietf.org>; Mon, 11 Jan 2010 12:02:47 -0800 (PST)
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: ApoEAEoSS0urR7Ht/2dsb2JhbADDOZQAhC8E
X-IronPort-AV: E=Sophos;i="4.49,257,1262563200"; d="scan'208";a="72931642"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 11 Jan 2010 20:02:44 +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 o0BK2fC4010905; Mon, 11 Jan 2010 20:02:44 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);  Mon, 11 Jan 2010 12:02:44 -0800
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, 11 Jan 2010 12:02:47 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B06A3DC@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <C770A342.36B14%watson@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-raptor-01
Thread-Index: AcpYytE8kvmuKdUwTmCg6CvJecOy4g1rh+GGAB3OdzAA/Vrr8wAAQRkA
References: <04CAD96D4C5A3D48B1919248A8FE0D540AFD8433@xmb-sjc-215.amer.cisco.com> <C770A342.36B14%watson@qualcomm.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Watson, Mark" <watson@qualcomm.com>, <fecframe@ietf.org>
X-OriginalArrivalTime: 11 Jan 2010 20:02:44.0488 (UTC) FILETIME=[09F28080:01CA92F9]
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-raptor-01
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 20:02:48 -0000

> 	> My responses to your comments are inline below with the exception =
of the last one
> 	> regarding FS-FSSI and FSSI encoding: Sorry I missed the discussion =
on that. I am
> confused
> 	> about what =93multiple distinct elements=94 means in the SDP =
elements draft: you define
> the
> 	> FSSI it to be just *CHAR =96 no notion of =91element=92 is defined.
>=20
> 	Here is an example from the SDP draft:
>=20
> 	        a=3Dfec-repair-flow: encoding-id=3D0; ss-fssi=3Dn:7,k:5
>=20
> 	n, k are distinct elements, and the ss-fssi is a *char.
>=20
>=20
>=20
> Yes, well, I can see that because I am a human being with some =
reasonably advanced
> cognitive functions ;-) But there is no sense of element defined in a =
formal sense that I
> could implement.

:)
=20
> The options are to define some kind of syntax (e.g. comma-separated =
list of <name> =93:=94
> <value> pairs) that all FEC Schemes must use, or to leave it as an =
opaque field for the
> FEC Scheme to define the syntax, subject to the framing rules imposed =
by the attribute
> definition.

I believe the former of what you said above is a good syntax. Could we =
get it in the framework draft?
=20
>=20
>=20
> 	>
> 	> A consequence of this decision is that the FEC Framework must =
require FEC Schemes
> to
> 	> define a text format for the SS-FSSI and FSSI (so I need to add =
that) and
> furthermore that
> 	> this format must not include the =91;=92 character or Carriage =
Return (otherwise things
> become
> 	> ambiguous in the SDP case). This seems a little arbitrary =
(SDP-specific encoding
> 	> requirements polluting the FEC framework), but I guess that=92s my =
fault for missing
> the
> 	> discussion.
>=20
> 	I believe this was voted in Stockholm and I had sent an email in the =
list.
>=20
>=20
>=20
> I don=92t believe the details above were addressed.
>=20
>=20
>=20
> 	> What did you decide regarding binary encodings ? Must FEC Schemes =
define these or
> must all
> 	> CDPs provide for text transport ?
>=20
> 	All need to provide text transport.
>=20
>=20
>=20
> So, this change needs to be made in the Framework.

Yes.

-acbegen


From watson@qualcomm.com  Mon Jan 11 15:47:48 2010
Return-Path: <watson@qualcomm.com>
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 0D6E63A6881 for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 15:47:48 -0800 (PST)
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 X95KLflso6Kl for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 15:47:43 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 57F113A67F5 for <fecframe@ietf.org>; Mon, 11 Jan 2010 15:47:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1263253661; x=1294789661; 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"Watson,=20Mark"=20<watson@qualcomm.com>|To:=20" Ali=20C.=20Begen=20(abegen)"=20<abegen@cisco.com>,=0D=0A =20=20=20=20=20=20=20=20"fecframe@ietf.org"=0D=0A=09<fecf rame@ietf.org>|Date:=20Mon,=2011=20Jan=202010=2015:47:36 =20-0800|Subject:=20Re:=20[Fecframe]=20Review=20for=20dra ft-ietf-fecframe-rtp-raptor-02|Thread-Topic:=20[Fecframe] =20Review=20for=20draft-ietf-fecframe-rtp-raptor-02 |Thread-Index:=20AcpXi3s0CQY7ynlsQyqxaZIfFXdzQQ3txMCiAE2X ZlAAp+Htxg=3D=3D|Message-ID:=20<C770F898.36B61%watson@qua lcomm.com>|In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D 540AFD8434@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=09boundar y=3D"_000_C770F89836B61watsonqualcommcom_"|MIME-Version: =201.0; bh=QVn3JNJaVzRgjn1CMXpRX/I1Stbb/L4DUyHAy6UFsK4=; b=hbIVkq2/EB5Itp/SAM28uYG++SZ66v1BVrwq2tCsxueKT6mLJ91/o+Nx WkeOrZCZ2noVqEfTuo3zsq34pSZBoxIgmnvcYASGL1kLFqKf9e5o4YRz+ lYjQX+vm4ds0HdtbWsAGpXIPiB02QJUvljEeVrRbwDhMxslV/kPTS9QRb 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,5858"; a="31804715"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 11 Jan 2010 15:47:41 -0800
Received: from ironstorm.qualcomm.com (ironstorm.qualcomm.com [172.30.39.153]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id o0BNleSu022299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <fecframe@ietf.org>; Mon, 11 Jan 2010 15:47:41 -0800
X-IronPort-AV: E=Sophos;i="4.49,258,1262592000"; d="scan'208,217";a="31542860"
Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 11 Jan 2010 15:47:40 -0800
Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 11 Jan 2010 15:47:40 -0800
Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Mon, 11 Jan 2010 15:47:40 -0800
From: "Watson, Mark" <watson@qualcomm.com>
To: "Ali C. Begen (abegen)" <abegen@cisco.com>, "fecframe@ietf.org" <fecframe@ietf.org>
Date: Mon, 11 Jan 2010 15:47:36 -0800
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
Thread-Index: AcpXi3s0CQY7ynlsQyqxaZIfFXdzQQ3txMCiAE2XZlAAp+Htxg==
Message-ID: <C770F898.36B61%watson@qualcomm.com>
In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540AFD8434@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_C770F89836B61watsonqualcommcom_"
MIME-Version: 1.0
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jan 2010 23:47:48 -0000

--_000_C770F89836B61watsonqualcommcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ali,

Responses inline...


On 1/9/10 5:14 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:

<snip>

>
> The payload format defined here could be used with any of the schemes def=
ined in the
> Raptor FEC Schemes document.

This was not clear to me. I thought RTP transport only applied to the singl=
e-sequenced flows. This seems to be what the fecframe-raptor is saying, too=
.

MW: The single-sequenced-flow scheme can apply to any source flow where the=
re is already a sequence number and an RTP source flow is a formally define=
d example of that.

But in this document we are discussing RTP *repair flows* and these can be =
used with any of the FEC Schemes. For example if you want to protect multip=
le source flows with a single repair flow you would need one of the schemes=
 with an explicit FEC Source Payload Id.

>
>
>       - Are there any requirements for max-sbl and symbol-size parameters=
? If yes, they
> must be stated in every subsection of 6.3.
>
>
>
> MW: The requirements are in the FEC Schemes and should not be duplicated =
here.

I'd imagine you would get a similar comment from IESG on this. This is the =
payload format registration so IMO it should have all the reqs, exceptions,=
 magical numbers, etc.

MW: Incorporating information by reference is formally equivalent to includ=
ing the information directly, but avoids duplication of documentation. So a=
ll the information is included. I can add some more explanation of this.

...Mark


--_000_C770F89836B61watsonqualcommcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Hi Ali,<BR>
<BR>
Responses inline...<BR>
<BR>
<BR>
On 1/9/10 5:14 PM, &quot;Ali C. Begen (abegen)&quot; &lt;<a href=3D"abegen@=
cisco.com">abegen@cisco.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'>&lt;snip&gt;<BR>
<BR>
&gt;<BR>
&gt; The payload format defined here could be used with any of the schemes =
defined in the<BR>
&gt; Raptor FEC Schemes document.<BR>
<BR>
This was not clear to me. I thought RTP transport only applied to the singl=
e-sequenced flows. This seems to be what the fecframe-raptor is saying, too=
.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: The single-sequenced-flow scheme can a=
pply to any source flow where there is already a sequence number and an RTP=
 source flow is a formally defined example of that.<BR>
<BR>
But in this document we are discussing RTP *repair flows* and these can be =
used with any of the FEC Schemes. For example if you want to protect multip=
le source flows with a single repair flow you would need one of the schemes=
 with an explicit FEC Source Payload Id.<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
&gt;<BR>
&gt;<BR>
&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;- Are there any requirements for m=
ax-sbl and symbol-size parameters? If yes, they<BR>
&gt; must be stated in every subsection of 6.3.<BR>
&gt;<BR>
&gt;<BR>
&gt;<BR>
&gt; MW: The requirements are in the FEC Schemes and should not be duplicat=
ed here.<BR>
<BR>
I&#8217;d imagine you would get a similar comment from IESG on this. This i=
s the payload format registration so IMO it should have all the reqs, excep=
tions, magical numbers, etc.<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>MW: Incorporating information by reference=
 is formally equivalent to including the information directly, but avoids d=
uplication of documentation. So all the information <B>is</B> included. I c=
an add some more explanation of this.<BR>
<BR>
...Mark<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C770F89836B61watsonqualcommcom_--

From abegen@cisco.com  Mon Jan 11 17:09:06 2010
Return-Path: <abegen@cisco.com>
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 EA5953A68B8 for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 17:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 YYx4VV2u4qzA for <fecframe@core3.amsl.com>; Mon, 11 Jan 2010 17:09:06 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B27C3A689D for <fecframe@ietf.org>; Mon, 11 Jan 2010 17:09:06 -0800 (PST)
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: ApoEAIVaS0urR7Ht/2dsb2JhbADCR5QdhC8Egxk
X-IronPort-AV: E=Sophos;i="4.49,259,1262563200"; d="scan'208";a="287079839"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 12 Jan 2010 01:09:04 +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 o0C1943r016149; Tue, 12 Jan 2010 01:09:04 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);  Mon, 11 Jan 2010 17:09:03 -0800
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, 11 Jan 2010 17:09:06 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B06A5D8@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <C770F898.36B61%watson@qualcomm.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
Thread-Index: AcpXi3s0CQY7ynlsQyqxaZIfFXdzQQ3txMCiAE2XZlAAp+HtxgACxXUQ
References: <04CAD96D4C5A3D48B1919248A8FE0D540AFD8434@xmb-sjc-215.amer.cisco.com> <C770F898.36B61%watson@qualcomm.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Watson, Mark" <watson@qualcomm.com>, <fecframe@ietf.org>
X-OriginalArrivalTime: 12 Jan 2010 01:09:03.0911 (UTC) FILETIME=[D4EFE370:01CA9323]
Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2010 01:09:07 -0000

Hi Mark,

> -----Original Message-----
> From: Watson, Mark [mailto:watson@qualcomm.com]
> Sent: Monday, January 11, 2010 3:48 PM
> To: Ali C. Begen (abegen); fecframe@ietf.org
> Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02
>=20
> Hi Ali,
>=20
> Responses inline...
>=20
>=20
> On 1/9/10 5:14 PM, "Ali C. Begen (abegen)" <abegen@cisco.com> wrote:
>=20
>=20
>=20
> 	<snip>
>=20
> 	>
> 	> The payload format defined here could be used with any of the =
schemes defined in
> the
> 	> Raptor FEC Schemes document.
>=20
> 	This was not clear to me. I thought RTP transport only applied to the =
single-
> sequenced flows. This seems to be what the fecframe-raptor is saying, =
too.
>=20
>=20
>=20
> MW: The single-sequenced-flow scheme can apply to any source flow =
where there is already a
> sequence number and an RTP source flow is a formally defined example =
of that.
>=20
> But in this document we are discussing RTP *repair flows* and these =
can be used with any
> of the FEC Schemes. For example if you want to protect multiple source =
flows with a single
> repair flow you would need one of the schemes with an explicit FEC =
Source Payload Id.

Could you make this more clear in the text?=20

=20
>=20
>=20
> 	>
> 	>
> 	>       - Are there any requirements for max-sbl and symbol-size =
parameters? If yes,
> they
> 	> must be stated in every subsection of 6.3.
> 	>
> 	>
> 	>
> 	> MW: The requirements are in the FEC Schemes and should not be =
duplicated here.
>=20
> 	I=92d imagine you would get a similar comment from IESG on this. This =
is the payload
> format registration so IMO it should have all the reqs, exceptions, =
magical numbers, etc.
>=20
>=20
>=20
> MW: Incorporating information by reference is formally equivalent to =
including the
> information directly, but avoids duplication of documentation. So all =
the information is
> included. I can add some more explanation of this.

Would be useful.

Thanks.
-acbegen

=20
> ...Mark
>=20
>=20
>=20
>=20


From root@core3.amsl.com  Tue Jan 12 23:15:02 2010
Return-Path: <root@core3.amsl.com>
X-Original-To: fecframe@ietf.org
Delivered-To: fecframe@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 2AF293A68EC; Tue, 12 Jan 2010 23:15:01 -0800 (PST)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20100113071502.2AF293A68EC@core3.amsl.com>
Date: Tue, 12 Jan 2010 23:15:02 -0800 (PST)
Cc: fecframe@ietf.org
Subject: [Fecframe] I-D Action:draft-ietf-fecframe-interleaved-fec-scheme-09.txt
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jan 2010 07:15:02 -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           : RTP Payload Format for 1-D Interleaved Parity FEC
	Author(s)       : A. Begen
	Filename        : draft-ietf-fecframe-interleaved-fec-scheme-09.txt
	Pages           : 32
	Date            : 2010-01-12

This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP.  The 1-D interleaved parity
code is a systematic code, where a number of repair symbols are
generated from a set of source symbols and sent in a repair flow
separate from the source flow that carries the source symbols.  The
1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of reasonable complexity.  The new payload
format defined in this document should only be used (with some
exceptions) as a part of the DVB-IPTV Application-layer FEC
specification.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 16, 2010.

Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-09.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-interleaved-fec-scheme-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2010-01-12231337.I-D@ietf.org>


--NextPart--

From magnus.westerlund@ericsson.com  Thu Jan 14 02:15:34 2010
Return-Path: <magnus.westerlund@ericsson.com>
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 ECC1B28C0D7 for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 02:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.209
X-Spam-Level: 
X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.040,  BAYES_00=-2.599, HELO_EQ_SE=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 8vnZrBBgJ+fP for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 02:15:33 -0800 (PST)
Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id C639328C0D6 for <fecframe@ietf.org>; Thu, 14 Jan 2010 02:15:32 -0800 (PST)
X-AuditID: c1b4fb24-b7bb6ae000001052-7f-4b4eeec02034
Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id A7.25.04178.0CEEE4B4; Thu, 14 Jan 2010 11:15:28 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 11:15:28 +0100
Received: from [147.214.183.147] ([147.214.183.147]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 14 Jan 2010 11:15:28 +0100
Message-ID: <4B4EEEC0.2020102@ericsson.com>
Date: Thu, 14 Jan 2010 11:15:28 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0
MIME-Version: 1.0
To: fecframe@ietf.org
References: <38c19b540912040749y72cb3be2wec6cd1aa13c1d46@mail.gmail.com>
In-Reply-To: <38c19b540912040749y72cb3be2wec6cd1aa13c1d46@mail.gmail.com>
X-Enigmail-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 14 Jan 2010 10:15:28.0539 (UTC) FILETIME=[7EEC9EB0:01CA9502]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [Fecframe] WG Last Call - Framework
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 10:15:34 -0000

WG,

This is one of your core documents. I have seen ONE (1) single comment
that someone has read the document. I do expect to see a bit more
reviews on this before I can consider there be consensus for publication
in the WG.

Magnus Westerlund

Greg Shepherd skrev 2009-12-04 16:49:
> Yes, we called LC on this earlier but I received feedback that there
> just wasn't enough time...
> 
> So, let's keep the WG LC open with a comment due date pushed out to
> Jan 8th to allow for the Holidays. I'll send weekly reminders to keep
> everyone on task. Please read and respond so we can ship and shut. ;-)
> 
> Thanks!,
> Greg
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe
> 


-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

From orlyp@radvision.com  Thu Jan 14 02:30:42 2010
Return-Path: <orlyp@radvision.com>
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 5AF933A6830 for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 02:30:42 -0800 (PST)
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 Hwv1Ko4w-QDy for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 02:30:41 -0800 (PST)
Received: from eframer.radvision.com (rvil-eframer.RADVISION.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 7FACF3A6774 for <fecframe@ietf.org>; Thu, 14 Jan 2010 02:30:40 -0800 (PST)
Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o0EAUgx2029346 for fecframe@ietf.org; Thu, 14 Jan 2010 12:30:42 +0200
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 o0EAUg2s029340;  Thu, 14 Jan 2010 12:30:42 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Thu, 14 Jan 2010 12:30:33 +0200
Message-ID: <E7D8D1A37669BA428A72828A4DD999AD02146B5B@rvil-mail1.RADVISION.com>
In-Reply-To: <4B4EEEC0.2020102@ericsson.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] WG Last Call - Framework
Thread-Index: AcqVAqd/2L4jLOg1RtG5zhVkN8FMUQAAdv2Q
References: <38c19b540912040749y72cb3be2wec6cd1aa13c1d46@mail.gmail.com> <4B4EEEC0.2020102@ericsson.com>
From: "Orly Peck" <orlyp@radvision.com>
To: "Magnus Westerlund" <magnus.westerlund@ericsson.com>, <fecframe@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by eframer.radvision.com id o0EAUg2s029340
Subject: Re: [Fecframe] WG Last Call - Framework
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 10:30:42 -0000

Hi, 
I will review the document early next week.
Thanks,
Orly Peck.

-----Original Message-----
From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Magnus Westerlund
Sent: Thursday, January 14, 2010 12:15 PM
To: fecframe@ietf.org
Subject: Re: [Fecframe] WG Last Call - Framework

WG,

This is one of your core documents. I have seen ONE (1) single comment
that someone has read the document. I do expect to see a bit more
reviews on this before I can consider there be consensus for publication
in the WG.

Magnus Westerlund

Greg Shepherd skrev 2009-12-04 16:49:
> Yes, we called LC on this earlier but I received feedback that there
> just wasn't enough time...
> 
> So, let's keep the WG LC open with a comment due date pushed out to
> Jan 8th to allow for the Holidays. I'll send weekly reminders to keep
> everyone on task. Please read and respond so we can ship and shut. ;-)
> 
> Thanks!,
> Greg
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe
> 


-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe


From gjshep@gmail.com  Thu Jan 14 07:09:42 2010
Return-Path: <gjshep@gmail.com>
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 49BEB3A6782 for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 07:09:42 -0800 (PST)
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 ofgQZnMsTa02 for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 07:09:41 -0800 (PST)
Received: from mail-iw0-f195.google.com (mail-iw0-f195.google.com [209.85.223.195]) by core3.amsl.com (Postfix) with ESMTP id 673CE3A6817 for <fecframe@ietf.org>; Thu, 14 Jan 2010 07:09:41 -0800 (PST)
Received: by iwn33 with SMTP id 33so106790iwn.29 for <fecframe@ietf.org>; Thu, 14 Jan 2010 07:09:36 -0800 (PST)
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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YS3eoiNqXwrkfK/LfhKSpBoDHsKCA2UwSo6dFmjNJP8=; b=H/VNqW4+QQd4FJWZ5o3bKyIdYND2GLn73O7vkeS+/ff1UV1hO5niGFrmXYgd54ca3t 68lQugsIG6u/mgzlOsHdYlkLW9aQfRhmZ2eA9+CO+TABQpfA3BT55TTR3x3ZI4dTBj3n bwa97MI2hdivG7MSzTz45qQC/RQoj8/I4kq04=
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=hn3VrP7t4VnQ+Ikcvr1s0kPtDOvxPUCPlKZFgWfblCULUsCF3kyk+vAtZHdH7avk7h YDIboPPSzRyK0d27TSHp9GBkK6Ei+tyIMwrbeVVWX8DIguWOPnTO2vBORRRH3I9IjTAD yM6VT4FHw0zzXO0s9gTkOrULUSZcwjSfWLSoU=
MIME-Version: 1.0
Received: by 10.231.59.5 with SMTP id j5mr283433ibh.6.1263481775825; Thu, 14  Jan 2010 07:09:35 -0800 (PST)
In-Reply-To: <E7D8D1A37669BA428A72828A4DD999AD02146B5B@rvil-mail1.RADVISION.com>
References: <38c19b540912040749y72cb3be2wec6cd1aa13c1d46@mail.gmail.com> <4B4EEEC0.2020102@ericsson.com> <E7D8D1A37669BA428A72828A4DD999AD02146B5B@rvil-mail1.RADVISION.com>
Date: Thu, 14 Jan 2010 07:09:35 -0800
Message-ID: <38c19b541001140709le4751dsc30255664175f1ae@mail.gmail.com>
From: Greg Shepherd <gjshep@gmail.com>
To: Orly Peck <orlyp@radvision.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: fecframe@ietf.org
Subject: Re: [Fecframe] WG Last Call - Framework
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: gjshep@gmail.com
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 15:09:42 -0000

Thank you!

On Thu, Jan 14, 2010 at 2:30 AM, Orly Peck <orlyp@radvision.com> wrote:
> Hi,
> I will review the document early next week.
> Thanks,
> Orly Peck.
>
> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Beh=
alf Of Magnus Westerlund
> Sent: Thursday, January 14, 2010 12:15 PM
> To: fecframe@ietf.org
> Subject: Re: [Fecframe] WG Last Call - Framework
>
> WG,
>
> This is one of your core documents. I have seen ONE (1) single comment
> that someone has read the document. I do expect to see a bit more
> reviews on this before I can consider there be consensus for publication
> in the WG.
>
> Magnus Westerlund
>
> Greg Shepherd skrev 2009-12-04 16:49:
>> Yes, we called LC on this earlier but I received feedback that there
>> just wasn't enough time...
>>
>> So, let's keep the WG LC open with a comment due date pushed out to
>> Jan 8th to allow for the Holidays. I'll send weekly reminders to keep
>> everyone on task. Please read and respond so we can ship and shut. ;-)
>>
>> Thanks!,
>> Greg
>> _______________________________________________
>> Fecframe mailing list
>> Fecframe@ietf.org
>> https://www.ietf.org/mailman/listinfo/fecframe
>>
>
>
> --
>
> Magnus Westerlund
>
> IETF Transport Area Director
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
> _______________________________________________
> 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 Jan 14 07:11:06 2010
Return-Path: <abegen@cisco.com>
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 30F2D3A63EB for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 07:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 M+LXdrDQv2jj for <fecframe@core3.amsl.com>; Thu, 14 Jan 2010 07:11:00 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 780AA3A6782 for <fecframe@ietf.org>; Thu, 14 Jan 2010 07:11:00 -0800 (PST)
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: ApoEAGbCTkurR7Hu/2dsb2JhbADEAJR5AoQuBA
X-IronPort-AV: E=Sophos;i="4.49,275,1262563200"; d="scan'208";a="288294958"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 14 Jan 2010 15:10:58 +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 o0EFAv4g003247; Thu, 14 Jan 2010 15:10:57 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, 14 Jan 2010 07:10:57 -0800
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, 14 Jan 2010 07:10:59 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B06AFCE@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <38c19b541001140709le4751dsc30255664175f1ae@mail.gmail.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Fecframe] WG Last Call - Framework
Thread-Index: AcqVK5uIEG+Lt56uQzGmaGwNHSmnbwAACKYQ
References: <38c19b540912040749y72cb3be2wec6cd1aa13c1d46@mail.gmail.com><4B4EEEC0.2020102@ericsson.com><E7D8D1A37669BA428A72828A4DD999AD02146B5B@rvil-mail1.RADVISION.com> <38c19b541001140709le4751dsc30255664175f1ae@mail.gmail.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: <gjshep@gmail.com>, "Orly Peck" <orlyp@radvision.com>
X-OriginalArrivalTime: 14 Jan 2010 15:10:57.0828 (UTC) FILETIME=[C6676E40:01CA952B]
Cc: fecframe@ietf.org
Subject: Re: [Fecframe] WG Last Call - Framework
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jan 2010 15:11:06 -0000

Can we get an updated draft before the review?

-acbegen

> -----Original Message-----
> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On =
Behalf Of Greg
> Shepherd
> Sent: Thursday, January 14, 2010 7:10 AM
> To: Orly Peck
> Cc: fecframe@ietf.org
> Subject: Re: [Fecframe] WG Last Call - Framework
>=20
> Thank you!
>=20
> On Thu, Jan 14, 2010 at 2:30 AM, Orly Peck <orlyp@radvision.com> =
wrote:
> > Hi,
> > I will review the document early next week.
> > Thanks,
> > Orly Peck.
> >
> > -----Original Message-----
> > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] =
On Behalf Of Magnus
> Westerlund
> > Sent: Thursday, January 14, 2010 12:15 PM
> > To: fecframe@ietf.org
> > Subject: Re: [Fecframe] WG Last Call - Framework
> >
> > WG,
> >
> > This is one of your core documents. I have seen ONE (1) single =
comment
> > that someone has read the document. I do expect to see a bit more
> > reviews on this before I can consider there be consensus for =
publication
> > in the WG.
> >
> > Magnus Westerlund
> >
> > Greg Shepherd skrev 2009-12-04 16:49:
> >> Yes, we called LC on this earlier but I received feedback that =
there
> >> just wasn't enough time...
> >>
> >> So, let's keep the WG LC open with a comment due date pushed out to
> >> Jan 8th to allow for the Holidays. I'll send weekly reminders to =
keep
> >> everyone on task. Please read and respond so we can ship and shut. =
;-)
> >>
> >> Thanks!,
> >> Greg
> >> _______________________________________________
> >> Fecframe mailing list
> >> Fecframe@ietf.org
> >> https://www.ietf.org/mailman/listinfo/fecframe
> >>
> >
> >
> > --
> >
> > Magnus Westerlund
> >
> > IETF Transport Area Director
> > =
----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > =
----------------------------------------------------------------------
> > Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> > F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 =
0949079
> > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> > =
----------------------------------------------------------------------
> > _______________________________________________
> > 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

From wwwrun@core3.amsl.com  Fri Jan 15 06:57:06 2010
Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: fecframe@ietf.org
Delivered-To: fecframe@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 994073A6A5D; Fri, 15 Jan 2010 06:57:06 -0800 (PST)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20100115145706.994073A6A5D@core3.amsl.com>
Date: Fri, 15 Jan 2010 06:57:06 -0800 (PST)
Cc: fecframe chair <fecframe-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, fecframe mailing list <fecframe@ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [Fecframe] Protocol Action: 'RTP Payload Format for 1-D Interleaved Parity FEC' to Proposed Standard
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2010 14:57:06 -0000

The IESG has approved the following document:

- 'RTP Payload Format for 1-D Interleaved Parity FEC '
   <draft-ietf-fecframe-interleaved-fec-scheme-09.txt> as a Proposed Standard


This document is the product of the FEC Framework Working Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-scheme-09.txt

Technical Summary

This document defines a new RTP payload format for the Forward Error
Correction that is generated by the 1-D interleaved parity code from a
source media encapsulated in RTP. The 1-D interleaved parity code is a
systematic code, where a number of repair symbols are generated from a
set of source symbols and sent in a repair flow separate from the
source flow that carries the source symbols. The new payload format
defined in this document is used (with some exceptions) as part of the
DVB Application-layer FEC specification.

Working Group Summary

There were no seriously contentious issues during the WG process. The
only controversy stemmed from some individuals who did the work in
SMPTE and didn't want the IETF redefining their work. But the problem
is that RFC 2733 did not protect some fields in the header and SMPTE
was based on RFC 2733. SMTPE spec also made mistakes with SSRC, CSRC
and timestamps which are corrected in this document. Additionally, RTP
validity checks fail in RPF 2733/SMTPE specs.

Document Quality

Current implementations follow SMTPE and not yet this specification.

Personal

Document Shepherd - Greg Shepherd
Responsible Area Director - Magnus Westerlund


From orlyp@radvision.com  Tue Jan 19 23:28:49 2010
Return-Path: <orlyp@radvision.com>
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 8975C3A68BB for <fecframe@core3.amsl.com>; Tue, 19 Jan 2010 23:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=0.6]
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 EXg9ObyZuM08 for <fecframe@core3.amsl.com>; Tue, 19 Jan 2010 23:28:48 -0800 (PST)
Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 2759A3A68A4 for <fecframe@ietf.org>; Tue, 19 Jan 2010 23:28:47 -0800 (PST)
Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o0K7SjU3026130 for fecframe@ietf.org; Wed, 20 Jan 2010 09:28:45 +0200
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 o0K7Sjam026124 for <fecframe@ietf.org>; Wed, 20 Jan 2010 09:28:45 +0200
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"
Date: Wed, 20 Jan 2010 09:28:38 +0200
Message-ID: <E7D8D1A37669BA428A72828A4DD999AD021470DA@rvil-mail1.RADVISION.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RE: [Fecframe] WG Last Call - Framework
Thread-Index: AcqVAqd/2L4jLOg1RtG5zhVkN8FMUQAAdv2QAPY3XdAAL6hOkAABUE1g
From: "Orly Peck" <orlyp@radvision.com>
To: <fecframe@ietf.org>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by eframer.radvision.com id o0K7Sjam026124
Subject: Re: [Fecframe] WG Last Call - Framework
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Jan 2010 07:28:49 -0000

Hi,
Following are my comments for draft-ietf-fecframe-framework-05:

1) On page 11, last sentence: "a repair packet carried over RTP starts with an RTP header of its own which is immediately followed by parity data..." - what about a FEC header that follows the RTP header?

2) on page 14 - "a CDP specification MUST define how a receiver determines the length of time it should wait to receive FEC repair packets for any given source blocks". 
Sometimes only the receiver knows how much time it can wait for a FEC repair packet due to latency considerations or any other consideration the receiving application may take into account. IMHO the sender can define a MINIMUM time that the sender should wait for the repair packet.

3) typo - on page 22 section 6.2 - "For each sApplication Data Units..." - remove "s".

4) same paragraph -  I think that the FEC scheme should (optionally) receive the information of the index of the ADU in the source block (this is important for FEC codes where order is significant).

5) page 23 - IMHO it should be mentioned that using the Explicit Source FEC Payload ID is not backward compatible with non-FEC support receivers, and therefore is a disadvantage. I think it should be recommended that if there is a way to avoid using the Explicit Source FEC Payload ID appended to the end of the source packet, then it should be avoided.

6) typo - page 24, section 6.3.1, second paragraph - "construction source packets within a gioven source block...." - gioven=given.

7) typo - same paragraph - "values in the sequence nmber space..." nmber=number.

8) page 25, section 6.5, third paragraph - "...provides FEC protection for all packets of the specified set of Source Data Flows..." - I am not sure I understand this sentence. Sometimes not all packets of a source flow are protected (e.g. using mask). 


Thanks,
Orly Peck.



-----Original Message-----
From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Orly Peck
Sent: Thursday, January 14, 2010 12:31 PM
To: Magnus Westerlund; fecframe@ietf.org
Subject: Re: [Fecframe] WG Last Call - Framework

Hi, 
I will review the document early next week.
Thanks,
Orly Peck.

-----Original Message-----
From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Behalf Of Magnus Westerlund
Sent: Thursday, January 14, 2010 12:15 PM
To: fecframe@ietf.org
Subject: Re: [Fecframe] WG Last Call - Framework

WG,

This is one of your core documents. I have seen ONE (1) single comment
that someone has read the document. I do expect to see a bit more
reviews on this before I can consider there be consensus for publication
in the WG.

Magnus Westerlund

Greg Shepherd skrev 2009-12-04 16:49:
> Yes, we called LC on this earlier but I received feedback that there
> just wasn't enough time...
> 
> So, let's keep the WG LC open with a comment due date pushed out to
> Jan 8th to allow for the Holidays. I'll send weekly reminders to keep
> everyone on task. Please read and respond so we can ship and shut. ;-)
> 
> Thanks!,
> Greg
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe
> 


-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------
_______________________________________________
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 Jan 28 12:55:52 2010
Return-Path: <abegen@cisco.com>
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 6785328C0FD; Thu, 28 Jan 2010 12:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.299
X-Spam-Level: 
X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 bFogpR5pT-XY; Thu, 28 Jan 2010 12:55:51 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8F1363A682E; Thu, 28 Jan 2010 12:55:51 -0800 (PST)
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: ApoEACeJYUurRN+J/2dsb2JhbADBXpdWhD0E
X-IronPort-AV: E=Sophos;i="4.49,363,1262563200"; d="scan'208";a="80528876"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 28 Jan 2010 20:56:11 +0000
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o0SKuBHR016520; Thu, 28 Jan 2010 20:56:11 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, 28 Jan 2010 12:56:11 -0800
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"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 28 Jan 2010 12:55:55 -0800
Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B23D8C5@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <846E11BB-CAB7-43DD-A532-246926CBEA9B@nostrum.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05)
Thread-Index: AcqgVw/0uFsBazxPS16NNa8b6TaLzQAAVdOg
References: <ECAE620F-C2A8-4D87-ADB8-30B6986A694D@nostrum.com> <27887E65-F19F-405C-B1ED-E04FB41452C5@nostrum.com> <04CAD96D4C5A3D48B1919248A8FE0D540B23D7FE@xmb-sjc-215.amer.cisco.com> <846E11BB-CAB7-43DD-A532-246926CBEA9B@nostrum.com>
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: "Robert Sparks" <rjsparks@nostrum.com>
X-OriginalArrivalTime: 28 Jan 2010 20:56:11.0037 (UTC) FILETIME=[5238CCD0:01CAA05C]
Cc: mmusic@ietf.org, fecframe@ietf.org
Subject: Re: [Fecframe] [MMUSIC] draft-ietf-mmusic-rfc4756bis (was Re: AD Review:draft-ietf-mmusic-rfc4765bis-05)
X-BeenThere: fecframe@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of FEC Framework <fecframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/fecframe>
List-Post: <mailto:fecframe@ietf.org>
List-Help: <mailto:fecframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fecframe>, <mailto:fecframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jan 2010 20:55:52 -0000

> Section 4.4 of this document says they SHOULD try to make the FEC
semantics
> work when a FEC-XR offer fails. This document does not say what the
FEC
> semantics are. Where in the new document do you tell an implementer
what
>        a=3Dgroup:FEC 1 2
>        a=3Dgroup:FEC 3 4
> means?

OK, right. "FEC" semantics are not defined in the new draft. If a new
implementation wants to be able to speak to 4756 endpoints, it will need
4756. Then I guess you are disagreeing that we are obsoleting 4756.

Well, I am not sure what is the right term here. At that time, I was
told "obsoleting" was the right choice. To me, RFC 4756 will still be
available for anybody who wants to be backward compatible anyway. So, I
did not think it would be a problem. But, if you say it is a problem, I
can't argue with that.

...
> 	I believe it is clear since we are obsoleting 4756. An obsoleted
spec
> 	should not be implemented anyway.
>=20
>=20
>=20
> Obsolete in the header refers to the document, not the technology
> in the document. It means the normative behavior that used to be
> defined by this document is now defined somewhere else. That
> somewhere else has to be very explicit about what's changed.
> If the intent is to deprecate an old behavior, you need to say that.
> It is not explicit in this document that you don't want new things
> sending offers with group:FEC without them having tried group:FEC-XR
> first.

We can remove the part saying that new implementations will need to try
FEC semantics before giving up (if the FEC semantics still give them
what they want). This is the part that still requires reading RFC 4756.
If an implementation does not desire to be backward compatible (meaning
it only speaks FEC-XR language), then it does not need 4756.

...
> I don't feel strongly about changing the name, especially if there are
> implementations (how many are there by the way?).

I don't think there are many as this stuff is mostly needed by the FEC
framework which is still in the wg last call process.=20

Any objections to FEC-FR? (CC'ing fecframe as well)
=20
...
>=20
> Looking back through the document, I spotted a minor note I made but
failed
> to transcribe earlier.
>=20
> In section 4.4's third paragraph, there is a SHOULD that is
impossible.
> As written, you are placing a requirement on implementations that do
> not implement this spec. I think you are trying to say that
implementations

I see your point. However, is not this what they are supposed to do
anyway based on 3388bis or SDP specs? If one does not understand the
grouping semantics or line grouping, they answer by ignoring the
grouping attribute (or with a refusal to the request).=20

> following the already published specifications will behave in one of
the
> two following ways and then providing normative behavior for how the
> offerer will react to either of those two cases.

Yes, this was the intent. And this kind of language is mostly based on
4756. I can remove "SHOULD" or refer to 3388bis to indicate that it is
not this draft who is making the rules for the answerers.=20

-acbegen