
From nobody Thu Dec  6 03:03:43 2018
Return-Path: <roni.even@huawei.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA62F130DE9 for <payload@ietfa.amsl.com>; Thu,  6 Dec 2018 03:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egVcisoQWirx for <payload@ietfa.amsl.com>; Thu,  6 Dec 2018 03:03:37 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB00126F72 for <payload@ietf.org>; Thu,  6 Dec 2018 03:03:37 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7E0A55EACD02C; Thu,  6 Dec 2018 11:03:33 +0000 (GMT)
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Dec 2018 11:03:35 +0000
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.140]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Thu, 6 Dec 2018 19:03:29 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, Giridhar Mandyam <mandyam@qti.qualcomm.com>
CC: "Ali C. Begen" <ali.begen@networked.media>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Ben Campbell <ben@nostrum.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-10.txt
Thread-Index: AQHUdKHUsCqCGfwu2UO8myfbHJx9L6Vxu7iA
Date: Thu, 6 Dec 2018 11:03:29 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18C85C10@dggemm526-mbx.china.huawei.com>
References: <154137912756.31875.5347836180455863963@ietfa.amsl.com> <A6E85ACB-7039-45B4-8854-0B9161093CB0@nostrum.com> <9C1381B7-A4A0-48FB-A811-FCD8EFA54BAF@networked.media> <e5732f8e-4714-1c14-4d8d-ea58fbc07b3d@nostrum.com> <CAA4MczsFdDHE-LSco9t+bV3Zie3iz1j1Ct=570XmTpT6RbpD9A@mail.gmail.com> <3CAF95D1-2D49-4EA2-9939-B0E4EC9D8C3B@nostrum.com> <8bd36e09cfe845758d52cc0b2aeb166f@NASANEXM01C.na.qualcomm.com> <CAA4Mczt8DwdZWn4AG3XUprxZGCgfjbH+tJ6ToFZDfCGAK9kpHg@mail.gmail.com> <62166FDE-60E2-4C39-97EB-2CE9A21FC9BD@nostrum.com> <DA7E59C1-ED41-4901-810B-0C83B6F197D6@networked.media> <D8A33513-5AD6-4782-919E-B9B166E30498@nostrum.com> <1d9e52a0143b4959b6ae3645846fe7a8@NASANEXM01C.na.qualcomm.com> <9816C546-A722-49CC-8DE2-1055631771A9@nostrum.com> <AM6PR07MB498223FF49ADC9F1B2ED82B095A90@AM6PR07MB4982.eurprd07.prod.outlook.com>
In-Reply-To: <AM6PR07MB498223FF49ADC9F1B2ED82B095A90@AM6PR07MB4982.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.135]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/5bGfFEnNt8EIdh1N0PqCYxFEUKs>
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-10.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 11:03:42 -0000

Hi,
Can you send these messages to the list.
I am wondering about ToP, I saw a previous question from Magnus about using=
 for example ToP 0,3 (FEC plus retransmission) not allowed by current defin=
ition in 5.1.1 but if I read section 4.2.2.3 first paragraph correctly it i=
s allowed
I also assume that Magnus asked for the default value for ToP and I did not=
 see any text in 5.1.1
Roni Even=20


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: Thursday, December 06, 2018 10:32 AM
To: Ben Campbell
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; Giridhar Man=
dyam
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,

I have responded on the first question. Although I don't understand why tha=
t went off-list.

I want to comment on the second paragraph below.

On 2018-12-05 19:36, Ben Campbell wrote:
>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com>=
 wrote:
>>
>> I believe his first comment on ToP needs to be addressed in the revision=
.  I believe his second comment is more problematic, because it refers to a=
 standards-track document that has not achieved RFC status yet (i.e. it may=
 undergo changes), and I am not sure it will help the document.
>>
>>
Considering that draft-ietf-avtext-rid is approved and stuck in RFC-editor =
missref state on cluster 238 I don't see this as a reason for not addressin=
g my raised issue.

The reason I do want to raise this is that flexfec could be used in a sub-s=
et of cases, but is not necessary in any cases as the linking to the source=
 flow is provided in the FLEXFEC RTP packet. Thus, for making it clear that=
 it is not needed, I think an explicit statement should be added to that ef=
fect. If we don't have a statement we might find situations where people wi=
ll attempt to apply it and gets into the confusion if they try the FEC mode=
 with multiple source SSRCs where it doesn't work.

Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Thu Dec  6 13:03:25 2018
Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8A0131197 for <payload@ietfa.amsl.com>; Thu,  6 Dec 2018 13:03:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjhyoiuibEf1 for <payload@ietfa.amsl.com>; Thu,  6 Dec 2018 13:03:14 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07DF130EDA for <payload@ietf.org>; Thu,  6 Dec 2018 13:03:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1544130194; x=1575666194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UDvc4mz0KkyCsLyIvV8ujwcrvCoaFQMAIHlfwYhspy0=; b=PA2qGnim2wFLN4sp5lf1n6+R2PNzo9HrAk3ejOs9xPG7ta16NgigYiqo mVXwN5k1bFg2Q4sae07ADWencft/JzXfT5OWL1ZbXePitcB58lGfFkXEd uSpPg667jgR2AAUhRq8gUNIQqQZejuTWk/CdWtl2cZfzBvcw7RB90kcLb 8=;
X-IronPort-AV: E=Sophos;i="5.56,323,1539673200"; d="scan'208";a="16642773"
Received: from unknown (HELO ironmsg05-sd.qualcomm.com) ([10.53.140.145]) by alexa-out-sd-01.qualcomm.com with ESMTP; 06 Dec 2018 13:03:14 -0800
Received: from nasanexm01c.na.qualcomm.com ([10.85.0.83]) by ironmsg05-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 06 Dec 2018 13:03:13 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01C.na.qualcomm.com (10.85.0.83) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 6 Dec 2018 13:03:13 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Thu, 6 Dec 2018 13:03:13 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "Ali C. Begen" <ali.begen@networked.media>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Ben Campbell <ben@nostrum.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
Thread-Index: AdSNorPPkyx2u/zORBuZfJA8MKesUwABEXtQ
Date: Thu, 6 Dec 2018 21:03:13 +0000
Message-ID: <c222823717894a13b7dd54a6620d9312@NASANEXM01C.na.qualcomm.com>
References: <113ed79cfaa347edb8b89a7ac5af3d69@NASANEXM01C.na.qualcomm.com>
In-Reply-To: <113ed79cfaa347edb8b89a7ac5af3d69@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/FGc2zUAPZZYlIz8tIizXCVcRao8>
Subject: Re: [payload] Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 21:03:24 -0000

Sorry - sent out too soon.

The last change should have read:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a f=
ormat that can be used to identify a single RTP source stream along with an=
 associated repair stream.  However, this specification already defines a m=
ethod of source and repair stream identification that can enable protection=
 of multiple source streams with a single repair stream.  Therefore the RTP=
 Stream Idenfifer Source Description SHOULD NOT be used for the Flexible FE=
C payload format."

-----Original Message-----
From: Giridhar Mandyam=20
Sent: Thursday, December 6, 2018 12:59 PM
To: 'Roni Even (A)' <roni.even@huawei.com>; Magnus Westerlund <magnus.weste=
rlund@ericsson.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11

Magnus,
Here is the proposal to respond to your comments in https://mailarchive.iet=
f.org/arch/msg/payload/MkHU_bBWl_Dp1jRhlvnFpZB1ewI.

Thanks,
-Giri Mandyam

A. > At least in discussing this with Mo F2F I got the impression that the =
plan was to also be explicit about what the lack of it (ToP) means, i.e. it=
 can be any of the self describing usages, so a mix of retransmission and F=
EC is possible.

Proposed change:  The following sentence will be added to each ToP section:=
  " The absence of the ToP field means that all protection types are allowe=
d."

B. >The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at all  nee=
ded, even if it could be used in a sub-set of applications of  flexfec. It =
would work in same RTP Session, with a single repair RTP stream only protec=
ts a singe source RTP stream. But, considering the possibility of repair of=
 multiple source streams and different RTP Sessions, I think an explicit st=
atement that this SHOULD NOT be used for the payload format would be good t=
o include.

Proposed Change #1:  Add a reference to https://tools.ietf.org/html/draft-i=
etf-avtext-rid-09 in the Informative References section.

Proposed Change #2:  Add Section 7.2, entitled "On the Use of the RTP Strea=
m Identifier Source Description", with the following text:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a f=
ormat that can be used to identify a single RTP source stream along with an=
 associated repair stream.  However, since this specification already defin=
es a method of source and repair stream identification that can enable prot=
ection of Multiple source streams with a single repair stream.  Therefore t=
he RTP Stream Idenfifer Source Description SHOULD NOT be used for the Flexi=
ble FEC payload format."=20

-----Original Message-----
From: Roni Even (A) <roni.even@huawei.com>
Sent: Thursday, December 6, 2018 3:03 AM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>; Giridhar Mandyam <m=
andyam@qti.qualcomm.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: RE: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,
Can you send these messages to the list.
I am wondering about ToP, I saw a previous question from Magnus about using=
 for example ToP 0,3 (FEC plus retransmission) not allowed by current defin=
ition in 5.1.1 but if I read section 4.2.2.3 first paragraph correctly it i=
s allowed I also assume that Magnus asked for the default value for ToP and=
 I did not see any text in 5.1.1 Roni Even=20


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Thursday, December 06, 2018 10:32 AM
To: Ben Campbell
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; Giridhar Man=
dyam
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,

I have responded on the first question. Although I don't understand why tha=
t went off-list.

I want to comment on the second paragraph below.

On 2018-12-05 19:36, Ben Campbell wrote:
>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com>=
 wrote:
>>
>> I believe his first comment on ToP needs to be addressed in the revision=
.  I believe his second comment is more problematic, because it refers to a=
 standards-track document that has not achieved RFC status yet (i.e. it may=
 undergo changes), and I am not sure it will help the document.
>>
>>
Considering that draft-ietf-avtext-rid is approved and stuck in RFC-editor =
missref state on cluster 238 I don't see this as a reason for not addressin=
g my raised issue.

The reason I do want to raise this is that flexfec could be used in a sub-s=
et of cases, but is not necessary in any cases as the linking to the source=
 flow is provided in the FLEXFEC RTP packet. Thus, for making it clear that=
 it is not needed, I think an explicit statement should be added to that ef=
fect. If we don't have a statement we might find situations where people wi=
ll attempt to apply it and gets into the confusion if they try the FEC mode=
 with multiple source SSRCs where it doesn't work.

Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Thu Dec  6 13:35:47 2018
Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240551311D4 for <payload@ietfa.amsl.com>; Thu,  6 Dec 2018 13:35:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Upd08WSp5Q6s for <payload@ietfa.amsl.com>; Thu,  6 Dec 2018 13:35:43 -0800 (PST)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71938130E93 for <payload@ietf.org>; Thu,  6 Dec 2018 13:35:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1544132143; x=1575668143; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=HTqpjcG6QJGRnK75RdxAStVob//+B1dpYE0uqN6+a48=; b=dERPP5wXDW2RjmC6OsMbqV/BTX0ZYgQWGLQvkM9SxqQP1TquzCWYsvQX bGShNCExgyRckCohNt/EVi89rgTJD2WU3WRnZlBoTywuqP+dIlnafuHKP uv1/Q4y+YrEZ6+kSCkpoUjUiCw7T0KQ1Q6BI3Nn/NWRAC2TrsDQDmt6Pl s=;
X-URL-LookUp-ScanningError: 1
X-IronPort-AV: E=Sophos;i="5.56,323,1539673200"; d="scan'208";a="19624179"
Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-02.qualcomm.com with ESMTP; 06 Dec 2018 12:58:59 -0800
Received: from nasanexm01h.na.qualcomm.com ([10.85.0.34]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 06 Dec 2018 12:58:50 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01H.na.qualcomm.com (10.85.0.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 6 Dec 2018 12:58:50 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Thu, 6 Dec 2018 12:58:50 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "Ali C. Begen" <ali.begen@networked.media>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Ben Campbell <ben@nostrum.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
Thread-Index: AdSNorPPkyx2u/zORBuZfJA8MKesUw==
Date: Thu, 6 Dec 2018 20:58:49 +0000
Message-ID: <113ed79cfaa347edb8b89a7ac5af3d69@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/FMkx3wmN1DY7fCqur-S17V-DqW8>
Subject: [payload] Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 21:35:46 -0000

Magnus,
Here is the proposal to respond to your comments in https://mailarchive.iet=
f.org/arch/msg/payload/MkHU_bBWl_Dp1jRhlvnFpZB1ewI.

Thanks,
-Giri Mandyam

A. > At least in discussing this with Mo F2F I got the impression that the =
plan was to also be explicit about what the lack of it (ToP) means, i.e. it=
 can be any of the self describing usages, so a mix of retransmission and F=
EC is possible.

Proposed change:  The following sentence will be added to each ToP section:=
  " The absence of the ToP field means that all protection types are allowe=
d."

B. >The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at all  nee=
ded, even if it could be used in a sub-set of applications of  flexfec. It =
would work in same RTP Session, with a single repair RTP stream only protec=
ts a singe source RTP stream. But, considering the possibility of repair of=
 multiple source streams and different RTP Sessions, I think an explicit st=
atement that this SHOULD NOT be used for the payload format would be good t=
o include.

Proposed Change #1:  Add a reference to https://tools.ietf.org/html/draft-i=
etf-avtext-rid-09 in the Informative References section.

Proposed Change #2:  Add Section 7.2, entitled "On the Use of the RTP Strea=
m Identifier Source Description", with the following text:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a f=
ormat that can be used to identify a single RTP source stream along with an=
 associated repair stream.  However, since this specification already defin=
es a method of source and repair stream identification that can enable prot=
ection of=20
Multiple source streams with a single repair stream.  Therefore the RTP Str=
eam Idenfifer Source Description SHOULD NOT be used for the Flexible FEC pa=
yload format."=20

-----Original Message-----
From: Roni Even (A) <roni.even@huawei.com>=20
Sent: Thursday, December 6, 2018 3:03 AM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>; Giridhar Mandyam <m=
andyam@qti.qualcomm.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: RE: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,
Can you send these messages to the list.
I am wondering about ToP, I saw a previous question from Magnus about using=
 for example ToP 0,3 (FEC plus retransmission) not allowed by current defin=
ition in 5.1.1 but if I read section 4.2.2.3 first paragraph correctly it i=
s allowed I also assume that Magnus asked for the default value for ToP and=
 I did not see any text in 5.1.1 Roni Even=20


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Thursday, December 06, 2018 10:32 AM
To: Ben Campbell
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; Giridhar Man=
dyam
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,

I have responded on the first question. Although I don't understand why tha=
t went off-list.

I want to comment on the second paragraph below.

On 2018-12-05 19:36, Ben Campbell wrote:
>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com>=
 wrote:
>>
>> I believe his first comment on ToP needs to be addressed in the revision=
.  I believe his second comment is more problematic, because it refers to a=
 standards-track document that has not achieved RFC status yet (i.e. it may=
 undergo changes), and I am not sure it will help the document.
>>
>>
Considering that draft-ietf-avtext-rid is approved and stuck in RFC-editor =
missref state on cluster 238 I don't see this as a reason for not addressin=
g my raised issue.

The reason I do want to raise this is that flexfec could be used in a sub-s=
et of cases, but is not necessary in any cases as the linking to the source=
 flow is provided in the FLEXFEC RTP packet. Thus, for making it clear that=
 it is not needed, I think an explicit statement should be added to that ef=
fect. If we don't have a statement we might find situations where people wi=
ll attempt to apply it and gets into the confusion if they try the FEC mode=
 with multiple source SSRCs where it doesn't work.

Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Fri Dec  7 05:27:20 2018
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A743E12E043 for <payload@ietfa.amsl.com>; Fri,  7 Dec 2018 05:27:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.761
X-Spam-Level: 
X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZiUGIAOi; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jdoU7RGT
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeR-Gcxnb2-s for <payload@ietfa.amsl.com>; Fri,  7 Dec 2018 05:27:13 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3375212D84D for <payload@ietf.org>; Fri,  7 Dec 2018 05:27:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1544189231; x=1546781231; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RJFfl+ddansM9pizxVB9cJf16SaWMj6QQqgjWlhoWgA=; b=ZiUGIAOiLKqEaghaUCRgxDMJorBSddpoxOIqxHtc/iPZp3dddjK6ioKzmTURxi9m mJHzCrBVlslOUIYqyGpruOwA/YTGlmsglaSVMZq3ISI/Hj83DgWPgKqlEZTdwXR/ aK+EQIMIqzfTOq5aWU8nP1pJru9QwNjMKNyNTAv1t1c=;
X-AuditID: c1b4fb3a-477ff70000002747-01-5c0a752f8757
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 45.5C.10055.F257A0C5; Fri,  7 Dec 2018 14:27:11 +0100 (CET)
Received: from ESESBMR504.ericsson.se (153.88.183.139) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 7 Dec 2018 14:26:29 +0100
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR504.ericsson.se (153.88.183.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 7 Dec 2018 14:26:29 +0100
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 7 Dec 2018 14:26:28 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JeH5EvHUoYRipOLzbuQvUOP+M+phOQfrPphZRlhE1Q8=; b=jdoU7RGTdRdCgZiO9SWCq+lSMdVHfPD16oJdOG8WzaPMWzqILPrRJBbEQvwMpwqBQOZvudX+xVkoahXo13zpw6ib8H4uaUHNhB4yzkabRNDY8SMNFbMu7l5NZ7vhYviY/bUFCK5D5oNLwQVwChhljt+igBI6qVtCuLhv4zItttQ=
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com (20.178.19.28) by AM0PR07MB5698.eurprd07.prod.outlook.com (20.178.113.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.9; Fri, 7 Dec 2018 13:26:27 +0000
Received: from AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::d011:17bc:7193:9bca]) by AM0PR07MB4979.eurprd07.prod.outlook.com ([fe80::d011:17bc:7193:9bca%2]) with mapi id 15.20.1425.006; Fri, 7 Dec 2018 13:26:27 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>, "Roni Even (A)" <roni.even@huawei.com>
CC: "Ali C. Begen" <ali.begen@networked.media>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Ben Campbell <ben@nostrum.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
Thread-Index: AdSNorPPkyx2u/zORBuZfJA8MKesUw==
Date: Fri, 7 Dec 2018 13:26:27 +0000
Message-ID: <AM0PR07MB4979BC9A6166E17F735C96BF95AA0@AM0PR07MB4979.eurprd07.prod.outlook.com>
References: <113ed79cfaa347edb8b89a7ac5af3d69@NASANEXM01C.na.qualcomm.com> <c222823717894a13b7dd54a6620d9312@NASANEXM01C.na.qualcomm.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.93]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5698; 6:aI/RWRV7qdqV5pYSEuBt8QloWfX58z26CwGWWGkT0B7fNJJLrqCNq12KvQ935PHPvOO2qGsSjQOiAMr5HsAlzknQFxioOEmqCWd+Vfe/VjoyyFgm7IA2qssHjBa3RFP2z/YmiEhvmnsync7rr/u+MrHYAnRzZrX6LZFoH1zpqsrDdsQp6S3/swzHvwVnRYQDtcU5dOPrlVc9Gm6y8bDifuLVlVFpsAFQaKLPOOXz8/CRbw8G/biLhOfiWpmtbuAivIgGyM6TxFyGcKnmvTYq8Snv/PF780pgk48HbZZtDfmklNGjatksrvEYZMjhbB3heXZDNy2Nt+gs6XIADPRnXFzdyutEu9q68W4Jqn1mbP0NvwX32LVaXNnf36BfR2k2mxzj0eH0UzpH7O4zG9pkAx+PUYiaIGHWlOqwEpX5g4SZ+FJwD6/xf9RTkGhClY7MYtL1cgChg88zXZmyXOBDpg==; 5:T1e1/fAcJ1XFZuEbUo7G/xNe0JHOG95oKdqt99k+BNAyDvpwIAWqxloxDjcfyVc34U6WU5K/xHn32CjgnAbrEc1wLHpBv7fXQ6znobdZnCNTXg6DcU1hYUqNtllTHd5JhQJFudZCey9isk0YwEAQmsoPm7WCY1L0ymktJgLODKs=; 7:yPqbWtBlqsYJ7XPKLjq3TaxfIMgymVUIAXhI+ByoZpoqYCEMjxBo2PlgdIJu+xphmKQKczAXz6DYZ1aqRfhGiEDv33ggLPpk+AfW8b2lWE/fDZ1f/6Z1lwBozSkgYjCVYLzlDKJwYIkyxM5+g84SFw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 255c4132-1487-4623-17de-08d65c4797c5
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB5698; 
x-ms-traffictypediagnostic: AM0PR07MB5698:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-microsoft-antispam-prvs: <AM0PR07MB5698CD551EFC5F3ADFE77DE795AA0@AM0PR07MB5698.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230011)(999002)(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231466)(944501520)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5698; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5698; 
x-forefront-prvs: 0879599414
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(376002)(396003)(346002)(136003)(13464003)(189003)(199004)(68736007)(25786009)(476003)(561944003)(66066001)(6436002)(55016002)(7696005)(53936002)(478600001)(76176011)(966005)(102836004)(486006)(446003)(44832011)(33656002)(5660300001)(14454004)(305945005)(53546011)(6506007)(74316002)(186003)(26005)(2906002)(7736002)(106356001)(105586002)(316002)(6246003)(71190400001)(97736004)(81166006)(229853002)(71200400001)(8676002)(8936002)(256004)(6116002)(110136005)(6306002)(81156014)(54906003)(86362001)(9686003)(3846002)(99286004)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5698; H:AM0PR07MB4979.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: kWwZ0QH56BrBs8uqBWMgrqGoqLouw3xQoI5g/TiM/UfGk8VVJmLMkn884RvT4bm7MZNq76+8w3KJdlofDto0dUguQzuePJLnGRU85lbD/1JvRdtSVRKCKVd1A5B/QceME+kQvX3IGHLeQEaS0m645aBSg9123YGVA2bG+kf8SbtBNAemeCV6ssdhAeG6bvOTjotVFUgIUHRGlZpDwgg3JFUSGOMwazh3Rm+WYSrPQOSCguk9HSnMUz4svHH1TGBt6ivwTT3WeRgFVrPaSkMNH4/Z3X9Lg9DuTPgt9HORRlWxGFZqaOOu0R6+G+kqRMWhXANprPuqs46vh5947SclVhSopZW8M5bCs54IK13lSgI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 255c4132-1487-4623-17de-08d65c4797c5
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2018 13:26:27.7588 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5698
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHed7bXkeLp5V6sIwY0YfyUqK5rOzyIYZhCFGUjHLkm4rblL0q an1QMaip2apJWqbpGiZSdrG8RpNWDDFvaeqHzPs0RB15y25u74q+/c5z/v/zPwcelpQ+oX3Y BG0Kp9Oq1DJGTBWfeZXuH5gqVu62jOyQWxbtpLzsWptIPrs8gOT2L/cIeXdXOyF3vOugDjOK 26tPaUXu2xlaYTKtEIpGc6dIUdIwRikqjBMoiokWH4jl1AlpnC4wPEYcP/lpVpTcG5J+9Upo Fqry0yMPFnAw9Jt7CT0Ss1L8FkHzso0WigUE07mV6F/xY2rWLaskYOXxdVeHwjdI0I82uj0G AhzzVaRQDK9Na9KLnDEMlsPAcjbj5E34LEx9e804RSQ2IXhUZ3U1NuIIqLcbRILoONS3OCiB A+Bd4WPayRTeDuM1OWvZLCvBSpizBQpheQjaJu67vAj7wtDSZ5eXxN4wOFZGCLdiMDV3kAJ7 wtToL9o5B/A2GBqIFp59obssz3Ua4D4GPozY3F5/mDMa3d5IuPN9hha4E0HOgk7gnXCrbpoW dlBBf/a425sIdwffuPVbobpgmBIC+klob9ATN9Dukv92FdgPypscjMC7wPzgK+lkCd4AtuIx qhxR1ciT53heExcUFMDpEi7wfJI2QMulPENr38jyYjWsHlkmj7QizCLZOkmSRqyU0qo0PkPT ioAlZZskMvXakyRWlZHJ6ZLO61LVHN+KNrOUzFty9KI8WorjVClcIsclc7q/XYL18MlCyvdW c35tg/X3rDRQlr/+OZARfqHzJ39tqzAXFvXQe4MP3rRe8gh53VIQ2xUfvprzsjZsPdRm9paX GsK7mkNqpXVjDis6Z/A63zeSuqXqTXiU5z7GGONriDv18LsjYklZE/pz4XQPddl+yGt4rhTf erS/KLLiY0auSHNs0cd4Qkbx8ao9O0kdr/oD4YGDl0IDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/4vBQoXKUwbabgLc2X6DIF8BaKLs>
Subject: Re: [payload] Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 13:27:19 -0000

Hi,=0A=
=0A=
Looks good to me.=0A=
=0A=
Cheers=0A=
=0A=
Magnus=0A=
=0A=
On 2018-12-06 22:03, Giridhar Mandyam wrote:=0A=
> Sorry - sent out too soon.=0A=
>=0A=
> The last change should have read:=0A=
>=0A=
> "The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a=
 format that can be used to identify a single RTP source stream along with =
an associated repair stream.  However, this specification already defines a=
 method of source and repair stream identification that can enable protecti=
on of multiple source streams with a single repair stream.  Therefore the R=
TP Stream Idenfifer Source Description SHOULD NOT be used for the Flexible =
FEC payload format."=0A=
>=0A=
> -----Original Message-----=0A=
> From: Giridhar Mandyam =0A=
> Sent: Thursday, December 6, 2018 12:59 PM=0A=
> To: 'Roni Even (A)' <roni.even@huawei.com>; Magnus Westerlund <magnus.wes=
terlund@ericsson.com>=0A=
> Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanat=
y@cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org=0A=
> Subject: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11=0A=
>=0A=
> Magnus,=0A=
> Here is the proposal to respond to your comments in https://mailarchive.i=
etf.org/arch/msg/payload/MkHU_bBWl_Dp1jRhlvnFpZB1ewI.=0A=
>=0A=
> Thanks,=0A=
> -Giri Mandyam=0A=
>=0A=
> A. > At least in discussing this with Mo F2F I got the impression that th=
e plan was to also be explicit about what the lack of it (ToP) means, i.e. =
it can be any of the self describing usages, so a mix of retransmission and=
 FEC is possible.=0A=
>=0A=
> Proposed change:  The following sentence will be added to each ToP sectio=
n:  " The absence of the ToP field means that all protection types are allo=
wed."=0A=
>=0A=
> B. >The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at all  n=
eeded, even if it could be used in a sub-set of applications of  flexfec. I=
t would work in same RTP Session, with a single repair RTP stream only prot=
ects a singe source RTP stream. But, considering the possibility of repair =
of multiple source streams and different RTP Sessions, I think an explicit =
statement that this SHOULD NOT be used for the payload format would be good=
 to include.=0A=
>=0A=
> Proposed Change #1:  Add a reference to https://tools.ietf.org/html/draft=
-ietf-avtext-rid-09 in the Informative References section.=0A=
>=0A=
> Proposed Change #2:  Add Section 7.2, entitled "On the Use of the RTP Str=
eam Identifier Source Description", with the following text:=0A=
>=0A=
> "The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a=
 format that can be used to identify a single RTP source stream along with =
an associated repair stream.  However, since this specification already def=
ines a method of source and repair stream identification that can enable pr=
otection of Multiple source streams with a single repair stream.  Therefore=
 the RTP Stream Idenfifer Source Description SHOULD NOT be used for the Fle=
xible FEC payload format." =0A=
>=0A=
> -----Original Message-----=0A=
> From: Roni Even (A) <roni.even@huawei.com>=0A=
> Sent: Thursday, December 6, 2018 3:03 AM=0A=
> To: Magnus Westerlund <magnus.westerlund@ericsson.com>; Giridhar Mandyam =
<mandyam@qti.qualcomm.com>=0A=
> Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanat=
y@cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org=0A=
> Subject: RE: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme=
-10.txt=0A=
>=0A=
> Hi,=0A=
> Can you send these messages to the list.=0A=
> I am wondering about ToP, I saw a previous question from Magnus about usi=
ng for example ToP 0,3 (FEC plus retransmission) not allowed by current def=
inition in 5.1.1 but if I read section 4.2.2.3 first paragraph correctly it=
 is allowed I also assume that Magnus asked for the default value for ToP a=
nd I did not see any text in 5.1.1 Roni Even =0A=
>=0A=
>=0A=
> -----Original Message-----=0A=
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=0A=
> Sent: Thursday, December 06, 2018 10:32 AM=0A=
> To: Ben Campbell=0A=
> Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; Giridhar M=
andyam=0A=
> Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme=
-10.txt=0A=
>=0A=
> Hi,=0A=
>=0A=
> I have responded on the first question. Although I don't understand why t=
hat went off-list.=0A=
>=0A=
> I want to comment on the second paragraph below.=0A=
>=0A=
> On 2018-12-05 19:36, Ben Campbell wrote:=0A=
>>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com=
> wrote:=0A=
>>>=0A=
>>> I believe his first comment on ToP needs to be addressed in the revisio=
n.  I believe his second comment is more problematic, because it refers to =
a standards-track document that has not achieved RFC status yet (i.e. it ma=
y undergo changes), and I am not sure it will help the document.=0A=
>>>=0A=
>>>=0A=
> Considering that draft-ietf-avtext-rid is approved and stuck in RFC-edito=
r missref state on cluster 238 I don't see this as a reason for not address=
ing my raised issue.=0A=
>=0A=
> The reason I do want to raise this is that flexfec could be used in a sub=
-set of cases, but is not necessary in any cases as the linking to the sour=
ce flow is provided in the FLEXFEC RTP packet. Thus, for making it clear th=
at it is not needed, I think an explicit statement should be added to that =
effect. If we don't have a statement we might find situations where people =
will attempt to apply it and gets into the confusion if they try the FEC mo=
de with multiple source SSRCs where it doesn't work.=0A=
>=0A=
> Cheers =0A=
>=0A=
> Magnus Westerlund =0A=
>=0A=
> ----------------------------------------------------------------------=0A=
> Network Architecture & Protocols, Ericsson Research=0A=
> ----------------------------------------------------------------------=0A=
> Ericsson AB                 | Phone  +46 10 7148287=0A=
> Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
> ----------------------------------------------------------------------=0A=
>=0A=
>=0A=
=0A=
-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Fri Dec  7 10:39:23 2018
Return-Path: <ben@nostrum.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA33130FA8 for <payload@ietfa.amsl.com>; Fri,  7 Dec 2018 10:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level: 
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_DHg1DmAMjr for <payload@ietfa.amsl.com>; Fri,  7 Dec 2018 10:39:20 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735C5130FA6 for <payload@ietf.org>; Fri,  7 Dec 2018 10:39:17 -0800 (PST)
Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wB7IcxiS012515 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 7 Dec 2018 12:39:01 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1544207942; bh=jR8w+VLjrcKPnfENtqouh1vnwldG8CpVA8aA8yaLU/Q=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=gryVINVJ4BjlNVeiNTgg2/hUgjLmGAmHk1S3QBod3QEyJlBASwFDL7+kX0tui0ZeT IRjO9qtmdBgyG8V9L5MgVNjZyB5T5TeTa6SMMqi1gOca/rmZVIVcDQhU0zEJUgJzZL NRkmqAmPenWMt0g+i01ENMzepHmHenekZjD7b9wQ=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <39E260D1-2B02-4684-9624-150CBD0B6456@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1C931877-2BD4-4E8A-A697-0D63BB194BE7"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Fri, 7 Dec 2018 12:38:58 -0600
In-Reply-To: <AM0PR07MB4979BC9A6166E17F735C96BF95AA0@AM0PR07MB4979.eurprd07.prod.outlook.com>
Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com>, "Roni Even (A)" <roni.even@huawei.com>, "Ali C. Begen" <ali.begen@networked.media>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, "payload@ietf.org" <payload@ietf.org>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <113ed79cfaa347edb8b89a7ac5af3d69@NASANEXM01C.na.qualcomm.com> <c222823717894a13b7dd54a6620d9312@NASANEXM01C.na.qualcomm.com> <AM0PR07MB4979BC9A6166E17F735C96BF95AA0@AM0PR07MB4979.eurprd07.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/Ajxjgg39tqgy0yBHdnyk-pzQm4Y>
Subject: Re: [payload] Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 18:39:22 -0000

--Apple-Mail=_1C931877-2BD4-4E8A-A697-0D63BB194BE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Does this resolve the discussion?

Thanks!

Ben (who apologies for not having caught up on the thread yet.)


> On Dec 7, 2018, at 7:26 AM, Magnus Westerlund =
<magnus.westerlund@ericsson.com> wrote:
>=20
> Hi,
>=20
> Looks good to me.
>=20
> Cheers
>=20
> Magnus
>=20
> On 2018-12-06 22:03, Giridhar Mandyam wrote:
>> Sorry - sent out too soon.
>>=20
>> The last change should have read:
>>=20
>> "The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] =
is a format that can be used to identify a single RTP source stream =
along with an associated repair stream.  However, this specification =
already defines a method of source and repair stream identification that =
can enable protection of multiple source streams with a single repair =
stream.  Therefore the RTP Stream Idenfifer Source Description SHOULD =
NOT be used for the Flexible FEC payload format."
>>=20
>> -----Original Message-----
>> From: Giridhar Mandyam
>> Sent: Thursday, December 6, 2018 12:59 PM
>> To: 'Roni Even (A)' <roni.even@huawei.com>; Magnus Westerlund =
<magnus.westerlund@ericsson.com>
>> Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) =
<mzanaty@cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
>> Subject: Proposed changes to =
draft-ietf-payload-flexible-fec-scheme-11
>>=20
>> Magnus,
>> Here is the proposal to respond to your comments in =
https://mailarchive.ietf.org/arch/msg/payload/MkHU_bBWl_Dp1jRhlvnFpZB1ewI.=

>>=20
>> Thanks,
>> -Giri Mandyam
>>=20
>> A. > At least in discussing this with Mo F2F I got the impression =
that the plan was to also be explicit about what the lack of it (ToP) =
means, i.e. it can be any of the self describing usages, so a mix of =
retransmission and FEC is possible.
>>=20
>> Proposed change:  The following sentence will be added to each ToP =
section:  " The absence of the ToP field means that all protection types =
are allowed."
>>=20
>> B. >The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at =
all  needed, even if it could be used in a sub-set of applications of  =
flexfec. It would work in same RTP Session, with a single repair RTP =
stream only protects a singe source RTP stream. But, considering the =
possibility of repair of multiple source streams and different RTP =
Sessions, I think an explicit statement that this SHOULD NOT be used for =
the payload format would be good to include.
>>=20
>> Proposed Change #1:  Add a reference to =
https://tools.ietf.org/html/draft-ietf-avtext-rid-09 in the Informative =
References section.
>>=20
>> Proposed Change #2:  Add Section 7.2, entitled "On the Use of the RTP =
Stream Identifier Source Description", with the following text:
>>=20
>> "The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] =
is a format that can be used to identify a single RTP source stream =
along with an associated repair stream.  However, since this =
specification already defines a method of source and repair stream =
identification that can enable protection of Multiple source streams =
with a single repair stream.  Therefore the RTP Stream Idenfifer Source =
Description SHOULD NOT be used for the Flexible FEC payload format."
>>=20
>> -----Original Message-----
>> From: Roni Even (A) <roni.even@huawei.com>
>> Sent: Thursday, December 6, 2018 3:03 AM
>> To: Magnus Westerlund <magnus.westerlund@ericsson.com>; Giridhar =
Mandyam <mandyam@qti.qualcomm.com>
>> Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) =
<mzanaty@cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
>> Subject: RE: [payload] I-D Action: =
draft-ietf-payload-flexible-fec-scheme-10.txt
>>=20
>> Hi,
>> Can you send these messages to the list.
>> I am wondering about ToP, I saw a previous question from Magnus about =
using for example ToP 0,3 (FEC plus retransmission) not allowed by =
current definition in 5.1.1 but if I read section 4.2.2.3 first =
paragraph correctly it is allowed I also assume that Magnus asked for =
the default value for ToP and I did not see any text in 5.1.1 Roni Even
>>=20
>>=20
>> -----Original Message-----
>> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
>> Sent: Thursday, December 06, 2018 10:32 AM
>> To: Ben Campbell
>> Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; =
Giridhar Mandyam
>> Subject: Re: [payload] I-D Action: =
draft-ietf-payload-flexible-fec-scheme-10.txt
>>=20
>> Hi,
>>=20
>> I have responded on the first question. Although I don't understand =
why that went off-list.
>>=20
>> I want to comment on the second paragraph below.
>>=20
>> On 2018-12-05 19:36, Ben Campbell wrote:
>>>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam =
<mandyam@qti.qualcomm.com> wrote:
>>>>=20
>>>> I believe his first comment on ToP needs to be addressed in the =
revision.  I believe his second comment is more problematic, because it =
refers to a standards-track document that has not achieved RFC status =
yet (i.e. it may undergo changes), and I am not sure it will help the =
document.
>>>>=20
>>>>=20
>> Considering that draft-ietf-avtext-rid is approved and stuck in =
RFC-editor missref state on cluster 238 I don't see this as a reason for =
not addressing my raised issue.
>>=20
>> The reason I do want to raise this is that flexfec could be used in a =
sub-set of cases, but is not necessary in any cases as the linking to =
the source flow is provided in the FLEXFEC RTP packet. Thus, for making =
it clear that it is not needed, I think an explicit statement should be =
added to that effect. If we don't have a statement we might find =
situations where people will attempt to apply it and gets into the =
confusion if they try the FEC mode with multiple source SSRCs where it =
doesn't work.
>>=20
>> Cheers
>>=20
>> Magnus Westerlund
>>=20
>> =
----------------------------------------------------------------------
>> Network Architecture & Protocols, Ericsson Research
>> =
----------------------------------------------------------------------
>> Ericsson AB                 | Phone  +46 10 7148287
>> Torshamnsgatan 23           | Mobile +46 73 0949079
>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
>> =
----------------------------------------------------------------------
>>=20
>>=20
>=20
> --
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20


--Apple-Mail=_1C931877-2BD4-4E8A-A697-0D63BB194BE7
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwKvkIACgkQgFZKbJXz
1A3I4RAAq0dUzORx3SGuyvOHHUxIq/LXJAmPTi/QIP6pJ8ijHXUUk+DNi7HsKaMy
TtNJXkmTjDrNwBvaNG+QjVG1OxgnjV1YZcqXf/LLLZ7oQrIxLyrmySOe5QDE33T+
K4onwGMopjQl875YG9y+1Ww8Su4ARKnLwXxEKXTEiFg4JHAftzdIlhF43TlUOVie
SoLAF/NYSfpE+b5ibptw/rsOjwsbPBOee0TuAJDB1OQxfBMvvySTAD55Uu3DZrht
r17Whr/wrn/POSxCPhYbCPZXDGX+K6YAsh059pkOdLjn9P4apjbXKwEx+N0fVWBz
5Oj3DuKYTOY6EMqGCh1LCUYyYt1NdO7vFeHMWxkhAoAK0N5J+WV2/YjxIGsbC3F+
pogWAmWHQYrmOHgklU3RyPnLzJb+NKXYoSfGaThlU0S11fVDr6esH3H3UFGhaMvs
IBM0fwS5+JHUhuutfP7b57Ftw8sln5vD65859egM4LK/Fi3GOvvh4MM6xG5ugd4q
qdQCmZJFfuMVBVR3JRm3l3qf3jdbm2DX8M8xZjXCXaa5FNUWupKZcJYbIO0w756q
gd816d0cUyZ4g3Lot4uYQ3aaR+XIjoILJXBlsP0wEe6fW42RhvEoBeP8arm3dZq1
SX8cZyM+m8OHUtVQX/ZEwIcgXq9cBN3/m8JDGZM3e9GJfkkpy0Q=
=/9GV
-----END PGP SIGNATURE-----

--Apple-Mail=_1C931877-2BD4-4E8A-A697-0D63BB194BE7--


From nobody Fri Dec  7 15:32:32 2018
Return-Path: <internet-drafts@ietf.org>
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFE7130E1D; Fri,  7 Dec 2018 15:32:23 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: payload@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: payload@ietf.org
Message-ID: <154422554299.20231.1300848600231366801@ietfa.amsl.com>
Date: Fri, 07 Dec 2018 15:32:23 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/Mj5Z4_UrXRHJw5duYat81jXVH3k>
Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-12.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Dec 2018 23:32:23 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Payloads WG of the IETF.

        Title           : RTP Payload Format for Flexible Forward Error Correction (FEC)
        Authors         : Mo Zanaty
                          Varun Singh
                          Ali Begen
                          Giridhar Mandyam
	Filename        : draft-ietf-payload-flexible-fec-scheme-12.txt
	Pages           : 41
	Date            : 2018-12-07

Abstract:
   This document defines new RTP payload formats for the Forward Error
   Correction (FEC) packets that are generated by the non-interleaved
   and interleaved parity codes from source media encapsulated in RTP.
   These parity codes are systematic codes, where a number of FEC repair
   packets are generated from a set of source packets from one or more
   source RTP streams.  These FEC repair packets are sent in a
   redundancy RTP stream separate from the source RTP stream(s) that
   carries the source packets.  RTP source packets that were lost in
   transmission can be reconstructed using the source and repair packets
   that were received.  The non-interleaved and interleaved parity codes
   which are defined in this specification offer a good protection
   against random and bursty packet losses, respectively, at a cost of
   decent complexity.  The RTP payload formats that are defined in this
   document address the scalability issues experienced with the earlier
   specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and
   offer several improvements.  Due to these changes, the new payload
   formats are not backward compatible with the earlier specifications,
   but endpoints that do not implement this specification can still work
   by simply ignoring the FEC repair packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-12
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Dec 10 02:11:26 2018
Return-Path: <roni.even@huawei.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4400130F08 for <payload@ietfa.amsl.com>; Mon, 10 Dec 2018 02:11:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVpcn_-ug3gk for <payload@ietfa.amsl.com>; Mon, 10 Dec 2018 02:11:21 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F33130F00 for <payload@ietf.org>; Mon, 10 Dec 2018 02:11:21 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 18908FC55FEC0; Mon, 10 Dec 2018 10:11:17 +0000 (GMT)
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 10 Dec 2018 10:11:18 +0000
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 10 Dec 2018 10:11:18 +0000
Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 10 Dec 2018 10:11:17 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.124]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0415.000; Mon, 10 Dec 2018 18:11:12 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "Ali C. Begen" <ali.begen@networked.media>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Ben Campbell <ben@nostrum.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
Thread-Index: AdSNorPPkyx2u/zORBuZfJA8MKesUwABEXtQALJmQOA=
Date: Mon, 10 Dec 2018 10:11:12 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18C8F81D@DGGEMM506-MBX.china.huawei.com>
References: <113ed79cfaa347edb8b89a7ac5af3d69@NASANEXM01C.na.qualcomm.com> <c222823717894a13b7dd54a6620d9312@NASANEXM01C.na.qualcomm.com>
In-Reply-To: <c222823717894a13b7dd54a6620d9312@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.156]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/VjhMweqm8SsN-JU-rxTYvuWuW-M>
Subject: Re: [payload] Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Dec 2018 10:11:25 -0000

Hi,
In the -12 version why did you refer to the individual draft and not to htt=
ps://tools.ietf.org/html/draft-ietf-avtext-rid-09=20

Roni Even

-----Original Message-----
From: Giridhar Mandyam [mailto:mandyam@qti.qualcomm.com]=20
Sent: Thursday, December 06, 2018 11:03 PM
To: Roni Even (A); Magnus Westerlund
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Ben Campbell; payload@ietf.org
Subject: RE: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11

Sorry - sent out too soon.

The last change should have read:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a f=
ormat that can be used to identify a single RTP source stream along with an=
 associated repair stream.  However, this specification already defines a m=
ethod of source and repair stream identification that can enable protection=
 of multiple source streams with a single repair stream.  Therefore the RTP=
 Stream Idenfifer Source Description SHOULD NOT be used for the Flexible FE=
C payload format."

-----Original Message-----
From: Giridhar Mandyam=20
Sent: Thursday, December 6, 2018 12:59 PM
To: 'Roni Even (A)' <roni.even@huawei.com>; Magnus Westerlund <magnus.weste=
rlund@ericsson.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11

Magnus,
Here is the proposal to respond to your comments in https://mailarchive.iet=
f.org/arch/msg/payload/MkHU_bBWl_Dp1jRhlvnFpZB1ewI.

Thanks,
-Giri Mandyam

A. > At least in discussing this with Mo F2F I got the impression that the =
plan was to also be explicit about what the lack of it (ToP) means, i.e. it=
 can be any of the self describing usages, so a mix of retransmission and F=
EC is possible.

Proposed change:  The following sentence will be added to each ToP section:=
  " The absence of the ToP field means that all protection types are allowe=
d."

B. >The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at all  nee=
ded, even if it could be used in a sub-set of applications of  flexfec. It =
would work in same RTP Session, with a single repair RTP stream only protec=
ts a singe source RTP stream. But, considering the possibility of repair of=
 multiple source streams and different RTP Sessions, I think an explicit st=
atement that this SHOULD NOT be used for the payload format would be good t=
o include.

Proposed Change #1:  Add a reference to https://tools.ietf.org/html/draft-i=
etf-avtext-rid-09 in the Informative References section.

Proposed Change #2:  Add Section 7.2, entitled "On the Use of the RTP Strea=
m Identifier Source Description", with the following text:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a f=
ormat that can be used to identify a single RTP source stream along with an=
 associated repair stream.  However, since this specification already defin=
es a method of source and repair stream identification that can enable prot=
ection of Multiple source streams with a single repair stream.  Therefore t=
he RTP Stream Idenfifer Source Description SHOULD NOT be used for the Flexi=
ble FEC payload format."=20

-----Original Message-----
From: Roni Even (A) <roni.even@huawei.com>
Sent: Thursday, December 6, 2018 3:03 AM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>; Giridhar Mandyam <m=
andyam@qti.qualcomm.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: RE: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,
Can you send these messages to the list.
I am wondering about ToP, I saw a previous question from Magnus about using=
 for example ToP 0,3 (FEC plus retransmission) not allowed by current defin=
ition in 5.1.1 but if I read section 4.2.2.3 first paragraph correctly it i=
s allowed I also assume that Magnus asked for the default value for ToP and=
 I did not see any text in 5.1.1 Roni Even=20


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Thursday, December 06, 2018 10:32 AM
To: Ben Campbell
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; Giridhar Man=
dyam
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,

I have responded on the first question. Although I don't understand why tha=
t went off-list.

I want to comment on the second paragraph below.

On 2018-12-05 19:36, Ben Campbell wrote:
>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com>=
 wrote:
>>
>> I believe his first comment on ToP needs to be addressed in the revision=
.  I believe his second comment is more problematic, because it refers to a=
 standards-track document that has not achieved RFC status yet (i.e. it may=
 undergo changes), and I am not sure it will help the document.
>>
>>
Considering that draft-ietf-avtext-rid is approved and stuck in RFC-editor =
missref state on cluster 238 I don't see this as a reason for not addressin=
g my raised issue.

The reason I do want to raise this is that flexfec could be used in a sub-s=
et of cases, but is not necessary in any cases as the linking to the source=
 flow is provided in the FLEXFEC RTP packet. Thus, for making it clear that=
 it is not needed, I think an explicit statement should be added to that ef=
fect. If we don't have a statement we might find situations where people wi=
ll attempt to apply it and gets into the confusion if they try the FEC mode=
 with multiple source SSRCs where it doesn't work.

Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Mon Dec 10 03:44:21 2018
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EBD130F05 for <payload@ietfa.amsl.com>; Mon, 10 Dec 2018 03:44:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.757
X-Spam-Level: 
X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=FKquA/wk; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ib+Odkg1
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gypNsmjkB0kT for <payload@ietfa.amsl.com>; Mon, 10 Dec 2018 03:44:17 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A732B130EA5 for <payload@ietf.org>; Mon, 10 Dec 2018 03:44:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1544442254; x=1547034254; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IjZkRBd83e6OfyvBQp8a3I2H07I7EULvZMlzrGYHwgo=; b=FKquA/wkg/4fiOX8t5i/mfzLvn4Gnw/DDSdXeP6xquC1ZSduQsrp9YmrGcOc+REE weWw/vFXWPFWEMtuHyiZKy6EPeKEYnJ8fAEmfnVK35KOBKrgOMU0YTdS5s7jvTvb gKA36YvPwaZmQzAM/ZHnzmBgkOhtEYVEOQ3l7S6kCmQ=;
X-AuditID: c1b4fb25-a68609e00000191f-c9-5c0e518e824a
Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id D2.05.06431.E815E0C5; Mon, 10 Dec 2018 12:44:14 +0100 (CET)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 10 Dec 2018 12:44:13 +0100
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 10 Dec 2018 12:44:13 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Zs+GLB/RfLwhooCZz9h3T/3Zqbe8hsxRY6AF/qMs6uo=; b=ib+Odkg1Wl/UA+rf3OatJuv9ukCNIeKM49O0zxwI2fwirVRw+5Ga3KFEMkZMFv2ELHgwLa/MHOosYBzAFpiSCUFpiVlPAVBYHPBImbbFkrQ4TtpblRFXC+5UJ888NBRP5PMGe0H5EUKf52ktbv5Gw27+WCCYA66HXnrI8QtVhSo=
Received: from DB7PR07MB4988.eurprd07.prod.outlook.com (20.178.42.222) by DB7PR07MB5244.eurprd07.prod.outlook.com (20.178.43.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.13; Mon, 10 Dec 2018 11:44:12 +0000
Received: from DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::f896:8ab3:3108:c686]) by DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::f896:8ab3:3108:c686%6]) with mapi id 15.20.1425.016; Mon, 10 Dec 2018 11:44:12 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-flexible-fec-scheme@ietf.org" <draft-ietf-payload-flexible-fec-scheme@ietf.org>
Thread-Topic: I-D Action: draft-ietf-payload-flexible-fec-scheme-12.txt
Thread-Index: AQHUjoUvdLBEeda/kkmexzf4PAc0Iw==
Date: Mon, 10 Dec 2018 11:44:12 +0000
Message-ID: <DB7PR07MB498871F09483207ED3DFD2F695A50@DB7PR07MB4988.eurprd07.prod.outlook.com>
References: <154422554299.20231.1300848600231366801@ietfa.amsl.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR07MB5244; 6:M5Gnk+IchgVZVPtcQt/8V2a7ZZG6x3zwItYWiuhR6I/44xHlaTUmMZeK0jv4D8iaGnY/sSrDZoIPW2rP4qj/WM+dH4Fb93yzjqEbo34ENvj5dMO/RPwAoQbRSYAjT2wHhFEUo6qoA+l1J1iGXTB7bvYv1gqxXh5eOjfYrbjfLPsxTEjw6Mx5OrA93jpBHTLOhd15uAI8l6sqHLLt5DnfVdCtEO8WA3HByM8hH33uyOd8wV+kNnMMw7+vPndO04HUX2xiK8iC4m3QLZ6SUXAsYDCR/lem7CRpz8zBsTWlANH1CcVdWioWi0WUCjfWEMqp5dsqNlxkQia4npYcxvzTNXiN7Fd1e7OEsvTJQB0hgYdfM6QavmV5/MPN0QhGfkvma9a+cpYrOsKQ/k6jYc+IAnE1OTFZ9yNG5gLZJ4zcHiWWraHfeNZTZ/UqyTtUsOxktwwAJHPk6vOHTLPcs+dd2A==; 5:Ey39WSViRvyvyOT8ODP8Zlo1NoRA5okUMGx3y48c3Vfa/5hkOc4dGUkLhUKCBPs+vJjwQMEusDBELJfDwRPA1zUtg0s/VANZN2pojFiyn0ltpFtciN+5Sp8s3NUa71PEcw8acNV5eZdgJ41b2ko5OEO2HdFK5euyz2rJ+PrZe/k=; 7:TTN9GMkc3XOOsm+untTLqpZ6FPvbr+OhHqTiaUfI5V2FYF2ntFJbaGLfXcE8cNEbl3a6MrpfV8KqjwJhbabKn7ggfpRWquU0RJWwx7Z1aUaGT6MHKfrq2R5yq6hyJKaCYgOWAuDum3aQfaDK/pKBgg==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 7291c6b8-31a5-4817-ff74-08d65e94ce1d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB7PR07MB5244; 
x-ms-traffictypediagnostic: DB7PR07MB5244:
x-microsoft-antispam-prvs: <DB7PR07MB5244A3BF74910C7621DBDC7195A50@DB7PR07MB5244.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231455)(999002)(944501520)(4982022)(52105112)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB5244; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB5244; 
x-forefront-prvs: 08828D20BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(366004)(39860400002)(376002)(189003)(199004)(6506007)(476003)(486006)(33656002)(66066001)(21615005)(71200400001)(53546011)(966005)(25786009)(44832011)(7736002)(68736007)(446003)(5660300001)(26005)(81166006)(81156014)(2906002)(606006)(229853002)(14454004)(186003)(6436002)(478600001)(102836004)(8676002)(74316002)(6116002)(53936002)(8936002)(3846002)(76176011)(9686003)(2501003)(7696005)(106356001)(54896002)(6306002)(105586002)(55016002)(86362001)(14444005)(256004)(99286004)(110136005)(236005)(316002)(66574011)(71190400001)(4326008)(97736004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5244; H:DB7PR07MB4988.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: pZ94jky+zq32Un9nIwgQjv7cUEeREhi/83jB7M6S3qUPR+eTM51F8v34QxLWdl590cOkMcXkNYwDsf3lYeZ2pSB4UptRsJEvBB2JM5PtJgLf3/LKpSfZJTwtiF1zn0KWRkTqcrP9YgeTPoFNkveX24WM7vT47QM7FIESgsUN29xcqh9L73B2dkhgI8gVS5tmAbBGVKbY8vmTrj8Pi2133KKmxfErTpBZjMxow95JU6n2o8MczrZNYQjDX1ZE7xcRzVF5lqu9ZWbPZ+u5oVUw7lEqdbGaP0fOaJR1CsJHpJH1xQoWVMMBk8F07dyx9A0B
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB7PR07MB498871F09483207ED3DFD2F695A50DB7PR07MB4988eurp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7291c6b8-31a5-4817-ff74-08d65e94ce1d
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2018 11:44:12.4376 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5244
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUyM2J7sW5fIF+MwfLrghbzO0+zW/y9XWRx 6eJZJgdmjyVLfjJ5zNr5hCWAKYrLJiU1J7MstUjfLoEr4/Dn/IKHORWT+46zNzBOj+pi5OSQ EDCRmDTjBVMXIxeHkMARRokT/5sZQRJCAt8YJQ5NioNILGGSWLnhDguIwyIwgVli9sur7BBV k5kktv5RhKh6xCix7c8msASbgIXEzR+NbCAJEYFJjBI7Du5hBkkwCyhJ7Nt+hBXEFhZwk5j8 dhsLiC0i4C7x4uJkVghbT+LUwt1gg1gEVCXO79kC1ssrECMxo/M/1GZniY6J18DqGQVkJe5/ v8cCMV9c4taT+UwQzwlILNlznhnCFpV4+fgfVH2ixI3Gp1A1ChL3f02GqpGVuDS/mxHkaAmB a2wS1w7/Y4FI6Ep8mDoVqshXYt6F5ewQRRcYJV5MWAhVpCXxtH0e0AYOIDtbYhYoWEDCchKr eh+yQNTfYJb42vUOqkZG4s4+8wmMerOQ3A1h50s07f7APAvsZ0GJkzOfsEDEdSQW7P7EBmFr Syxb+JoZxj5z4DETsvgCRvZVjKLFqcVJuelGxnqpRZnJxcX5eXp5qSWbGIFp6OCW36o7GC+/ cTzEKMDBqMTDu9eDL0aINbGsuDL3EKMEB7OSCK9uGm+MEG9KYmVValF+fFFpTmrxIUZpDhYl cV4/LaBqgfTEktTs1NSC1CKYLBMHp1QDo24ka7vv7Gb/v6+fX5q3eKqmr6nodvtHeeud32ac uGlyuvFvRPuFQxv/Oa4uLDvhX614eMfbPP2u23GarkEKfz5d+RTxg11AITgr6Jxy9s3IrFeR kkeeCpz+tt7hVUu5rodcy5smi0Idvw1Lf5dKh/uWlx3YGGtafWzL5z2nW3VXtgs2HLq6QYml OCPRUIu5qDgRAE9PKEs/AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/cuFC26bWR4-fEjVvn0_6ZTZ3BMw>
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-12.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Dec 2018 11:44:20 -0000

--_000_DB7PR07MB498871F09483207ED3DFD2F695A50DB7PR07MB4988eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Authors.

With the exception of the id-nits and RID reference this is ready. But can =
you please addresses the below relevant ID-nits and update the reference to=
 RID to the WG version. Authors should always run ID-nits before submitting=
 a version. It avoids so many small errors.


/tmp/draft-ietf-payload-flexible-fec-scheme-12.txt(1946): Found possible IP=
v4 address '143.163.151.157' in position 18; this doesn't match the suggest=
ed documentation address ranges specified in RFC 6890 (or successor): block=
s 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/=
24 (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) example multicast a=
ddress range specified in RFC 5771.


  =3D=3D Unused Reference: 'RFC6709' is defined on line 1735, but no explic=
it
     reference was found in the text
     '[RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design C.=
..'

  =3D=3D Unused Reference: 'RFC2733' is defined on line 1762, but no explic=
it
     reference was found in the text
     '[RFC2733]  Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format..=
.'

  =3D=3D Unused Reference: 'SMPTE2022-1' is defined on line 1801, but no ex=
plicit
     reference was found in the text
     '[SMPTE2022-1] SMPTE 2022-1-2007, "Forward Error Correction for Real-.=
..'

  ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 485=
6)

  ** Downref: Normative reference to an Informational RFC: RFC 6709

  -- Obsolete informational reference (is this intentional?): RFC 2326
     (Obsoleted by RFC 7826)

  -- Obsolete informational reference (is this intentional?): RFC 2733
     (Obsoleted by RFC 5109)

  -- Obsolete informational reference (is this intentional?): RFC 5246
     (Obsoleted by RFC 8446)

Replace I-D.roach-avtext-rid] with

https://tools.ietf.org/html/draft-ietf-avtext-rid-09

Cheers

Magnus

On 2018-12-08 00:32, internet-drafts@ietf.org<mailto:internet-drafts@ietf.o=
rg> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Audio/Video Transport Payloads WG of the I=
ETF.

        Title           : RTP Payload Format for Flexible Forward Error Cor=
rection (FEC)
        Authors         : Mo Zanaty
                          Varun Singh
                          Ali Begen
                          Giridhar Mandyam
        Filename        : draft-ietf-payload-flexible-fec-scheme-12.txt
        Pages           : 41
        Date            : 2018-12-07

Abstract:
   This document defines new RTP payload formats for the Forward Error
   Correction (FEC) packets that are generated by the non-interleaved
   and interleaved parity codes from source media encapsulated in RTP.
   These parity codes are systematic codes, where a number of FEC repair
   packets are generated from a set of source packets from one or more
   source RTP streams.  These FEC repair packets are sent in a
   redundancy RTP stream separate from the source RTP stream(s) that
   carries the source packets.  RTP source packets that were lost in
   transmission can be reconstructed using the source and repair packets
   that were received.  The non-interleaved and interleaved parity codes
   which are defined in this specification offer a good protection
   against random and bursty packet losses, respectively, at a cost of
   decent complexity.  The RTP payload formats that are defined in this
   document address the scalability issues experienced with the earlier
   specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and
   offer several improvements.  Due to these changes, the new payload
   formats are not backward compatible with the earlier specifications,
   but endpoints that do not implement this specification can still work
   by simply ignoring the FEC repair packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-12
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-schem=
e-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-flexible-fec-scheme-=
12


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt




--

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com<mailto=
:magnus.westerlund@ericsson.com>
----------------------------------------------------------------------

--_000_DB7PR07MB498871F09483207ED3DFD2F695A50DB7PR07MB4988eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-cite-prefix">Hi Authors. <br>
</div>
<div class=3D"moz-cite-prefix"><br>
</div>
<div class=3D"moz-cite-prefix">With the exception of the id-nits and RID re=
ference this is ready. But can you please addresses the below relevant ID-n=
its and update the reference to RID to the WG version. Authors should alway=
s run ID-nits before submitting a
 version. It avoids so many small errors. <br>
</div>
<div class=3D"moz-cite-prefix"><br>
</div>
<div class=3D"moz-cite-prefix">
<pre>/tmp/draft-ietf-payload-flexible-fec-scheme-12.txt(1946): Found possib=
le IPv4 address '143.163.151.157' in position 18; this doesn't match the su=
ggested documentation address ranges specified in RFC 6890 (or successor): =
blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.1=
13.0/24 (TEST-NET-3); or the 233.252.0.0/24 (MCAST-TEST-NET) example multic=
ast address range specified in RFC 5771.</pre>
</div>
<div class=3D"moz-cite-prefix"><br>
</div>
<div class=3D"moz-cite-prefix">
<pre>  =3D=3D Unused Reference: 'RFC6709' is defined on line 1735, but no e=
xplicit=0A=
     reference was found in the text=0A=
     '[RFC6709]  Carpenter, B., Aboba, B., Ed., and S. Cheshire, &quot;Desi=
gn C...'=0A=
=0A=
  =3D=3D Unused Reference: 'RFC2733' is defined on line 1762, but no explic=
it=0A=
     reference was found in the text=0A=
     '[RFC2733]  Rosenberg, J. and H. Schulzrinne, &quot;An RTP Payload For=
mat...'=0A=
=0A=
  =3D=3D Unused Reference: 'SMPTE2022-1' is defined on line 1801, but no ex=
plicit=0A=
     reference was found in the text=0A=
     '[SMPTE2022-1] SMPTE 2022-1-2007, &quot;Forward Error Correction for R=
eal-...'=0A=
=0A=
  ** Obsolete normative reference: RFC 3555 (Obsoleted by RFC 4855, RFC 485=
6)=0A=
=0A=
  ** Downref: Normative reference to an Informational RFC: RFC 6709=0A=
=0A=
  -- Obsolete informational reference (is this intentional?): RFC 2326=0A=
     (Obsoleted by RFC 7826)=0A=
=0A=
  -- Obsolete informational reference (is this intentional?): RFC 2733=0A=
     (Obsoleted by RFC 5109)=0A=
=0A=
  -- Obsolete informational reference (is this intentional?): RFC 5246=0A=
     (Obsoleted by RFC 8446)</pre>
</div>
<div class=3D"moz-cite-prefix"><br>
</div>
<div class=3D"moz-cite-prefix">Replace I-D.roach-avtext-rid] with<br>
<pre class=3D"moz-quote-pre" wrap=3D""><a class=3D"moz-txt-link-freetext" h=
ref=3D"https://tools.ietf.org/html/draft-ietf-avtext-rid-09">https://tools.=
ietf.org/html/draft-ietf-avtext-rid-09</a> </pre>
</div>
<div class=3D"moz-cite-prefix"><br>
</div>
<div class=3D"moz-cite-prefix">Cheers</div>
<div class=3D"moz-cite-prefix"><br>
</div>
<div class=3D"moz-cite-prefix">Magnus<br>
</div>
<div class=3D"moz-cite-prefix"><br>
</div>
<div class=3D"moz-cite-prefix">On 2018-12-08 00:32, <a class=3D"moz-txt-lin=
k-abbreviated" href=3D"mailto:internet-drafts@ietf.org">
internet-drafts@ietf.org</a> wrote:<br>
</div>
<blockquote type=3D"cite" cite=3D"mid:154422554299.20231.130084860023136680=
1@ietfa.amsl.com">
<pre class=3D"moz-quote-pre" wrap=3D"">=0A=
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.=0A=
This draft is a work item of the Audio/Video Transport Payloads WG of the I=
ETF.=0A=
=0A=
        Title           : RTP Payload Format for Flexible Forward Error Cor=
rection (FEC)=0A=
        Authors         : Mo Zanaty=0A=
                          Varun Singh=0A=
                          Ali Begen=0A=
                          Giridhar Mandyam=0A=
	Filename        : draft-ietf-payload-flexible-fec-scheme-12.txt=0A=
	Pages           : 41=0A=
	Date            : 2018-12-07=0A=
=0A=
Abstract:=0A=
   This document defines new RTP payload formats for the Forward Error=0A=
   Correction (FEC) packets that are generated by the non-interleaved=0A=
   and interleaved parity codes from source media encapsulated in RTP.=0A=
   These parity codes are systematic codes, where a number of FEC repair=0A=
   packets are generated from a set of source packets from one or more=0A=
   source RTP streams.  These FEC repair packets are sent in a=0A=
   redundancy RTP stream separate from the source RTP stream(s) that=0A=
   carries the source packets.  RTP source packets that were lost in=0A=
   transmission can be reconstructed using the source and repair packets=0A=
   that were received.  The non-interleaved and interleaved parity codes=0A=
   which are defined in this specification offer a good protection=0A=
   against random and bursty packet losses, respectively, at a cost of=0A=
   decent complexity.  The RTP payload formats that are defined in this=0A=
   document address the scalability issues experienced with the earlier=0A=
   specifications including RFC 2733, RFC 5109 and SMPTE 2022-1, and=0A=
   offer several improvements.  Due to these changes, the new payload=0A=
   formats are not backward compatible with the earlier specifications,=0A=
   but endpoints that do not implement this specification can still work=0A=
   by simply ignoring the FEC repair packets.=0A=
=0A=
=0A=
The IETF datatracker status page for this draft is:=0A=
<a class=3D"moz-txt-link-freetext" href=3D"https://datatracker.ietf.org/doc=
/draft-ietf-payload-flexible-fec-scheme/">https://datatracker.ietf.org/doc/=
draft-ietf-payload-flexible-fec-scheme/</a>=0A=
=0A=
There are also htmlized versions available at:=0A=
<a class=3D"moz-txt-link-freetext" href=3D"https://tools.ietf.org/html/draf=
t-ietf-payload-flexible-fec-scheme-12">https://tools.ietf.org/html/draft-ie=
tf-payload-flexible-fec-scheme-12</a>=0A=
<a class=3D"moz-txt-link-freetext" href=3D"https://datatracker.ietf.org/doc=
/html/draft-ietf-payload-flexible-fec-scheme-12">https://datatracker.ietf.o=
rg/doc/html/draft-ietf-payload-flexible-fec-scheme-12</a>=0A=
=0A=
A diff from the previous version is available at:=0A=
<a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf.org/rfcdiff?url=
2=3Ddraft-ietf-payload-flexible-fec-scheme-12">https://www.ietf.org/rfcdiff=
?url2=3Ddraft-ietf-payload-flexible-fec-scheme-12</a>=0A=
=0A=
=0A=
Please note that it may take a couple of minutes from the time of submissio=
n=0A=
until the htmlized version and diff are available at tools.ietf.org.=0A=
=0A=
Internet-Drafts are also available by anonymous FTP at:=0A=
<a class=3D"moz-txt-link-freetext" href=3D"ftp://ftp.ietf.org/internet-draf=
ts/">ftp://ftp.ietf.org/internet-drafts/</a>=0A=
=0A=
_______________________________________________=0A=
I-D-Announce mailing list=0A=
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:I-D-Announce@ietf.org"=
>I-D-Announce@ietf.org</a>=0A=
<a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf.org/mailman/lis=
tinfo/i-d-announce">https://www.ietf.org/mailman/listinfo/i-d-announce</a>=
=0A=
Internet-Draft directories: <a class=3D"moz-txt-link-freetext" href=3D"http=
://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>=0A=
or <a class=3D"moz-txt-link-freetext" href=3D"ftp://ftp.ietf.org/ietf/1shad=
ow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>=0A=
=0A=
</pre>
</blockquote>
<p><br>
</p>
<pre class=3D"moz-signature" cols=3D"72">-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture &amp; Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  &#43;46 10 7148287=0A=
Torshamnsgatan 23           | Mobile &#43;46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: <a class=3D"moz-txt-link-abbreviated"=
 href=3D"mailto:magnus.westerlund@ericsson.com">magnus.westerlund@ericsson.=
com</a>=0A=
----------------------------------------------------------------------</pre=
>
</body>
</html>

--_000_DB7PR07MB498871F09483207ED3DFD2F695A50DB7PR07MB4988eurp_--


From nobody Mon Dec 10 13:21:05 2018
Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D21DA130F41 for <payload@ietfa.amsl.com>; Mon, 10 Dec 2018 13:21:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TweiniGpbnBE for <payload@ietfa.amsl.com>; Mon, 10 Dec 2018 13:21:01 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE62E130F3E for <payload@ietf.org>; Mon, 10 Dec 2018 13:21:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1544476860; x=1576012860; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6hWtM7T7X/H1WZCzB7+sdnJet4zXC91DbT6/vV80l5s=; b=tPrNTaRkeeWbW2h0GjH7QmCSruZPfDDUYGLNRNN8D/v9O7ZG3oozrqof E7kUthljjRSxfwjCH9qeDwfuVDlpsOrh2ZIfcDHrTTPYorZ41VoVTvKXx mGi7LYu6yjTxsLn7B8mvXLuFHb7CjWTbx+DRwLXFi+fVCmF2tYEmOUKrI o=;
X-IronPort-AV: E=Sophos;i="5.56,339,1539673200"; d="scan'208";a="16972597"
Received: from unknown (HELO ironmsg03-sd.qualcomm.com) ([10.53.140.143]) by alexa-out-sd-01.qualcomm.com with ESMTP; 10 Dec 2018 13:20:59 -0800
Received: from nasanexm01c.na.qualcomm.com ([10.85.0.83]) by ironmsg03-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 10 Dec 2018 13:20:59 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01C.na.qualcomm.com (10.85.0.83) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 10 Dec 2018 13:20:58 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Mon, 10 Dec 2018 13:20:58 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "Roni Even (A)" <roni.even@huawei.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "Ali C. Begen" <ali.begen@networked.media>, "Mo Zanaty (mzanaty)" <mzanaty@cisco.com>, Ben Campbell <ben@nostrum.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
Thread-Index: AdSNorPPkyx2u/zORBuZfJA8MKesUwABEXtQALJmQOAAFt02EA==
Date: Mon, 10 Dec 2018 21:20:58 +0000
Message-ID: <f38691a1b66742de940d0d477dd11056@NASANEXM01C.na.qualcomm.com>
References: <113ed79cfaa347edb8b89a7ac5af3d69@NASANEXM01C.na.qualcomm.com> <c222823717894a13b7dd54a6620d9312@NASANEXM01C.na.qualcomm.com> <6E58094ECC8D8344914996DAD28F1CCD18C8F81D@DGGEMM506-MBX.china.huawei.com>
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD18C8F81D@DGGEMM506-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/Teh0pxlDQQo4M_R2by9IxYdVq7E>
Subject: Re: [payload] Proposed changes to draft-ietf-payload-flexible-fec-scheme-11
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Dec 2018 21:21:04 -0000

Hi,

Imported the wrong XML file.  I will fix when taking care of the other nits=
 that Magnus brought up in his other email.

Thanks,

-Giri

-----Original Message-----
From: Roni Even (A) <roni.even@huawei.com>=20
Sent: Monday, December 10, 2018 2:11 AM
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; Magnus Westerlund <magnus.=
westerlund@ericsson.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: RE: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11

Hi,
In the -12 version why did you refer to the individual draft and not to htt=
ps://tools.ietf.org/html/draft-ietf-avtext-rid-09=20

Roni Even

-----Original Message-----
From: Giridhar Mandyam [mailto:mandyam@qti.qualcomm.com]=20
Sent: Thursday, December 06, 2018 11:03 PM
To: Roni Even (A); Magnus Westerlund
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Ben Campbell; payload@ietf.org
Subject: RE: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11

Sorry - sent out too soon.

The last change should have read:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a f=
ormat that can be used to identify a single RTP source stream along with an=
 associated repair stream.  However, this specification already defines a m=
ethod of source and repair stream identification that can enable protection=
 of multiple source streams with a single repair stream.  Therefore the RTP=
 Stream Idenfifer Source Description SHOULD NOT be used for the Flexible FE=
C payload format."

-----Original Message-----
From: Giridhar Mandyam=20
Sent: Thursday, December 6, 2018 12:59 PM
To: 'Roni Even (A)' <roni.even@huawei.com>; Magnus Westerlund <magnus.weste=
rlund@ericsson.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: Proposed changes to draft-ietf-payload-flexible-fec-scheme-11

Magnus,
Here is the proposal to respond to your comments in https://mailarchive.iet=
f.org/arch/msg/payload/MkHU_bBWl_Dp1jRhlvnFpZB1ewI.

Thanks,
-Giri Mandyam

A. > At least in discussing this with Mo F2F I got the impression that the =
plan was to also be explicit about what the lack of it (ToP) means, i.e. it=
 can be any of the self describing usages, so a mix of retransmission and F=
EC is possible.

Proposed change:  The following sentence will be added to each ToP section:=
  " The absence of the ToP field means that all protection types are allowe=
d."

B. >The use of draft-ietf-avtext-rid RepairedRtpStreamId is not at all  nee=
ded, even if it could be used in a sub-set of applications of  flexfec. It =
would work in same RTP Session, with a single repair RTP stream only protec=
ts a singe source RTP stream. But, considering the possibility of repair of=
 multiple source streams and different RTP Sessions, I think an explicit st=
atement that this SHOULD NOT be used for the payload format would be good t=
o include.

Proposed Change #1:  Add a reference to https://tools.ietf.org/html/draft-i=
etf-avtext-rid-09 in the Informative References section.

Proposed Change #2:  Add Section 7.2, entitled "On the Use of the RTP Strea=
m Identifier Source Description", with the following text:

"The RTP Stream Identifier Source Description [I.-D.ietf-avtext-rid] is a f=
ormat that can be used to identify a single RTP source stream along with an=
 associated repair stream.  However, since this specification already defin=
es a method of source and repair stream identification that can enable prot=
ection of Multiple source streams with a single repair stream.  Therefore t=
he RTP Stream Idenfifer Source Description SHOULD NOT be used for the Flexi=
ble FEC payload format."=20

-----Original Message-----
From: Roni Even (A) <roni.even@huawei.com>
Sent: Thursday, December 6, 2018 3:03 AM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>; Giridhar Mandyam <m=
andyam@qti.qualcomm.com>
Cc: Ali C. Begen <ali.begen@networked.media>; Mo Zanaty (mzanaty) <mzanaty@=
cisco.com>; Ben Campbell <ben@nostrum.com>; payload@ietf.org
Subject: RE: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,
Can you send these messages to the list.
I am wondering about ToP, I saw a previous question from Magnus about using=
 for example ToP 0,3 (FEC plus retransmission) not allowed by current defin=
ition in 5.1.1 but if I read section 4.2.2.3 first paragraph correctly it i=
s allowed I also assume that Magnus asked for the default value for ToP and=
 I did not see any text in 5.1.1 Roni Even=20


-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Thursday, December 06, 2018 10:32 AM
To: Ben Campbell
Cc: Ali C. Begen; Mo Zanaty (mzanaty); Roni Even (A); ART ADs; Giridhar Man=
dyam
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
0.txt

Hi,

I have responded on the first question. Although I don't understand why tha=
t went off-list.

I want to comment on the second paragraph below.

On 2018-12-05 19:36, Ben Campbell wrote:
>> On Dec 5, 2018, at 12:28 PM, Giridhar Mandyam <mandyam@qti.qualcomm.com>=
 wrote:
>>
>> I believe his first comment on ToP needs to be addressed in the revision=
.  I believe his second comment is more problematic, because it refers to a=
 standards-track document that has not achieved RFC status yet (i.e. it may=
 undergo changes), and I am not sure it will help the document.
>>
>>
Considering that draft-ietf-avtext-rid is approved and stuck in RFC-editor =
missref state on cluster 238 I don't see this as a reason for not addressin=
g my raised issue.

The reason I do want to raise this is that flexfec could be used in a sub-s=
et of cases, but is not necessary in any cases as the linking to the source=
 flow is provided in the FLEXFEC RTP packet. Thus, for making it clear that=
 it is not needed, I think an explicit statement should be added to that ef=
fect. If we don't have a statement we might find situations where people wi=
ll attempt to apply it and gets into the confusion if they try the FEC mode=
 with multiple source SSRCs where it doesn't work.

Cheers=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Tue Dec 11 10:56:24 2018
Return-Path: <internet-drafts@ietf.org>
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2C4130F17; Tue, 11 Dec 2018 10:56:14 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: payload@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: payload@ietf.org
Message-ID: <154455457454.13143.14509030085765652926@ietfa.amsl.com>
Date: Tue, 11 Dec 2018 10:56:14 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/tHZB9DIvzCuPnZ26CETfNrlshTY>
Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2018 18:56:15 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Payloads WG of the IETF.

        Title           : RTP Payload Format for Flexible Forward Error Correction (FEC)
        Authors         : Mo Zanaty
                          Varun Singh
                          Ali Begen
                          Giridhar Mandyam
	Filename        : draft-ietf-payload-flexible-fec-scheme-13.txt
	Pages           : 41
	Date            : 2018-12-11

Abstract:
   This document defines new RTP payload formats for the Forward Error
   Correction (FEC) packets that are generated by the non-interleaved
   and interleaved parity codes from source media encapsulated in RTP.
   These parity codes are systematic codes, where a number of FEC repair
   packets are generated from a set of source packets from one or more
   source RTP streams.  These FEC repair packets are sent in a
   redundancy RTP stream separate from the source RTP stream(s) that
   carries the source packets.  RTP source packets that were lost in
   transmission can be reconstructed using the source and repair packets
   that were received.  The non-interleaved and interleaved parity codes
   which are defined in this specification offer a good protection
   against random and bursty packet losses, respectively, at a cost of
   decent complexity.  The RTP payload formats that are defined in this
   document address scalability issues experienced with the earlier
   specifications, and offer several improvements.  Due to these
   changes, the new payload formats are not backward compatible with
   earlier specifications, but endpoints that do not implement this
   specification can still work by simply ignoring the FEC repair
   packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-13
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-scheme-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-flexible-fec-scheme-13


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Dec 11 11:02:03 2018
Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A48130F30 for <payload@ietfa.amsl.com>; Tue, 11 Dec 2018 11:01:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks8CnVjqlKWL for <payload@ietfa.amsl.com>; Tue, 11 Dec 2018 11:01:57 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD65130F18 for <payload@ietf.org>; Tue, 11 Dec 2018 11:01:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1544554916; x=1576090916; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dqw3osbg3/gQPMyQe6HHAIoGJtrDPiSPdfp1oXfX6aE=; b=l8dX8fhpXiO5WSZdk2ome0jk+YUr97bWKstGnFt9Stny9/2fuaqzTM0e +6yLHkaRWvEk50M7GnGxz68ahJTiy8ihN923TKso/LWSjY8Zge3I7x2fQ 7231em7SSM28ILcq+FtgkgUE6DEz5xjcS0Utf/scSzCeWGE7ymy6BCwjk w=;
X-IronPort-AV: E=Sophos;i="5.56,343,1539673200"; d="scan'208";a="17129643"
Received: from unknown (HELO ironmsg-SD-alpha.qualcomm.com) ([10.53.140.30]) by alexa-out-sd-01.qualcomm.com with ESMTP; 11 Dec 2018 11:01:55 -0800
X-IronPort-AV: E=McAfee;i="5900,7806,9103"; a="311667999"
Received: from nasanexm01a.na.qualcomm.com ([10.85.0.81]) by ironmsg-SD-alpha.qualcomm.com with ESMTP/TLS/AES256-SHA; 11 Dec 2018 11:01:55 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by nasanexm01a.na.qualcomm.com (10.85.0.81) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 11 Dec 2018 11:01:55 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Tue, 11 Dec 2018 11:01:55 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
Thread-Index: AQHUkYNOwBwcl0RgWUyBftJvM248iKV547eQ
Date: Tue, 11 Dec 2018 19:01:54 +0000
Message-ID: <d47f7a5e86374769b38b361ada051036@NASANEXM01C.na.qualcomm.com>
References: <154455457454.13143.14509030085765652926@ietfa.amsl.com>
In-Reply-To: <154455457454.13143.14509030085765652926@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/cLm8rfbQXrgMgA1LZv3m9NLxDEw>
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Dec 2018 19:01:59 -0000

Please note that I cleared out as many nits as I thought made sense.  Curre=
nt nit check showed zero errors, but a few warnings and comments.  I also u=
pdated the avtext-rid reference.

I modified the abstract slightly as inclusion of references violated RFC 73=
22, Sec. 4.3.   As a result, I removed those references from the abstract a=
nd added a sentence in the Introduction that provided the references.

-Giri Mandyam

-----Original Message-----
From: payload <payload-bounces@ietf.org> On Behalf Of internet-drafts@ietf.=
org
Sent: Tuesday, December 11, 2018 10:56 AM
To: i-d-announce@ietf.org
Cc: payload@ietf.org
Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.tx=
t


A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
This draft is a work item of the Audio/Video Transport Payloads WG of the I=
ETF.

        Title           : RTP Payload Format for Flexible Forward Error Cor=
rection (FEC)
        Authors         : Mo Zanaty
                          Varun Singh
                          Ali Begen
                          Giridhar Mandyam
	Filename        : draft-ietf-payload-flexible-fec-scheme-13.txt
	Pages           : 41
	Date            : 2018-12-11

Abstract:
   This document defines new RTP payload formats for the Forward Error
   Correction (FEC) packets that are generated by the non-interleaved
   and interleaved parity codes from source media encapsulated in RTP.
   These parity codes are systematic codes, where a number of FEC repair
   packets are generated from a set of source packets from one or more
   source RTP streams.  These FEC repair packets are sent in a
   redundancy RTP stream separate from the source RTP stream(s) that
   carries the source packets.  RTP source packets that were lost in
   transmission can be reconstructed using the source and repair packets
   that were received.  The non-interleaved and interleaved parity codes
   which are defined in this specification offer a good protection
   against random and bursty packet losses, respectively, at a cost of
   decent complexity.  The RTP payload formats that are defined in this
   document address scalability issues experienced with the earlier
   specifications, and offer several improvements.  Due to these
   changes, the new payload formats are not backward compatible with
   earlier specifications, but endpoints that do not implement this
   specification can still work by simply ignoring the FEC repair
   packets.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-13
https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-schem=
e-13

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-flexible-fec-scheme-=
13


Please note that it may take a couple of minutes from the time of submissio=
n until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


From nobody Wed Dec 12 09:07:50 2018
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE2A130F12 for <payload@ietfa.amsl.com>; Wed, 12 Dec 2018 09:07:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.758
X-Spam-Level: 
X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=e2a8qKao; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZmbXPwGS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4ohrZzK5Kqt for <payload@ietfa.amsl.com>; Wed, 12 Dec 2018 09:07:46 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36BC7130F11 for <payload@ietf.org>; Wed, 12 Dec 2018 09:07:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1544634464; x=1547226464; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YWd+BAVN5Ru9v7CWInnIaeSH7DDvyyZbSjeGA8Hxf6Q=; b=e2a8qKaohJUXc4zeYzQAdo8sEUUuV/oTH8ezbgAVfxmdfv68Q5IPjROvb1Q4HBzz rbZp582tls5bULqk5tHVokCxbO2kGU6x36f2X5g4+0rPcrl4VUi7AwZyfupcRrom 0c7dJQ++ZWu/zoTpClqzziXKAm9+AuZcNMLY7vu8fRU=;
X-AuditID: c1b4fb30-f15ff700000043c4-7f-5c11406099c1
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 90.7D.17348.060411C5; Wed, 12 Dec 2018 18:07:44 +0100 (CET)
Received: from ESESBMB501.ericsson.se (153.88.183.168) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 12 Dec 2018 18:07:43 +0100
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 12 Dec 2018 18:07:43 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DSR8fdNI6ZsGSedl3ztvgKnZczBI8VB9tJS0zC0W0cA=; b=ZmbXPwGSJ0VcP9CyWu8bPvZvpqLxSBL4x3m64CxTLZSVu+AEsii36Vu2u76u1YxE4wo61NhIf+ooaRVcA4nWpczGSL7xEKQWL/MHbO33E/NE96G0RslFUvx1Lq0bMX9KJF5AmE5Pk0wI5f2+1f6JTh/nu32SPOxpDQhUlj/yb9o=
Received: from DB7PR07MB4988.eurprd07.prod.outlook.com (20.178.42.222) by DB7PR07MB4869.eurprd07.prod.outlook.com (20.177.123.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.8; Wed, 12 Dec 2018 17:07:41 +0000
Received: from DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::f896:8ab3:3108:c686]) by DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::f896:8ab3:3108:c686%6]) with mapi id 15.20.1425.016; Wed, 12 Dec 2018 17:07:41 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
Thread-Index: AQHUkYNNPGC4Er/nT0KhreRKPYco/Q==
Date: Wed, 12 Dec 2018 17:07:40 +0000
Message-ID: <DB7PR07MB49880261F6563E347598DF6A95A70@DB7PR07MB4988.eurprd07.prod.outlook.com>
References: <154455457454.13143.14509030085765652926@ietfa.amsl.com> <d47f7a5e86374769b38b361ada051036@NASANEXM01C.na.qualcomm.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR07MB4869; 6:TPLjs/t3mAtLcCdfnPfJxXHtWHM4ZeXeKRgXqcS0hh+bwZlqo02FbiqWG/cxR4zog9elPu9qHvP6lfcdZDU1HEbtkZh6JXtjVUU0cJVvZurEraWHqOXN7kDm5eIufmjDLhbFkwl7ebaRX7GhRi/pfBjti9fe7xbiysuOg57WMrlL1uxUKpEpUw2U7E7Qd4akRP+tSqKAFFpJgcmPfXXo+LQNitjIC/wD5sFp+6vOWlFpIp/KVxWjsCW1tuNjw1QuFHsJ6mkMRkU5ciC3AZ73l/RP57J/PgOo2IPVGcze4pYq3W3tgXPFgC6aP7owzQGzU+CBsXGS7qwSvsfEC/DdFLMH1Ru+W3PvAthXIkVuBJnlDGlrkdYoUnEtolZTUGMdQ6SCCV7Lhpf+BxcwmVaZOBlgMyL2mq3w+47YprDPBUaHQZLz8j3k4n2vwFVJiI2uZF68Uubg7Aep6uWjo8jslw==; 5:o4SqSRrxTBIX0z1CV3nqQYAVBl2SvsQgKtc+2M+6CRFD9BcDHiSIn6HAdfzL6yNsM8bBwYBq52OJpbcO438TPqqayBSRINn2qPGxCd6sgFnXQgCIdnJuOeg8RcU4qhK7Tfh33e/fzbxsLYrL21EXLNn2nq7VnfbFZfZNwSxWFBM=; 7:2S9Pyy1wtNcpeECpzDlyH3nFGxe7/DE4SyRn0BhaVi1JIP2idFHpBzbglzi7cmwl63Rw+ykDe9Xa4iuW0XsungWE2TafsNwT5VHHPCB8bqOINJDqlgYmnw4qU07IdtjaNdos6Jj91gV8N9aOjGkjbw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 4f9c6a0f-9e9e-401f-635b-08d660545347
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB7PR07MB4869; 
x-ms-traffictypediagnostic: DB7PR07MB4869:
x-microsoft-antispam-prvs: <DB7PR07MB4869D3677C1B7C09D9F4352295A70@DB7PR07MB4869.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231455)(999002)(944501520)(52105112)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4869; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4869; 
x-forefront-prvs: 0884AAA693
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(346002)(376002)(396003)(199004)(189003)(13464003)(102836004)(81156014)(81166006)(71190400001)(26005)(71200400001)(6436002)(106356001)(53546011)(33656002)(14454004)(66066001)(66574011)(2501003)(3846002)(25786009)(68736007)(6116002)(4001150100001)(229853002)(8676002)(97736004)(186003)(446003)(8936002)(99286004)(476003)(55016002)(256004)(486006)(6306002)(7736002)(966005)(6246003)(305945005)(14444005)(44832011)(478600001)(7696005)(105586002)(6506007)(76176011)(53936002)(9686003)(110136005)(316002)(5660300001)(86362001)(74316002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4869; H:DB7PR07MB4988.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gppS1aWvea8RY+GMHO/QIk19+9vNqT3mws3Exm0x9QchwoAnasb1vvlOx1Fr7uHDUkgV1yqGUq0RIH66Nx3pQaAXQ5H3orUaFw3CmiRwssjpX9/Q8GrN6sJ2t1Y7+WdAPvRpiFj3tOeOC0CVqz1GgzwekhGTfDZkEw4IVZvZ6t5Aajfuse5h9V9SRx3JiZOCwiKGCP4ccCM7eGEi5bAG++8yrTADbm9TB90/0z5pYQKacqLHkwMUf+vTSrJaGgLjFCMXL8IMZBhea7+WHSTWUblbnXsyMChM5jJw0aYAwNILZTk9LpDp7fJxPGfSPTiM
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f9c6a0f-9e9e-401f-635b-08d660545347
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Dec 2018 17:07:40.8259 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4869
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGbG9WjfBQTDG4OkESYv3P24yWly6eJbJ gcljyZKfTB6Lpj5jDGCK4rJJSc3JLEst0rdL4Mp4/OwKc8F9jYqG9ZMZGxh/KXQxcnJICJhI 9Lb9Zuli5OIQEjjCKDH1+1c2COcbo8SCRTegMkuYJM5+nQWWYRGYwCyxa+09ZojMJCaJiydf sYAMExJ4xCjRtDATxGYTsJC4+aMRqIODQ0QgQmJvWwFIWFggSOJpw25GEFtEIFji/89dTBC2 nsTLGdPAbBYBVYm/b/vAbF6BGIkru7ZB7WpllJh/vRsswSggK3H/+z2wvcwC4hK3nsxngnhI QGLJnvPMELaoxMvH/1gh6hMlbjQ+hapRkLj/azJUjazEpfndjCALJASusUkcO3adESKhK/Fh 6lSoIl+Jf3MnskEUXWCUWHR+BytEQkuicd9Hdgg7W2LyrHtQzXISq3ofskA0nGeW2HZ1Mzso KCQEZCT615VD1HxmlXi6xnoCo94sJE9A2DoSC3Z/YoOwtSWWLXzNPAscGoISJ2c+YVnAyLKK UbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzB1HNzy22AH48vnjocYBTgYlXh4XYApRYg1say4 MvcQowQHs5II7xYtoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHeP0JAKYH0xJLU7NTUgtQimCwT B6dUA+Ns5sOOTJcVuf3fy/7wbyybKHaXr+NR9cWfdyZ5/D73wLtGpibswdebVhYvQqRnXLn0 i2dl7GI9tTCDS+1sfruimI4nZ+5Z92jJ1BiZyYfY+O69StPTWM5/7cKdn2+cTXZef/NwLlcc z9LOd5OZJ5jvrfUU4WkVWLj6GM9mwVkMLHVv+57uzhFUYinOSDTUYi4qTgQAX9EFtBkDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/vOcQveJnORBgBtgOdI6Y6kcP8Po>
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2018 17:07:49 -0000

Hi,=0A=
=0A=
Looking at the changes.=0A=
=0A=
Section 7.1.1:=0A=
Regarding: c=3DIN IP4 233.252.0.1/127=0A=
Isn't keeping it as an unicast address a better approach here?=0A=
=0A=
Note that https://tools.ietf.org/html/rfc5737 do have unicast ranges=0A=
which you can pick an address from.=0A=
=0A=
I don't think there are any issues in itself with having a multicast=0A=
address here. However, people may get ideas, especially with both 7.1.1=0A=
and 7.1.2 using multicast.=0A=
=0A=
Otherwise it appears that you have addressed those ID-nits you need to=0A=
address.=0A=
=0A=
Cheers=0A=
=0A=
Magnus=0A=
=0A=
=0A=
On 2018-12-11 20:02, Giridhar Mandyam wrote:=0A=
> Please note that I cleared out as many nits as I thought made sense.  Cur=
rent nit check showed zero errors, but a few warnings and comments.  I also=
 updated the avtext-rid reference.=0A=
>=0A=
> I modified the abstract slightly as inclusion of references violated RFC =
7322, Sec. 4.3.   As a result, I removed those references from the abstract=
 and added a sentence in the Introduction that provided the references.=0A=
>=0A=
> -Giri Mandyam=0A=
>=0A=
> -----Original Message-----=0A=
> From: payload <payload-bounces@ietf.org> On Behalf Of internet-drafts@iet=
f.org=0A=
> Sent: Tuesday, December 11, 2018 10:56 AM=0A=
> To: i-d-announce@ietf.org=0A=
> Cc: payload@ietf.org=0A=
> Subject: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.=
txt=0A=
>=0A=
>=0A=
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.=0A=
> This draft is a work item of the Audio/Video Transport Payloads WG of the=
 IETF.=0A=
>=0A=
>         Title           : RTP Payload Format for Flexible Forward Error C=
orrection (FEC)=0A=
>         Authors         : Mo Zanaty=0A=
>                           Varun Singh=0A=
>                           Ali Begen=0A=
>                           Giridhar Mandyam=0A=
> 	Filename        : draft-ietf-payload-flexible-fec-scheme-13.txt=0A=
> 	Pages           : 41=0A=
> 	Date            : 2018-12-11=0A=
>=0A=
> Abstract:=0A=
>    This document defines new RTP payload formats for the Forward Error=0A=
>    Correction (FEC) packets that are generated by the non-interleaved=0A=
>    and interleaved parity codes from source media encapsulated in RTP.=0A=
>    These parity codes are systematic codes, where a number of FEC repair=
=0A=
>    packets are generated from a set of source packets from one or more=0A=
>    source RTP streams.  These FEC repair packets are sent in a=0A=
>    redundancy RTP stream separate from the source RTP stream(s) that=0A=
>    carries the source packets.  RTP source packets that were lost in=0A=
>    transmission can be reconstructed using the source and repair packets=
=0A=
>    that were received.  The non-interleaved and interleaved parity codes=
=0A=
>    which are defined in this specification offer a good protection=0A=
>    against random and bursty packet losses, respectively, at a cost of=0A=
>    decent complexity.  The RTP payload formats that are defined in this=
=0A=
>    document address scalability issues experienced with the earlier=0A=
>    specifications, and offer several improvements.  Due to these=0A=
>    changes, the new payload formats are not backward compatible with=0A=
>    earlier specifications, but endpoints that do not implement this=0A=
>    specification can still work by simply ignoring the FEC repair=0A=
>    packets.=0A=
>=0A=
>=0A=
> The IETF datatracker status page for this draft is:=0A=
> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/=
=0A=
>=0A=
> There are also htmlized versions available at:=0A=
> https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-13=0A=
> https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-sch=
eme-13=0A=
>=0A=
> A diff from the previous version is available at:=0A=
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-flexible-fec-schem=
e-13=0A=
>=0A=
>=0A=
> Please note that it may take a couple of minutes from the time of submiss=
ion until the htmlized version and diff are available at tools.ietf.org.=0A=
>=0A=
> Internet-Drafts are also available by anonymous FTP at:=0A=
> ftp://ftp.ietf.org/internet-drafts/=0A=
>=0A=
> _______________________________________________=0A=
> payload mailing list=0A=
> payload@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/payload=0A=
>=0A=
> _______________________________________________=0A=
> payload mailing list=0A=
> payload@ietf.org=0A=
> https://www.ietf.org/mailman/listinfo/payload=0A=
>=0A=
=0A=
-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Wed Dec 12 10:41:01 2018
Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5AB0130EDB for <payload@ietfa.amsl.com>; Wed, 12 Dec 2018 10:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sglpyx6yOci6 for <payload@ietfa.amsl.com>; Wed, 12 Dec 2018 10:40:56 -0800 (PST)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E1B1311F9 for <payload@ietf.org>; Wed, 12 Dec 2018 10:40:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1544640056; x=1576176056; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6t7vafIN/bkro+aGkjLPT5Ds6kUlWFHj4IdBwixHvok=; b=p/6BY11Vbc/uF0iTVCasXtioW9AlwhDjH7QE5eWy0lqOFuuuXbmHxDIh yU3Hfag3EX8TrJEWY9UxGqY5Bk/mNe++n/UQGWehpek3HBWqPuqwF5p7V fv0smmi9rHjZ39v9BxsYbhMlPFajPLZICONUoXlxMHV/jWTpD1fKmd/N2 0=;
X-IronPort-AV: E=Sophos;i="5.56,345,1539673200"; d="scan'208";a="20194255"
Received: from unknown (HELO ironmsg02-sd.qualcomm.com) ([10.53.140.142]) by alexa-out-sd-02.qualcomm.com with ESMTP; 12 Dec 2018 10:40:55 -0800
Received: from nasanexm01g.na.qualcomm.com ([10.85.0.33]) by ironmsg02-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 12 Dec 2018 10:40:55 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01G.na.qualcomm.com (10.85.0.33) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 10:40:55 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Wed, 12 Dec 2018 10:40:55 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
Thread-Index: AQHUkYNOwBwcl0RgWUyBftJvM248iKV7Y5tw
Date: Wed, 12 Dec 2018 18:40:54 +0000
Message-ID: <92c0d62b5233440391e75ce5b9056016@NASANEXM01C.na.qualcomm.com>
References: <154455457454.13143.14509030085765652926@ietfa.amsl.com> <d47f7a5e86374769b38b361ada051036@NASANEXM01C.na.qualcomm.com> <DB7PR07MB49880261F6563E347598DF6A95A70@DB7PR07MB4988.eurprd07.prod.outlook.com>
In-Reply-To: <DB7PR07MB49880261F6563E347598DF6A95A70@DB7PR07MB4988.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/uDMO5bp2edlKX8ZPAPZiKBF4nIk>
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Dec 2018 18:41:00 -0000

> Isn't keeping it as an unicast address a better approach here?

2 reasons:

a) I didn't see a particular reason to have 2 different addresses in the ex=
amples.

b) The repair window in the example of Sec. 7.1.1 was small compared to the=
 example in Sec. 7.1.2, which seems appropriate for live media over multica=
st.  Therefore I felt that a multicast delivery address could be appropriat=
e.   {I did consider using localhost for the address (127.0.0.1), so as to =
provide a unicast address example that could represent an RTP proxy that in=
termediates between a multicast source and unicast receiver.  But this may =
imply restricted use of FLEX FEC as well, which is not desirable either.}

I can change one of the examples to something like 192.0.2.0/24, but I wond=
er if Sec. 7.1.2 may be more appropriate than 7.1.1.

-Giri

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund@ericsson.com>=20
Sent: Wednesday, December 12, 2018 9:08 AM
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
3.txt

Hi,

Looking at the changes.

Section 7.1.1:
Regarding: c=3DIN IP4 233.252.0.1/127
Isn't keeping it as an unicast address a better approach here?

Note that https://tools.ietf.org/html/rfc5737 do have unicast ranges which =
you can pick an address from.

I don't think there are any issues in itself with having a multicast addres=
s here. However, people may get ideas, especially with both 7.1.1 and 7.1.2=
 using multicast.

Otherwise it appears that you have addressed those ID-nits you need to addr=
ess.

Cheers

Magnus


On 2018-12-11 20:02, Giridhar Mandyam wrote:
> Please note that I cleared out as many nits as I thought made sense.  Cur=
rent nit check showed zero errors, but a few warnings and comments.  I also=
 updated the avtext-rid reference.
>
> I modified the abstract slightly as inclusion of references violated RFC =
7322, Sec. 4.3.   As a result, I removed those references from the abstract=
 and added a sentence in the Introduction that provided the references.
>
> -Giri Mandyam
>
> -----Original Message-----
> From: payload <payload-bounces@ietf.org> On Behalf Of=20
> internet-drafts@ietf.org
> Sent: Tuesday, December 11, 2018 10:56 AM
> To: i-d-announce@ietf.org
> Cc: payload@ietf.org
> Subject: [payload] I-D Action:=20
> draft-ietf-payload-flexible-fec-scheme-13.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Audio/Video Transport Payloads WG of the=
 IETF.
>
>         Title           : RTP Payload Format for Flexible Forward Error C=
orrection (FEC)
>         Authors         : Mo Zanaty
>                           Varun Singh
>                           Ali Begen
>                           Giridhar Mandyam
> 	Filename        : draft-ietf-payload-flexible-fec-scheme-13.txt
> 	Pages           : 41
> 	Date            : 2018-12-11
>
> Abstract:
>    This document defines new RTP payload formats for the Forward Error
>    Correction (FEC) packets that are generated by the non-interleaved
>    and interleaved parity codes from source media encapsulated in RTP.
>    These parity codes are systematic codes, where a number of FEC repair
>    packets are generated from a set of source packets from one or more
>    source RTP streams.  These FEC repair packets are sent in a
>    redundancy RTP stream separate from the source RTP stream(s) that
>    carries the source packets.  RTP source packets that were lost in
>    transmission can be reconstructed using the source and repair packets
>    that were received.  The non-interleaved and interleaved parity codes
>    which are defined in this specification offer a good protection
>    against random and bursty packet losses, respectively, at a cost of
>    decent complexity.  The RTP payload formats that are defined in this
>    document address scalability issues experienced with the earlier
>    specifications, and offer several improvements.  Due to these
>    changes, the new payload formats are not backward compatible with
>    earlier specifications, but endpoints that do not implement this
>    specification can still work by simply ignoring the FEC repair
>    packets.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-schem
> e/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-13
> https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-
> scheme-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-flexible-fec-sche
> me-13
>
>
> Please note that it may take a couple of minutes from the time of submiss=
ion until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>

--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------


From nobody Wed Dec 12 22:52:11 2018
Return-Path: <roni.even@huawei.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADB712875B for <payload@ietfa.amsl.com>; Wed, 12 Dec 2018 22:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sOfvwWWETZE for <payload@ietfa.amsl.com>; Wed, 12 Dec 2018 22:52:00 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7BB12F1AB for <payload@ietf.org>; Wed, 12 Dec 2018 22:51:59 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 37122EE9C4174; Thu, 13 Dec 2018 06:51:56 +0000 (GMT)
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 13 Dec 2018 06:51:57 +0000
Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.124]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Thu, 13 Dec 2018 14:51:51 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "payload@ietf.org" <payload@ietf.org>, Giridhar Mandyam <mandyam@qti.qualcomm.com>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
Thread-Index: AQHUkYNOv149ErSWI0aQKBTwcm8kJ6V660oAgAFRybA=
Date: Thu, 13 Dec 2018 06:51:51 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18C911AF@DGGEMM506-MBX.china.huawei.com>
References: <154455457454.13143.14509030085765652926@ietfa.amsl.com> <d47f7a5e86374769b38b361ada051036@NASANEXM01C.na.qualcomm.com> <DB7PR07MB49880261F6563E347598DF6A95A70@DB7PR07MB4988.eurprd07.prod.outlook.com> <92c0d62b5233440391e75ce5b9056016@NASANEXM01C.na.qualcomm.com>
In-Reply-To: <92c0d62b5233440391e75ce5b9056016@NASANEXM01C.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.200.202.156]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/X8_mRf13Rkbe8vW2z7maHCSERc4>
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 06:52:03 -0000

Magnus,
Is it OK to have the multicast address and can I send the document to publi=
cation?

Regards
Roni
-----Original Message-----
From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Giridhar Mandy=
am
Sent: Wednesday, December 12, 2018 8:41 PM
To: Magnus Westerlund; payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
3.txt

> Isn't keeping it as an unicast address a better approach here?

2 reasons:

a) I didn't see a particular reason to have 2 different addresses in the ex=
amples.

b) The repair window in the example of Sec. 7.1.1 was small compared to the=
 example in Sec. 7.1.2, which seems appropriate for live media over multica=
st.  Therefore I felt that a multicast delivery address could be appropriat=
e.   {I did consider using localhost for the address (127.0.0.1), so as to =
provide a unicast address example that could represent an RTP proxy that in=
termediates between a multicast source and unicast receiver.  But this may =
imply restricted use of FLEX FEC as well, which is not desirable either.}

I can change one of the examples to something like 192.0.2.0/24, but I wond=
er if Sec. 7.1.2 may be more appropriate than 7.1.1.

-Giri

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Sent: Wednesday, December 12, 2018 9:08 AM
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; payload@ietf.org
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-1=
3.txt

Hi,

Looking at the changes.

Section 7.1.1:
Regarding: c=3DIN IP4 233.252.0.1/127
Isn't keeping it as an unicast address a better approach here?

Note that https://tools.ietf.org/html/rfc5737 do have unicast ranges which =
you can pick an address from.

I don't think there are any issues in itself with having a multicast addres=
s here. However, people may get ideas, especially with both 7.1.1 and 7.1.2=
 using multicast.

Otherwise it appears that you have addressed those ID-nits you need to addr=
ess.

Cheers

Magnus


On 2018-12-11 20:02, Giridhar Mandyam wrote:
> Please note that I cleared out as many nits as I thought made sense.  Cur=
rent nit check showed zero errors, but a few warnings and comments.  I also=
 updated the avtext-rid reference.
>
> I modified the abstract slightly as inclusion of references violated RFC =
7322, Sec. 4.3.   As a result, I removed those references from the abstract=
 and added a sentence in the Introduction that provided the references.
>
> -Giri Mandyam
>
> -----Original Message-----
> From: payload <payload-bounces@ietf.org> On Behalf Of=20
> internet-drafts@ietf.org
> Sent: Tuesday, December 11, 2018 10:56 AM
> To: i-d-announce@ietf.org
> Cc: payload@ietf.org
> Subject: [payload] I-D Action:=20
> draft-ietf-payload-flexible-fec-scheme-13.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories.
> This draft is a work item of the Audio/Video Transport Payloads WG of the=
 IETF.
>
>         Title           : RTP Payload Format for Flexible Forward Error C=
orrection (FEC)
>         Authors         : Mo Zanaty
>                           Varun Singh
>                           Ali Begen
>                           Giridhar Mandyam
> 	Filename        : draft-ietf-payload-flexible-fec-scheme-13.txt
> 	Pages           : 41
> 	Date            : 2018-12-11
>
> Abstract:
>    This document defines new RTP payload formats for the Forward Error
>    Correction (FEC) packets that are generated by the non-interleaved
>    and interleaved parity codes from source media encapsulated in RTP.
>    These parity codes are systematic codes, where a number of FEC repair
>    packets are generated from a set of source packets from one or more
>    source RTP streams.  These FEC repair packets are sent in a
>    redundancy RTP stream separate from the source RTP stream(s) that
>    carries the source packets.  RTP source packets that were lost in
>    transmission can be reconstructed using the source and repair packets
>    that were received.  The non-interleaved and interleaved parity codes
>    which are defined in this specification offer a good protection
>    against random and bursty packet losses, respectively, at a cost of
>    decent complexity.  The RTP payload formats that are defined in this
>    document address scalability issues experienced with the earlier
>    specifications, and offer several improvements.  Due to these
>    changes, the new payload formats are not backward compatible with
>    earlier specifications, but endpoints that do not implement this
>    specification can still work by simply ignoring the FEC repair
>    packets.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-schem
> e/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-13
> https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-
> scheme-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-flexible-fec-sche
> me-13
>
>
> Please note that it may take a couple of minutes from the time of submiss=
ion until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload
>

--=20

Magnus Westerlund=20

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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


From nobody Thu Dec 13 03:49:38 2018
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8A3130FC5 for <payload@ietfa.amsl.com>; Thu, 13 Dec 2018 03:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.761
X-Spam-Level: 
X-Spam-Status: No, score=-5.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SdmFyRx/; dkim=pass (1024-bit key) header.d=ericsson.com header.b=dc5ilGhS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CSQCFTA40xV for <payload@ietfa.amsl.com>; Thu, 13 Dec 2018 03:49:25 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CA5130FC2 for <payload@ietf.org>; Thu, 13 Dec 2018 03:49:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1544701762; x=1547293762; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1CDQeHmz89wsBmGSlVFMvGZE5BFnbdD7JwvGUKHxakU=; b=SdmFyRx/7FI8X00VTyftDg4n2aFVRv7UQPoAZhSidSWf6pgzBpy1IzCIndtqMWEn QnO/OZZDKZsvuZvLSSvfaCgoooUZojtPd8q0osPNic4FUDHwgiO3fxDLU6qgp+vF nKb99FECSE13YM8ImHWulRjghtMLSmDPo6LDWF0J244=;
X-AuditID: c1b4fb2d-3c7e09e000007af1-55-5c12474275c1
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C8.5B.31473.247421C5; Thu, 13 Dec 2018 12:49:22 +0100 (CET)
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 13 Dec 2018 12:49:21 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 13 Dec 2018 12:49:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pm4NtMFygWMwr+wziANzWzMzig5r/KBmQBW7L4H55/Q=; b=dc5ilGhSHe3j0a28rjKmKpkwWXPHhKT0I3tmD3n2tDTdFfVem4iSvEZoof+G7VY6Jo0d1ck9roBBG8MTXDFxFCysKw0o0Ui1eJnUrjnZIovFPToFd1c8INTjoso7KlJRqdpFyeuYjXtC9DSM/ZY0rpw0+LG+3YAw99BWJultyXM=
Received: from DB7PR07MB4988.eurprd07.prod.outlook.com (20.178.42.222) by DB7PR07MB5835.eurprd07.prod.outlook.com (20.178.106.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.8; Thu, 13 Dec 2018 11:49:20 +0000
Received: from DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::f896:8ab3:3108:c686]) by DB7PR07MB4988.eurprd07.prod.outlook.com ([fe80::f896:8ab3:3108:c686%6]) with mapi id 15.20.1446.010; Thu, 13 Dec 2018 11:49:20 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "Roni Even (A)" <roni.even@huawei.com>
CC: "payload@ietf.org" <payload@ietf.org>, Giridhar Mandyam <mandyam@qti.qualcomm.com>
Thread-Topic: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
Thread-Index: AQHUkYNNPGC4Er/nT0KhreRKPYco/Q==
Date: Thu, 13 Dec 2018 11:49:20 +0000
Message-ID: <DB7PR07MB4988CC2EF7BA9AF9ABDA387C95A00@DB7PR07MB4988.eurprd07.prod.outlook.com>
References: <154455457454.13143.14509030085765652926@ietfa.amsl.com> <d47f7a5e86374769b38b361ada051036@NASANEXM01C.na.qualcomm.com> <DB7PR07MB49880261F6563E347598DF6A95A70@DB7PR07MB4988.eurprd07.prod.outlook.com> <92c0d62b5233440391e75ce5b9056016@NASANEXM01C.na.qualcomm.com> <6E58094ECC8D8344914996DAD28F1CCD18C911AF@DGGEMM506-MBX.china.huawei.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; 
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR07MB5835; 6:wTCTXmqlCAu/mk/ZW8xpy/x1CU85Sls9j6TgJXLVAT5GWUww+ImqAmTVmDE38E9H2Eqs7s9BswTGfF4rd/cud32Zu5rKAzzF6x+9jEbpktnSMhextZqobcJTjWEIFupxSzzcX9bFWeQ2OpfqP6JYhM9HpDzWb3IDw0a7wozFCQ+f7KZk6in44wtI25uFgrb6THdmdcVJSvNBtUsB0ESsGCHY265QXAj8Li/jkXwbumASJBatv7pqDeUPemtgm4JINGYCXtP0v0GE4adk88p/n2Diclylu9Ph5tajaBGZGCXYaGO462NZsNbabfjleZ/XWT3TsLdZMyGxSZioZ2i1vgTircKRBm8mMvYjxS+Jda5Botuc5WZwGDBr4wBguKhivHzTW//5Al8VPrFw5RVBnEY9mViUdUMGXkuoEz5GOvH5mSjcjbm7w2a/8o2O0q5EeKDttJd7dsWbnRZLiDWEng==; 5:cHbbKD/3zqTKdMXpQEKBYSmRff94W2hVnzJeMLu1sODvajS1+LAGxRtzsIAaDV2AhQmjduYysiKTYhCes8CeoPNNppqDJFByhXhfc1GDXzZZdQr0ElKd8dyw/+PPA9yJLrvaWfj0F7ZgMSn7gkhFuq7e2qHNM+aGbi1GGnkZctw=; 7:9/ZUII0swHmLVWsxiORpeQkDQhqy22+VWQ+msnOFh5vhykAwseSGQ0KM1sjZ+Qgl26ov7Li9ZEN09echdke9KH0PAxC4vtmtonuKoOxkWWbiSU0jXjbs9X00e5/i4x8Zg92Nn7FbK/vC3UY5K1r8TA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 9ef9de8b-f620-44e6-28e1-08d660f104e7
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB7PR07MB5835; 
x-ms-traffictypediagnostic: DB7PR07MB5835:
x-microsoft-antispam-prvs: <DB7PR07MB58356AE35021BD645AE72DB795A00@DB7PR07MB5835.eurprd07.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231475)(944501520)(52105112)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB5835; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB5835; 
x-forefront-prvs: 088552DE73
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(366004)(346002)(376002)(396003)(54094003)(13464003)(199004)(189003)(44832011)(486006)(106356001)(14454004)(105586002)(966005)(6116002)(3846002)(33656002)(25786009)(478600001)(446003)(476003)(305945005)(2906002)(99286004)(54906003)(74316002)(71190400001)(5660300001)(68736007)(71200400001)(86362001)(93886005)(14444005)(97736004)(8676002)(316002)(8936002)(81156014)(76176011)(7736002)(229853002)(4001150100001)(53546011)(6916009)(66066001)(9686003)(66574011)(6436002)(55016002)(4326008)(6306002)(53936002)(6246003)(26005)(7696005)(102836004)(186003)(6506007)(256004)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5835; H:DB7PR07MB4988.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 4nGtRLdxe9tGBonOwwnQBPDELj8jAu40vsK86a5XVjmUeIYgN86j/L5SrWFgkib5O9OEevaDiq/HD5v+X9NsBP//BrMA/lWs7sC4ZcP6YFQv0mPT16l8to0JTu2OobUOcmOqcYiWoK7qnCLeHJnKGm8AwhEsDTEDePA02zMalPMfhnFUns3b8p4LTAfd/82fCbGbvn5felWas3mw9xD6WFgnG2mHcprKofp4CiE87ZN/mby+TjN0S/2apdM17wRb0pNQIKP3RbjCvfSdJxJZ1NX5xP7z1MECPhp9BTlttm7/5siihntwLfgkf4CVHbCk
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9ef9de8b-f620-44e6-28e1-08d660f104e7
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Dec 2018 11:49:20.3765 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5835
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHO/fl1Rpcb4o/NC1GD1I3KysWZZYJShSEEogItfSmQ52yu0Tt wZQ0UiItJj5gPpomFkklabPSVET/0Om0UEOt+UhdD5MwtZG53Rv03+d7vt/z+55zODTO3ie9 aZVay2nUyhQp5UaUxTRflYVFsHH7HvcRiu8ro0hhGezDFEvdZuIEHnmz6ysZaTSuYpE1+ll0 Do91O5bApagyOE3Q8YtuSfapNip98EjmXNUgrkNWeQFypYE5CD3jvWQBcqNZpguBuSlXFMsI +rvnMUEYMXheP4scgmCKcCi/W4wLzj0MGqvnkCCsCNptOsIxmWIUMLqSQznYg/GHtjeNznWc iYHpLz24g7cyUTCja0VCJhrWV02YwHKYLy1xMsHsgsX2MtLBEiYOTM02sWwGg58rZheHgRhf mPw1IRZ4wdh0JSZcjwHjKzMusCfMT/0hhbwSRnJmxMwOsFuslMC+YKksdBYA856Cl0/zSMGQ waJeLw46C5a6ElIIDSBY+FEhTvIH2+t+MZQMhroqJLAfNNz5RAgbRnAwtg+IoW0wOVnvUoSC yv87ucCBUNW6RAkcAHXVNrzc+QTu0Fs2TVQhogF58hzPpyYeCJZzGlU8z6ep5WpO+wxtfJW3 Tb9lLeiR7WQHYmgk3SK5EcrGsaQyg89K7UBA41IPyVSsexwrSVBmZXOatAuaKykc34F8aELq JbGzGxaTqNRyyRyXzmn+uRjt6q1DR917P6sqz4cfpn0mdresV1yuOW3I1rzIVLnmHSo1KcZG hvMjoqzfij88YBq8fLOoKaL2nSH9Yyc9X0JtvrR9MeQhewa/FTwcqUcGz6iwtcyh+IUn9rVN ndcDAvdaTKFDIXv6dy7nhnfertGOz/rZU8NPFV6LXqaHZAp1LTmcLyX4JOV+f1zDK/8CopoW liYDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/7CplMSbf9ygc6ntC8F4qTA3FGks>
Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme-13.txt
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Dec 2018 11:49:37 -0000

On 2018-12-13 07:52, Roni Even (A) wrote:=0A=
> Magnus,=0A=
> Is it OK to have the multicast address and can I send the document to pub=
lication?=0A=
=0A=
Yes, it is. I don't think there are anything in this examples that are=0A=
not possible to work in multicast. It is just that I think a large part=0A=
of the usage of this specification will be in unicast.=0A=
=0A=
Cheers=0A=
=0A=
Magnus=0A=
=0A=
=0A=
=0A=
> Regards=0A=
> Roni=0A=
> -----Original Message-----=0A=
> From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Giridhar Man=
dyam=0A=
> Sent: Wednesday, December 12, 2018 8:41 PM=0A=
> To: Magnus Westerlund; payload@ietf.org=0A=
> Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme=
-13.txt=0A=
>=0A=
>> Isn't keeping it as an unicast address a better approach here?=0A=
> 2 reasons:=0A=
>=0A=
> a) I didn't see a particular reason to have 2 different addresses in the =
examples.=0A=
>=0A=
> b) The repair window in the example of Sec. 7.1.1 was small compared to t=
he example in Sec. 7.1.2, which seems appropriate for live media over multi=
cast.  Therefore I felt that a multicast delivery address could be appropri=
ate.   {I did consider using localhost for the address (127.0.0.1), so as t=
o provide a unicast address example that could represent an RTP proxy that =
intermediates between a multicast source and unicast receiver.  But this ma=
y imply restricted use of FLEX FEC as well, which is not desirable either.}=
=0A=
>=0A=
> I can change one of the examples to something like 192.0.2.0/24, but I wo=
nder if Sec. 7.1.2 may be more appropriate than 7.1.1.=0A=
>=0A=
> -Giri=0A=
>=0A=
> -----Original Message-----=0A=
> From: Magnus Westerlund <magnus.westerlund@ericsson.com>=0A=
> Sent: Wednesday, December 12, 2018 9:08 AM=0A=
> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; payload@ietf.org=0A=
> Subject: Re: [payload] I-D Action: draft-ietf-payload-flexible-fec-scheme=
-13.txt=0A=
>=0A=
> Hi,=0A=
>=0A=
> Looking at the changes.=0A=
>=0A=
> Section 7.1.1:=0A=
> Regarding: c=3DIN IP4 233.252.0.1/127=0A=
> Isn't keeping it as an unicast address a better approach here?=0A=
>=0A=
> Note that https://tools.ietf.org/html/rfc5737 do have unicast ranges whic=
h you can pick an address from.=0A=
>=0A=
> I don't think there are any issues in itself with having a multicast addr=
ess here. However, people may get ideas, especially with both 7.1.1 and 7.1=
.2 using multicast.=0A=
>=0A=
> Otherwise it appears that you have addressed those ID-nits you need to ad=
dress.=0A=
>=0A=
> Cheers=0A=
>=0A=
> Magnus=0A=
>=0A=
>=0A=
> On 2018-12-11 20:02, Giridhar Mandyam wrote:=0A=
>> Please note that I cleared out as many nits as I thought made sense.  Cu=
rrent nit check showed zero errors, but a few warnings and comments.  I als=
o updated the avtext-rid reference.=0A=
>>=0A=
>> I modified the abstract slightly as inclusion of references violated RFC=
 7322, Sec. 4.3.   As a result, I removed those references from the abstrac=
t and added a sentence in the Introduction that provided the references.=0A=
>>=0A=
>> -Giri Mandyam=0A=
>>=0A=
>> -----Original Message-----=0A=
>> From: payload <payload-bounces@ietf.org> On Behalf Of =0A=
>> internet-drafts@ietf.org=0A=
>> Sent: Tuesday, December 11, 2018 10:56 AM=0A=
>> To: i-d-announce@ietf.org=0A=
>> Cc: payload@ietf.org=0A=
>> Subject: [payload] I-D Action: =0A=
>> draft-ietf-payload-flexible-fec-scheme-13.txt=0A=
>>=0A=
>>=0A=
>> A New Internet-Draft is available from the on-line Internet-Drafts direc=
tories.=0A=
>> This draft is a work item of the Audio/Video Transport Payloads WG of th=
e IETF.=0A=
>>=0A=
>>         Title           : RTP Payload Format for Flexible Forward Error =
Correction (FEC)=0A=
>>         Authors         : Mo Zanaty=0A=
>>                           Varun Singh=0A=
>>                           Ali Begen=0A=
>>                           Giridhar Mandyam=0A=
>> 	Filename        : draft-ietf-payload-flexible-fec-scheme-13.txt=0A=
>> 	Pages           : 41=0A=
>> 	Date            : 2018-12-11=0A=
>>=0A=
>> Abstract:=0A=
>>    This document defines new RTP payload formats for the Forward Error=
=0A=
>>    Correction (FEC) packets that are generated by the non-interleaved=0A=
>>    and interleaved parity codes from source media encapsulated in RTP.=
=0A=
>>    These parity codes are systematic codes, where a number of FEC repair=
=0A=
>>    packets are generated from a set of source packets from one or more=
=0A=
>>    source RTP streams.  These FEC repair packets are sent in a=0A=
>>    redundancy RTP stream separate from the source RTP stream(s) that=0A=
>>    carries the source packets.  RTP source packets that were lost in=0A=
>>    transmission can be reconstructed using the source and repair packets=
=0A=
>>    that were received.  The non-interleaved and interleaved parity codes=
=0A=
>>    which are defined in this specification offer a good protection=0A=
>>    against random and bursty packet losses, respectively, at a cost of=
=0A=
>>    decent complexity.  The RTP payload formats that are defined in this=
=0A=
>>    document address scalability issues experienced with the earlier=0A=
>>    specifications, and offer several improvements.  Due to these=0A=
>>    changes, the new payload formats are not backward compatible with=0A=
>>    earlier specifications, but endpoints that do not implement this=0A=
>>    specification can still work by simply ignoring the FEC repair=0A=
>>    packets.=0A=
>>=0A=
>>=0A=
>> The IETF datatracker status page for this draft is:=0A=
>> https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-schem=
=0A=
>> e/=0A=
>>=0A=
>> There are also htmlized versions available at:=0A=
>> https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-13=0A=
>> https://datatracker.ietf.org/doc/html/draft-ietf-payload-flexible-fec-=
=0A=
>> scheme-13=0A=
>>=0A=
>> A diff from the previous version is available at:=0A=
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-flexible-fec-sche=
=0A=
>> me-13=0A=
>>=0A=
>>=0A=
>> Please note that it may take a couple of minutes from the time of submis=
sion until the htmlized version and diff are available at tools.ietf.org.=
=0A=
>>=0A=
>> Internet-Drafts are also available by anonymous FTP at:=0A=
>> ftp://ftp.ietf.org/internet-drafts/=0A=
>>=0A=
>> _______________________________________________=0A=
>> payload mailing list=0A=
>> payload@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/payload=0A=
>>=0A=
>> _______________________________________________=0A=
>> payload mailing list=0A=
>> payload@ietf.org=0A=
>> https://www.ietf.org/mailman/listinfo/payload=0A=
>>=0A=
=0A=
-- =0A=
=0A=
Magnus Westerlund =0A=
=0A=
----------------------------------------------------------------------=0A=
Network Architecture & Protocols, Ericsson Research=0A=
----------------------------------------------------------------------=0A=
Ericsson AB                 | Phone  +46 10 7148287=0A=
Torshamnsgatan 23           | Mobile +46 73 0949079=0A=
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A=
----------------------------------------------------------------------=0A=
=0A=


From nobody Fri Dec 14 22:43:40 2018
Return-Path: <ron.even.tlv@gmail.com>
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5C0128CF3; Fri, 14 Dec 2018 22:43:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Roni Even <ron.even.tlv@gmail.com>
To: <ben@nostrum.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: iesg-secretary@ietf.org, roni.even@mail01.huawei.com, payload-chairs@ietf.org, Roni Even <roni.even@huawei.com>, payload@ietf.org
Message-ID: <154485621837.30654.14670313520130395622.idtracker@ietfa.amsl.com>
Date: Fri, 14 Dec 2018 22:43:38 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/brm7riGJNce3pCm8BvS-zKZItVI>
Subject: [payload] Publication has been requested for draft-ietf-payload-flexible-fec-scheme-13
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Dec 2018 06:43:39 -0000

Roni Even has requested publication of draft-ietf-payload-flexible-fec-scheme-13 as Proposed Standard on behalf of the PAYLOAD working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-payload-flexible-fec-scheme/


From nobody Tue Dec 18 21:00:55 2018
Return-Path: <ben@nostrum.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0B1276D0; Tue, 18 Dec 2018 21:00:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level: 
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMos3dYTjmGF; Tue, 18 Dec 2018 21:00:52 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EF312F1A5; Tue, 18 Dec 2018 21:00:49 -0800 (PST)
Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wBJ50iQl011795 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 18 Dec 2018 23:00:48 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1545195648; bh=9OlWFm/uGcf9ppxJ+WygsI2BIwjKsQCjqKKFrkW/k2E=; h=From:Subject:Date:Cc:To; b=CzXunuuK3cwosp/wS4G8R5aqOQj5mPqyJVx9wqyuvwOKLEY1rQvhCKnl/b8n7ebb0 qQ3+Ww09KYceqYLfdm/Kbk/IxL0DW8GGP6eOOB9iokPou9pj31v7D+/n0qNJb5oU6H rw1PIScj6nQTLUUkPrgLtsLmj+vht9jNZ296SnEU=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45]
From: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_DD09E9A0-C180-43EB-8DE2-43167BA9511D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Message-Id: <3462BDFF-84C6-4FE5-857D-50B457AF15FE@nostrum.com>
Date: Tue, 18 Dec 2018 23:00:43 -0600
Cc: payload@ietf.org
To: draft-ietf-payload-flexible-fec-scheme.all@ietf.org
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/tT4lQ_oVsDWuRmcFn7OImwy87oo>
Subject: [payload] AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 05:00:55 -0000

--Apple-Mail=_DD09E9A0-C180-43EB-8DE2-43167BA9511D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

This is my AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13.

The document is overall in pretty good shape. It=E2=80=99s more readable =
than I expected, given the subject matter. I would like to discuss my =
substantive comments/questions prior to IETF LC.

Thanks!

Ben.

*** Substantive***

General: Do I read correctly that this document can completely stand =
alone from RFC 6363? That is, the calculation of the protection stream =
and reconstruction of lost source packets is completely specified in =
this document? I don=E2=80=99t see that as a problem, but if it=E2=80=99s =
correct some introduction text to that effect would be helpful. Is a =
normative reference to 6363 even needed?

 If that=E2=80=99s _not_ the intent, then we need some discussion about =
where I went wrong in reading it.

=C2=A72: Unless there=E2=80=99s a strong reason otherwise, please use =
the updated key word boilerplate from RFC 8174.

=C2=A74.2: "The FEC repair packets MUST contain information that =
identifies the
source block...=E2=80=9D: The MUST seems more like a statement of fact =
than a normative requirement.

=C2=A74.2.1:

- There=E2=80=99s a number of 2119/8174 keywords in this section that =
seem more natural consequences of using RTP than new normative =
requirements. If that is the case, they shouldn=E2=80=99t use normative =
keywords unless in the form of direct quotes.

- 10th paragraph: "The repair streams=E2=80=99 SSRC=E2=80=99s CNAME =
SHOULD be
identical to the CNAME of the source RTP stream(s) that this
repair stream protects.=E2=80=9D
Why is the SHOULD not a MUST? What happens if it is violated?


- 11th paragraph: "such
scenarios, using the same CNAME for the source and repair RTP
streams means that the RTP Source and the FEC Source MUST share
the same CNAME (for this specific source-repair stream
association).=E2=80=9D

That MUST seems like a statement of fact.

=C2=A74.2.2: Please add a short explanation of why we need two different =
FEC packet formats. (Not counting the retransmission packet; the =
reasoning there is pretty obvious.)

=C2=A75.1.1 (and subsequent media type definitions)

- Please consider using the IESG (iesg@ietf.org) as the contact for =
further information. Working groups come and go, and authors change =
jobs. But someone on the IESG should (hopefully) always be able to find =
the right person,

- Change control:  In 5.1.1, shouldn=E2=80=99t that be the PAYLOAD =
working group (or it=E2=80=99s successor as delegated by the IESG...)

- Are these registrations really intended to be provisional?

=C2=A75.2.1, last bullet: "Any unknown option in the offer MUST be =
ignored and deleted from
the answer.=E2=80=9D: Is that a a new requirement specific to flex-fec, =
or just a normal offer/answer requirement?

=C2=A76.3.1.1, last paragraph: This is the only mention of =
=E2=80=9Cstaircase=E2=80=9D in the draft. Please add or cite a =
definition.

=C2=A78:
- "the potential impacts of using FEC MUST be considered=E2=80=9D is =
vague for a MUST. Who/what does this apply to? Is the implementor =
expected to know in advance whether their implementation will be used in =
a congestion-prone network? (If that is the intent, I suggest =
non-normative guidance.)
- =E2=80=9CIn a network-friendly implementation=E2=80=9D: Do you expect =
to see network-unfriendly implementations? Is that okay?

=C2=A79, last paragraph: What are the security implications of unused =
source-buffers? Is this a potential DoS vector?


*** Editorial ***

- Abstract: I=E2=80=99m not sure how to interpret the phrase =E2=80=9Cdece=
nt complexity=E2=80=9D. How much complexity qualifies as =E2=80=9Cdecent=E2=
=80=9D?

=C2=A71,

- first paragraph: Please add  or cite a definition for FEC. I=E2=80=99m =
not sure all readers will understand it the same way the authors do. (I =
was personally surprised to find discussion about reacting to feedback, =
since I thought of FEC as something used when no feedback channel was =
available.)

- 2nd paragraph: s/Redunadncy/Redundancy=E2=80=9D

=C2=A71.1.1:

- It would be helpful to describe what L and D represent here, or at =
least give a forward reference to the definition. (I note that a lot of =
text goes by before you get to the  definitions or the 2119 =
boilerplate.)

- Does 1-D and later 2-D stand for =E2=80=9Cone dimensional=E2=80=9D and =
=E2=80=9Ctwo dimensional=E2=80=9D? If so, please expand  both first =
mention. (As it was, I got a bit confused by trying to conflate the =
=E2=80=9CD=E2=80=9D in =E2=80=9C1-D=E2=80=9D with the =E2=80=9CD=E2=80=9D =
in =E2=80=9CLxD=E2=80=9D.)

=C2=A71.1.5:
- "assuming that each repair packet carries an equal
number of bytes carried by a source packet,=E2=80=9D
s/ =E2=80=9Cbytes carried=E2=80=9D/=E2=80=9Cbytes as carried=E2=80=9D

=C2=A74.2, last paragraph: Missing article before =E2=80=98Repair =
=E2=80=9CPayload=E2=80=9D =E2=80=98

=C2=A74.2.2, paragraph after Figure 10:
The text seems to be suggest there is one source packet protected by a =
given repair packet. IIUC, that=E2=80=99s not the case; a given FEC =
packet protects several source packets, doesn=E2=80=99t it?

=C2=A75.2, first paragraph: s/ "Applications that are using RTP =
transport=E2=80=9D / =E2=80=9CApplications that use the RTP transport=E2=80=
=9D

=C2=A75.2.1, first bullet: I don=E2=80=99t know how to interpret =
=E2=80=9CSHOULD normally=E2=80=9D.

=C2=A75.2.2, first paragraph: Is there a reason to cite the obsolete RFC =
2326?

=C2=A76.3.3:
- list item 2: "The padding of octet 0 MUST be added at
the end of the bit string.=E2=80=9D: I assume that means =E2=80=9Cpadded =
with zeros=E2=80=9D, but it could be interpreted to mean =E2=80=9Cpad =
the zeroth byte=E2=80=9D.

- list item 5: Should =E2=80=9Cnum_recovered_until_this_iteration=E2=80=9D=
 say =E2=80=9Cbefore_this_iteration=E2=80=9D?

=C2=A79, last paragraph: I don=E2=80=99t understand the intent of the =
last sentence.






--Apple-Mail=_DD09E9A0-C180-43EB-8DE2-43167BA9511D
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwZ0HsACgkQgFZKbJXz
1A2FWw/+Lkwek9hGwSHtW/FLSpNLZyw/uEpQsg/vx8Lg18Da94KYRLQ4+sfRYboV
iprBybzvfEgrGApqqmbajo+MBQ5Cg+iYdd6OgGCy0YWwHMDYsAbvTn7UTzBbrYk7
UkCN2zUxoKQH2RWcXYqMxIkcgnNhcwqetB37YKlic8BjuvMMGeO7w9YNp4nEdNb5
BNs5l+q3xGtYlULCnTMiPBk36x6PPc84stgFO11Tc9E5N+ZPJ5GJFtYVZqkoOPS+
PK8prCK+R6NkVdoap0arNjna/bDUXfpt68zgzZgqk4se6+4N/JpUSmKrfmBr3xXO
HJPLaOjmFiZULTun1BbqNdFeBQQJRs+c4vCLQShcaM2DGUgp+805JP7yw0MLUGNy
OOVCn+Mvoy3kM87/BNgwzIr/FGrx4NTT2cNVjIN9G7j2KtG1uBSLh7vqbkAKfIbE
mDvr+limV/NygYm63tc6gks4Gv2SvY8aO9jf51sRW9p6Vl5qnFMKx/D7KEpshTmB
/uiNlizELjcv9MNdHZXCwG34i8Dk9t5blqRlLqMzbRMDf10vUT/1JZYibZ1kIyq7
WSbR31mUO72LB4QjBdQUQoTMi7Q9MfOml+wUnVvZeKnTlL8CVlCxFTuh1awGc1/4
TN/PZ/p6K3ErrOvkPzptlhQhDky8N//1sYtXeMzcsPHFZwFYf60=
=hN5R
-----END PGP SIGNATURE-----

--Apple-Mail=_DD09E9A0-C180-43EB-8DE2-43167BA9511D--


From nobody Sat Dec 22 17:38:54 2018
Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6B4130DC9; Sat, 22 Dec 2018 17:38:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level: 
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSS-ng3q7lNW; Sat, 22 Dec 2018 17:38:50 -0800 (PST)
Received: from alexa-out-sd-02.qualcomm.com (alexa-out-sd-02.qualcomm.com [199.106.114.39]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08987129AB8; Sat, 22 Dec 2018 17:38:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1545529130; x=1577065130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RN6Di7hXvTW0LQ/CCvfm2yCLtMhSrDUtTujFjjyPKeA=; b=IkokObPtveEjpgdPDiUoTxjmZK1miDgmGdr1ZbxORqhnfF6lamUVZ4bC UJ6kM/IjhpOswIx/7Dc6keY6ffWWimz5GGUkv61F2Apm/loDjXWLJzHBr WHnajegkMKMbpJoEd73x0S3srbnxgyJVpLb9DR9yLywD62Cd8oc313FiE c=;
X-IronPort-AV: E=Sophos;i="5.56,386,1539673200"; d="scan'208";a="22225897"
Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by alexa-out-sd-02.qualcomm.com with ESMTP; 22 Dec 2018 17:38:48 -0800
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2018 17:38:47 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 22 Dec 2018 17:38:47 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Sat, 22 Dec 2018 17:38:47 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: Ben Campbell <ben@nostrum.com>, "draft-ietf-payload-flexible-fec-scheme.all@ietf.org" <draft-ietf-payload-flexible-fec-scheme.all@ietf.org>
CC: "payload@ietf.org" <payload@ietf.org>
Thread-Topic: AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13
Thread-Index: AQHUl1fULReBgVYI4UmKkArmKMKaIqWIRViA
Date: Sun, 23 Dec 2018 01:38:46 +0000
Message-ID: <485343397e554f97be3e0a5c9df8ef4d@NASANEXM01C.na.qualcomm.com>
References: <3462BDFF-84C6-4FE5-857D-50B457AF15FE@nostrum.com>
In-Reply-To: <3462BDFF-84C6-4FE5-857D-50B457AF15FE@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [199.106.107.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/vfiVlSDhj-WY985KJ4Kinmjzxds>
Subject: Re: [payload] AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Dec 2018 01:38:53 -0000

VGhhbmsgeW91IGZvciB0aGUgY2FyZWZ1bCByZXZpZXcuICBCZWZvcmUgc3VibWl0dGluZyByZXYg
MTQsIEkgd291bGQgbGlrZSB0byBnZXQgYWdyZWVtZW50IG9uIHRoZSBmb2xsb3dpbmcgcHJvcG9z
ZWQgY2hhbmdlcy4NCi1HaXJpDQoNCj4gR2VuZXJhbDogRG8gSSByZWFkIGNvcnJlY3RseSB0aGF0
IHRoaXMgZG9jdW1lbnQgY2FuIGNvbXBsZXRlbHkgc3RhbmQgYWxvbmUgZnJvbSBSRkMgNjM2Mz8g
VGhhdCBpcywgdGhlIGNhbGN1bGF0aW9uIG9mIHRoZSBwcm90ZWN0aW9uIHN0cmVhbSBhbmQgcmVj
b25zdHJ1Y3Rpb24gb2YgbG9zdCBzb3VyY2UgcGFja2V0cyBpcyBjb21wbGV0ZWx5IHNwZWNpZmll
ZCBpbiB0aGlzIGRvY3VtZW50PyBJIGRvbuKAmXQgc2VlIHRoYXQgYXMgYSBwcm9ibGVtLCBidXQg
aWYgaXTigJlzIGNvcnJlY3Qgc29tZSBpbnRyb2R1Y3Rpb24gdGV4dCB0byB0aGF0IGVmZmVjdCB3
b3VsZCBiZSBoZWxwZnVsLiBJcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gNjM2MyBldmVuIG5l
ZWRlZD8NCg0KRkxFWCBGRUMgY2VydGFpbmx5IHdhcyBpbnNwaXJlZCBieSBGRUMgRlJBTUUsIGJ1
dCB0aGUgZG9jdW1lbnQgY2FuIHN0YW5kIG9uIGl0cyBvd24uICAgIFNpbmNlIHNldmVyYWwgZGVm
aW5pdGlvbnMgYXJlIGxldmVyYWdlZCBmcm9tIFJGQyA2MzYzLCBJIGJlbGlldmUgYSBub3JtYXRp
dmUgcmVmZXJlbmNlIGlzIHN0aWxsIGFwcHJvcHJpYXRlLiAgTXkgc3VnZ2VzdGlvbiBpcyB0byBh
ZGQgb25lIHNlbnRlbmNlIHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDEuDQoNClBy
b3Bvc2VkIGNoYW5nZTogIEFkZCAiVGhpcyBkb2N1bWVudCBhbHNvIGxldmVyYWdlcyBzZXZlcmFs
IGRlZmluaXRpb25zIGFsb25nIHdpdGggdGhlIGJhc2ljIHNvdXJjZS9yZXBhaXIgaGVhZGVyIGRl
c2NyaXB0aW9uIGZyb20gUkZDIDYzNjMgaW4gdGhlaXIgYXBwbGljYXRpb24gdG8gdGhlIHBhcml0
eSBjb2RlcyBkZWZpbmVkIGhlcmUuIg0KDQo+wqcyOiBVbmxlc3MgdGhlcmXigJlzIGEgc3Ryb25n
IHJlYXNvbiBvdGhlcndpc2UsIHBsZWFzZSB1c2UgdGhlIHVwZGF0ZWQga2V5IHdvcmQgYm9pbGVy
cGxhdGUgZnJvbSBSRkMgODE3NC4NCg0KUHJvcG9zZWQgY2hhbmdlOiAgd2lsbCByZXBsYWNlIHdp
dGggdGV4dCBpbiBTZWMuIDIgb2YgUkZDIDgxNzQuDQoNCj7CpzQuMjogIlRoZSBGRUMgcmVwYWly
IHBhY2tldHMgTVVTVCBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaWRlbnRpZmllcyB0aGUgc291
cmNlIGJsb2NrLi4u4oCdOiBUaGUgTVVTVCBzZWVtcyBtb3JlIGxpa2UgYSBzdGF0ZW1lbnQgb2Yg
ZmFjdCB0aGFuIGEgbm9ybWF0aXZlIHJlcXVpcmVtZW50Lg0KDQpQcm9wb3NlZCBjaGFuZ2U6ICAi
IFRoZSBGRUMgcmVwYWlyIHBhY2tldHMgd2lsbCBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaWRl
bnRpZmllcyB0aGUgc291cmNlIGJsb2NrLi4uIg0KDQo+wqc0LjIuMToNCj4tIFRoZXJl4oCZcyBh
IG51bWJlciBvZiAyMTE5LzgxNzQga2V5d29yZHMgaW4gdGhpcyBzZWN0aW9uIHRoYXQgc2VlbSBt
b3JlIG5hdHVyYWwgY29uc2VxdWVuY2VzIG9mIHVzaW5nIFJUUCB0aGFuIG5ldyBub3JtYXRpdmUg
cmVxdWlyZW1lbnRzLiBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGV5IHNob3VsZG7igJl0IHVzZSBu
b3JtYXRpdmUga2V5d29yZHMgdW5sZXNzIGluIHRoZSBmb3JtIG9mIGRpcmVjdCBxdW90ZXMuDQoN
CkFwb2xvZ2llcyAtIEkgaGFkIHRyb3VibGUgaWRlbnRpZnlpbmcgc3VjaCBpbnN0YW5jZXMuICBB
bGwgaW5zdGFuY2VzIG9mIHN1Y2gga2V5d29yZHMgYXJlIHJlbGF0ZWQgdG8gcmVxdWlyZW1lbnRz
IHdpdGggcmVzcGVjdCB0byBSRkMgMzU1MC4gIERvIHlvdSBoYXZlIHNwZWNpZmljIGV4YW1wbGVz
Pw0KDQo+LSAxMHRoIHBhcmFncmFwaDogIlRoZSByZXBhaXIgc3RyZWFtc+KAmSBTU1JD4oCZcyBD
TkFNRSBTSE9VTEQgYmUgaWRlbnRpY2FsIHRvIHRoZSBDTkFNRSBvZiB0aGUgc291cmNlIFJUUCBz
dHJlYW0ocykgdGhhdCB0aGlzIHJlcGFpciBzdHJlYW0gcHJvdGVjdHMu4oCdIFdoeSBpcyB0aGUg
U0hPVUxEIG5vdCBhIE1VU1Q/IFdoYXQgaGFwcGVucyBpZiBpdCBpcyB2aW9sYXRlZD8NCg0KUHJv
cG9zZWQgY2hhbmdlOiAgQWdyZWVkIHRoYXQgdGhlIHJlcXVpcmVtZW50IG1ha2VzIG1vcmUgc2Vu
c2UgYXMgYSBNVVNULiAgV2lsbCBjaGFuZ2UgYWNjb3JkaW5nbHkuDQoNCj4tIDExdGggcGFyYWdy
YXBoOiAic3VjaCBzY2VuYXJpb3MsIHVzaW5nIHRoZSBzYW1lIENOQU1FIGZvciB0aGUgc291cmNl
IGFuZCByZXBhaXIgUlRQIHN0cmVhbXMgbWVhbnMgdGhhdCB0aGUgUlRQIFNvdXJjZSBhbmQgdGhl
IEZFQyBTb3VyY2UgTVVTVCBzaGFyZSB0aGUgc2FtZSBDTkFNRSAoZm9yIHRoaXMgc3BlY2lmaWMg
c291cmNlLXJlcGFpciBzdHJlYW0gYXNzb2NpYXRpb24pLuKAnSBUaGF0IE1VU1Qgc2VlbXMgbGlr
ZSBhIHN0YXRlbWVudCBvZiBmYWN0Lg0KDQpQcm9wb3NlZCBjaGFuZ2U6ICAiIHN1Y2ggc2NlbmFy
aW9zLCB1c2luZyB0aGUgc2FtZSBDTkFNRSBmb3IgdGhlIHNvdXJjZSBhbmQgcmVwYWlyIFJUUCBz
dHJlYW1zIG1lYW5zIHRoYXQgdGhlIFJUUCBTb3VyY2UgYW5kIHRoZSBGRUMgU291cmNlIHdpbGwg
c2hhcmUgdGhlIHNhbWUgQ05BTUUgKGZvciB0aGlzIHNwZWNpZmljIHNvdXJjZS1yZXBhaXIgc3Ry
ZWFtIGFzc29jaWF0aW9uKS7igJ0NCg0KPsKnNC4yLjI6IFBsZWFzZSBhZGQgYSBzaG9ydCBleHBs
YW5hdGlvbiBvZiB3aHkgd2UgbmVlZCB0d28gZGlmZmVyZW50IEZFQyBwYWNrZXQgZm9ybWF0cy4g
KE5vdCBjb3VudGluZyB0aGUgcmV0cmFuc21pc3Npb24gcGFja2V0OyB0aGUgcmVhc29uaW5nIHRo
ZXJlIGlzIHByZXR0eSBvYnZpb3VzLikNCg0KUHJvcG9zZWQgY2hhbmdlOiAgQWRkIGFkZGl0aW9u
YWwgc2VudGVuY2UgdG8gZmlyc3QgcGFyYWdyYXBoIG9mIFNlYy4gNC4yLjI6ICAiVHdvIG9mIHRo
ZXNlIHZhcmlhbnRzIGFyZSBtZWFudCB0byBkZXNjcmliZSBkaWZmZXJlbnQgbWV0aG9kcyBmb3Ig
ZGVyaXZpbmcgdGhlIHNvdXJjZSBkYXRhIGZyb20gYSBzb3VyY2UgcGFja2V0IGZvciBhIHJlcGFp
ciBwYWNrZXQuICBUaGUgdGhpcmQgdmFyaWFudCBpcyBmb3IgYSBzdHJhaWdodCByZXRyYW5zbWlz
c2lvbiBvZiB0aGUgc291cmNlIHBhY2tldC4iDQoNCj7CpzUuMS4xIChhbmQgc3Vic2VxdWVudCBt
ZWRpYSB0eXBlIGRlZmluaXRpb25zKSAtIFBsZWFzZSBjb25zaWRlciB1c2luZyB0aGUgSUVTRyAo
aWVzZ0BpZXRmLm9yZykgYXMgdGhlIGNvbnRhY3QgZm9yIGZ1cnRoZXIgaW5mb3JtYXRpb24uIFdv
cmtpbmcgZ3JvdXBzIGNvbWUgYW5kIGdvLCBhbmQgYXV0aG9ycyBjaGFuZ2Ugam9icy4gQnV0IHNv
bWVvbmUgb24gdGhlIElFU0cgc2hvdWxkIChob3BlZnVsbHkpIGFsd2F5cyBiZSBhYmxlIHRvIGZp
bmQgdGhlIHJpZ2h0IHBlcnNvbiwNCg0KVEVOVEFUSVZFIHByb3Bvc2VkIGNoYW5nZTogIEkgYW0g
aGFwcHkgdG8gc3dhcCBvdXQgVmFydW4ncyBlbWFpbCBmb3IgSUVTRywgYnV0IHRoaXMgZG9lcyBu
b3Qgc2VlbSB0byBiZSBhIHdpZGVzcHJlYWQgcHJhY3RpY2UgZXZlbiBmb3IgcmVjZW50bHktcHVi
bGlzaGVkIFJGQydzLiAgQ2FuIHlvdSBjb25maXJtIHRoYXQgdGhpcyBpcyBub3cgYmVjb21pbmcg
YSBiZXN0IHByYWN0aWNlIGZvciBjb250YWN0IGluZm8gcmVnYXJkaW5nIHJlZ2lzdHJpZXM/DQoN
Cj4tIENoYW5nZSBjb250cm9sOiAgSW4gNS4xLjEsIHNob3VsZG7igJl0IHRoYXQgYmUgdGhlIFBB
WUxPQUQgd29ya2luZyBncm91cCAob3IgaXTigJlzIHN1Y2Nlc3NvciBhcyBkZWxlZ2F0ZWQgYnkg
dGhlIElFU0cuLi4pDQoNClByb3Bvc2VkIGNoYW5nZTogIENoYW5nZSB0byAiSUVURiBBdWRpby9W
aWRlbyBQYXlsb2FkcyBUcmFuc3BvcnQgUGF5bG9hZHMgV29ya2luZyBHcm91cCINCg0KPi0gQXJl
IHRoZXNlIHJlZ2lzdHJhdGlvbnMgcmVhbGx5IGludGVuZGVkIHRvIGJlIHByb3Zpc2lvbmFsPw0K
DQpBdCB0aGlzIHBvaW50LCBuby4NCg0KUHJvcG9zZWQgY2hhbmdlOiAgRWxpbWluYXRlIG1lbnRp
b24gb2YgcHJvdmlzaW9uYWwgcmVnaXN0cmF0aW9uIGZvciBhbGwgbWVkaWEgdHlwZXMuDQoNCj7C
pzUuMi4xLCBsYXN0IGJ1bGxldDogIkFueSB1bmtub3duIG9wdGlvbiBpbiB0aGUgb2ZmZXIgTVVT
VCBiZSBpZ25vcmVkIGFuZCBkZWxldGVkIGZyb20gdGhlIGFuc3dlci7igJ06IElzIHRoYXQgYSBh
IG5ldyByZXF1aXJlbWVudCBzcGVjaWZpYyB0byBmbGV4LWZlYywgb3IganVzdCBhIG5vcm1hbCBv
ZmZlci9hbnN3ZXIgcmVxdWlyZW1lbnQ/DQoNClJGQyAzMjY0IFNlY3Rpb24gNiBzdGF0ZXMNCidG
b3IgZWFjaCAibT0iIGxpbmUgaW4gdGhlIG9mZmVyLCB0aGVyZSBNVVNUIGJlIGEgY29ycmVzcG9u
ZGluZyAibT0iIGxpbmUgaW4gdGhlIGFuc3dlci4gIFRoZSBhbnN3ZXIgTVVTVCBjb250YWluIGV4
YWN0bHkgdGhlIHNhbWUgbnVtYmVyIG9mICJtPSIgbGluZXMgYXMgdGhlIG9mZmVyLiAgVGhpcyBh
bGxvd3MgZm9yIHN0cmVhbXMgdG8gYmUgbWF0Y2hlZCB1cCBiYXNlZCBvbiB0aGVpciBvcmRlci4g
IFRoaXMgaW1wbGllcyB0aGF0IGlmIHRoZSBvZmZlciBjb250YWluZWQgemVybyAibT0iIGxpbmVz
LCB0aGUgYW5zd2VyIE1VU1QgY29udGFpbiB6ZXJvICJtPSIgbGluZXMuJw0KDQpJIGRvbid0IGJl
bGlldmUgdGhpcyBpcyBub3JtYWwgb2ZmZXIvYW5zd2VyLiAgSXQgaXMgc3BlY2lmaWMgdG8gRkxF
WCBGRUMuDQoNCj7CpzYuMy4xLjEsIGxhc3QgcGFyYWdyYXBoOiBUaGlzIGlzIHRoZSBvbmx5IG1l
bnRpb24gb2Yg4oCcc3RhaXJjYXNl4oCdIGluIHRoZSBkcmFmdC4gUGxlYXNlIGFkZCBvciBjaXRl
IGEgZGVmaW5pdGlvbi4NCg0KVGhpcyBpcyBsZWZ0b3ZlciBmcm9tIGFuIGVhcmx5IHZlcnNpb24g
b2YgdGhlIHNwZWMgd2hlcmUgYWRkaXRpb25hbCAobm9uLXBhcml0eSkgY29kZXMgd2VyZSBtZW50
aW9uZWQgaW4gdGhlIHNwZWMuICANCg0KUHJvcG9zZWQgY2hhbmdlOiAgRWxpbWluYXRlIG1lbnRp
b24gb2Ygc3RhaXJjYXNlLiAgQW55IGRlcml2YXRpdmUgc3BlY2lmaWNhdGlvbnMgcmVxdWlyaW5n
IHRoaXMgZGVmaW5pdGlvbiAoZS5nLiBMRFBDKSBjYW4gcHJvZHVjZSB0aGUgZGVmaW5pdGlvbiBp
biB0aGVpciBjb250ZXh0Lg0KDQo+wqc4OiAtICJ0aGUgcG90ZW50aWFsIGltcGFjdHMgb2YgdXNp
bmcgRkVDIE1VU1QgYmUgY29uc2lkZXJlZOKAnSBpcyB2YWd1ZSBmb3IgYSBNVVNULiBXaG8vd2hh
dCBkb2VzIHRoaXMgYXBwbHkgdG8/IElzIHRoZSBpbXBsZW1lbnRvciBleHBlY3RlZCB0byBrbm93
IGluIGFkdmFuY2Ugd2hldGhlciB0aGVpciBpbXBsZW1lbnRhdGlvbiB3aWxsIGJlIHVzZWQgaW4g
YSBjb25nZXN0aW9uLXByb25lIG5ldHdvcms/IChJZiB0aGF0IGlzIHRoZSBpbnRlbnQsIEkgc3Vn
Z2VzdCBub24tbm9ybWF0aXZlIGd1aWRhbmNlLikNCg0KVGhpcyBpcyBkZXBlbmRlbnQgb24gbWFu
eSBjb25zaWRlcmF0aW9ucyAoZS5nLiBpcyB0aGlzIGJlaW5nIHVzZWQgb24gSVAgbXVsdGljYXN0
IG5ldHdvcmssIGlzIHJhdGUgY29udHJvbCBwb3NzaWJsZSwgZXRjLikuICBOb3JtYXRpdmUgZ3Vp
ZGFuY2UgaXMgbm90IGFwcGxpY2FibGUuDQoNClByb3Bvc2VkIGNoYW5nZTogICIgdGhlIHBvdGVu
dGlhbCBpbXBhY3RzIG9mIHVzaW5nIEZFQyBzaG91bGQgYmUgY29uc2lkZXJlZCAiDQoNCj4tIOKA
nEluIGEgbmV0d29yay1mcmllbmRseSBpbXBsZW1lbnRhdGlvbuKAnTogRG8geW91IGV4cGVjdCB0
byBzZWUgbmV0d29yay11bmZyaWVuZGx5IGltcGxlbWVudGF0aW9ucz8gSXMgdGhhdCBva2F5Pw0K
DQpJIGRvbid0IHZpZXcgIm5ldHdvcmstZnJpZW5kbHkiIGFzIGJlaW5nIGEgc3RhdGljIGNvbmRp
dGlvbi4gIFRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgYW4gRkVDIHRyYW5zbWl0dGVyL3JlY2Vp
dmVyIHBhaXIgaGF2ZSBuZWdvdGlhdGVkIGEgY29ubmVjdGlvbiB3aGljaCBpcyBuZXR3b3JrLWZy
aWVuZGx5IGZvciBvbmUgYXBwbGljYXRpb24sIGJ1dCBtYXkgbm90IGJlIGZvciBhIGRpZmZlcmVu
dCBhcHBsaWNhdGlvbi4gIFRoZXJlIHdhcyBhIGRpc2N1c3Npb24gYWJvdXQgd2hlbiBGRUMgaXMg
YXBwcm9wcmlhdGUgYW5kIHdoZW4gaXQgaXMgbm90IG9uIHRoZSBXZWJSVEMgbWFpbGluZyBsaXN0
cyAtIHNlZSBodHRwczovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLXdlYnJ0
Yy8yMDE4Tm92LzAxNTYuaHRtbC4gICAiTmV0d29yay11bmZyaWVuZGx5IiBpbXBsZW1lbnRhdGlv
bnMgY291bGQgY29uY2VpdmFibHkgb2NjdXIgd2hlbiBhbiBGRUMgc2Vzc2lvbiBoYXMgYmVlbiBu
ZWdvdGlhdGVkIGJldHdlZW4gZW5kcG9pbnRzLCBidXQgbmVpdGhlciBlbmRwb2ludCBoYXMgYXNz
ZXNzZWQgdHJhbnNtaXNzaW9uIGNvbmRpdGlvbnMuIA0KDQpJbiBzaG9ydCwgSSB0aGluayB0aGUg
dGV4dCBpcyBmaW5lIGFzIGlzLiAgDQoNCj7CpzksIGxhc3QgcGFyYWdyYXBoOiBXaGF0IGFyZSB0
aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIHVudXNlZCBzb3VyY2UtYnVmZmVycz8gSXMgdGhp
cyBhIHBvdGVudGlhbCBEb1MgdmVjdG9yPw0KDQpJdCBjb3VsZCBiZS4gIFVudXNlZCBzb3VyY2Ug
YnVmZmVycyBjb21iaW5lZCB3aXRoIHBvdGVudGlhbGx5IGxhcmdlIHBhY2tldCBzaXplIChlLmcu
IGZvciBidW5kbGVkIHByb3RlY3Rpb24pIGNvdWxkIGV2ZW50dWFsbHkgcmVzdWx0IGluIGEgbGFj
ayBvZiByZXNvdXJjZXMgKGUuZy4gbWVtb3J5KSBpbiBhbiBlbmRwb2ludC4NCg0KUHJvcG9zZWQg
YWRkaXRpb25hbCBjbGFyaWZ5aW5nIHRleHQ6IEZvbGxvd2luZyAgIkdpdmVuIHRoYXQgRkxFWCBG
RUMgZW5hYmxlcyB0aGUgcHJvdGVjdGlvbiBvZiBtdWx0aXBsZSBzb3VyY2Ugc3RyZWFtcywgdGhl
cmUgZXhpc3RzIHRoZSBwb3NzaWJpbGl0eSB0aGF0IG11bHRpcGxlIHNvdXJjZSBidWZmZXJzIG1h
eSBiZSBjcmVhdGVkIHRoYXQgbWF5IG5vdCBiZSB1c2VkIiBhZGQgICJBbiBhdHRhY2tlciBjb3Vs
ZCBsZXZlcmFnZSB1bnVzZWQgc291cmNlIGJ1ZmZlcnMgdG8gYXMgYSBtZWFucyBvZiBvY2N1cHlp
bmcgbWVtb3J5IGluIGEgRkxFWCBGRUMgZW5kcG9pbnQuIg0KDQo+LSBBYnN0cmFjdDogSeKAmW0g
bm90IHN1cmUgaG93IHRvIGludGVycHJldCB0aGUgcGhyYXNlIOKAnGRlY2VudCBjb21wbGV4aXR5
4oCdLiBIb3cgbXVjaCBjb21wbGV4aXR5IHF1YWxpZmllcyBhcyDigJxkZWNlbnTigJ0/DQoNClBy
b3Bvc2VkIGNoYW5nZTogIHJlbW92ZSB0aGUgd29yZCAiZGVjZW50LiINCg0KPsKnMSwgLSBmaXJz
dCBwYXJhZ3JhcGg6IFBsZWFzZSBhZGQgIG9yIGNpdGUgYSBkZWZpbml0aW9uIGZvciBGRUMuIEni
gJltIG5vdCBzdXJlIGFsbCByZWFkZXJzIHdpbGwgdW5kZXJzdGFuZCBpdCB0aGUgc2FtZSB3YXkg
dGhlIGF1dGhvcnMgZG8uIChJIHdhcyBwZXJzb25hbGx5IHN1cnByaXNlZCB0byBmaW5kIGRpc2N1
c3Npb24gYWJvdXQgcmVhY3RpbmcgdG8gZmVlZGJhY2ssIHNpbmNlIEkgdGhvdWdodCBvZiBGRUMg
YXMgc29tZXRoaW5nIHVzZWQgd2hlbiBubyBmZWVkYmFjayBjaGFubmVsIHdhcyBhdmFpbGFibGUu
KQ0KDQpQcm9wb3NlZCBjaGFuZ2U6ICBBZGQgYWZ0ZXIgdGhlIGZpcnN0IHNlbnRlbmNlIGluIHRo
aXMgcGFyYWdyYXBoICJGb3IgYSBkZWZpbml0aW9uIG9mIEZFQywgcGxlYXNlIHJlZmVyIHRvIFNl
Y3Rpb24gMSBvZiBbUkZDNjM2M10vIg0KDQo+LSAybmQgcGFyYWdyYXBoOiBzL1JlZHVuYWRuY3kv
UmVkdW5kYW5jeeKAnQ0KDQpQcm9wb3NlZCBjaGFuZ2U6ICAgIlJlZHVuYWRuY3kiIGNoYW5nZWQg
dG8gIlJlZHVuZGFuY3kiLiAgVGhhbmsgeW91IGZvciBjYXRjaGluZyB0aGlzLg0KDQo+wqcxLjEu
MTogLSBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGRlc2NyaWJlIHdoYXQgTCBhbmQgRCByZXByZXNl
bnQgaGVyZSwgb3IgYXQgbGVhc3QgZ2l2ZSBhIGZvcndhcmQgcmVmZXJlbmNlIHRvIHRoZSBkZWZp
bml0aW9uLiAoSSBub3RlIHRoYXQgYSBsb3Qgb2YgdGV4dCBnb2VzIGJ5IGJlZm9yZSB5b3UgZ2V0
IHRvIHRoZSAgZGVmaW5pdGlvbnMgb3IgdGhlIDIxMTkgYm9pbGVycGxhdGUuKQ0KDQpDdXJyZW50
IHRleHQgc3RhdGVzOiAgIiBDb25zaWRlciBhIGdyb3VwIG9mIEQgeCBMIHNvdXJjZSBwYWNrZXRz
IHRoYXQgaGF2ZSBzZXF1ZW5jZSBudW1iZXJzIHN0YXJ0aW5nIGZyb20gMSBydW5uaW5nIHRvIEQg
eCBMLCBhbmQgYSByZXBhaXIgcGFja2V0IGlzIGdlbmVyYXRlZCBieSBhcHBseWluZyB0aGUgWE9S
IG9wZXJhdGlvbiB0byBldmVyeSBMIGNvbnNlY3V0aXZlIHBhY2tldHMgYXMgc2tldGNoZWQgaW4g
RmlndXJlIDMuIg0KDQpJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBmdXJ0aGVyIGRlZmlu
aXRpb24gcmVxdWlyZWQuICBIb3dldmVyLCBhbiBhZGRpdGlvbiBzZW50ZW5jZSBjb3VsZCBmb2xs
b3cgdGhlIGFib3ZlIGRlc2NyaXB0aW9uIHRvIGNsYXJpZnkuIA0KDQpQcm9wb3NlZCB0ZXh0OiAg
IkluIGdlbmVyYWwsIEQgYW5kIEwgcmVwcmVzZW50IHZhbHVlcyB0aGF0IGRlc2NyaWJlIGhvdyBw
YWNrZXRzIGFyZSBncm91cGVkIHRvZ2V0aGVyIGZvciBwYXJpdHkgY29kZSBnZW5lcmF0aW9uIHdo
ZW4gaW50ZXJsZWF2aW5nIGFsbCBEIHggTCBzb3VyY2UgcGFja2V0cy4iDQoNCj4tIERvZXMgMS1E
IGFuZCBsYXRlciAyLUQgc3RhbmQgZm9yIOKAnG9uZSBkaW1lbnNpb25hbOKAnSBhbmQg4oCcdHdv
IGRpbWVuc2lvbmFs4oCdPyBJZiBzbywgcGxlYXNlIGV4cGFuZCAgYm90aCBmaXJzdCBtZW50aW9u
LiAoQXMgaXQgd2FzLCBJIGdvdCBhIGJpdCBjb25mdXNlZCBieSB0cnlpbmcgdG8gY29uZmxhdGUg
dGhlIOKAnETigJ0gaW4g4oCcMS1E4oCdIHdpdGggdGhlIOKAnETigJ0gaW4g4oCcTHhE4oCdLikN
Cg0KWWVzIGl0IGRvZXMuICANCg0KUHJvcG9zZWQgY2hhbmdlOiAgU2VjLiAxLjEgdGl0bGUgY2hh
bmdlcyB0byAiT25lLURpbWVuc2lvbmFsICgxLUQpIE5vbi1pbnRlcmxlYXZlZCAoUm93KSBGRUMg
UHJvdGVjdGlvbiINClByb3Bvc2VkIGNoYW5nZTogIFNlYy4gMS4xLjQgdGl0bGUgY2hhbmdlcyB0
byAiIFR3by1EaW1lbnNpb25hbCAoMi1EKSAoUm93IGFuZCBDb2x1bW4pIEZFQyBQcm90ZWN0aW9u
Ig0KDQo+wqcxLjEuNTogICJhc3N1bWluZyB0aGF0IGVhY2ggcmVwYWlyIHBhY2tldCBjYXJyaWVz
IGFuIGVxdWFsIG51bWJlciBvZiBieXRlcyBjYXJyaWVkIGJ5IGEgc291cmNlIHBhY2tldCzigJ0N
Cj5zLyDigJxieXRlcyBjYXJyaWVk4oCdL+KAnGJ5dGVzIGFzIGNhcnJpZWTigJ0NCg0KQWdyZWVk
LiAgQ2hhbmdlIG1hZGUuDQoNCj7CpzQuMiwgbGFzdCBwYXJhZ3JhcGg6IE1pc3NpbmcgYXJ0aWNs
ZSBiZWZvcmUg4oCYUmVwYWlyIOKAnFBheWxvYWTigJ0g4oCYDQoNClByb3Bvc2VkIGNoYW5nZTog
ICJUaGUgcmVwYWlyICJQYXlsb2FkIiAuLi4iDQoNCj7CpzQuMi4yLCBwYXJhZ3JhcGggYWZ0ZXIg
RmlndXJlIDEwOiBUaGUgdGV4dCBzZWVtcyB0byBiZSBzdWdnZXN0IHRoZXJlIGlzIG9uZSBzb3Vy
Y2UgcGFja2V0IHByb3RlY3RlZCBieSBhIGdpdmVuIHJlcGFpciBwYWNrZXQuIElJVUMsIHRoYXTi
gJlzIG5vdCB0aGUgY2FzZTsgYSBnaXZlbiBGRUMgcGFja2V0IHByb3RlY3RzIHNldmVyYWwgc291
cmNlIHBhY2tldHMsIGRvZXNu4oCZdCBpdD8NCg0KVGhlIHRleHQgcmVhZHMgaW4gcGFydCAiLi4u
IGluY2x1ZGVzIHJlcGFpciBvZiBldmVyeXRoaW5nIGZvbGxvd2luZyB0aGUgZml4ZWQgMTItYnl0
ZSBSVFAgaGVhZGVyIG9mIHRoZSBzb3VyY2UgcGFja2V0IC4uLiIuICANCg0KIi4uLiBldmVyeXRo
aW5nIGZvbGxvd2luZyAuLi4iIGltcGxpZXMgbW9yZSB0aGFuIGp1c3QgYSBzaW5nbGUgc291cmNl
IFJUUCBwYWNrZXQuICANCg0KPiDCpzUuMiwgZmlyc3QgcGFyYWdyYXBoOiBzLyAiQXBwbGljYXRp
b25zIHRoYXQgYXJlIHVzaW5nIFJUUCB0cmFuc3BvcnTigJ0gLyDigJxBcHBsaWNhdGlvbnMgdGhh
dCB1c2UgdGhlIFJUUCB0cmFuc3BvcnTigJ0NCg0KQWdyZWVkLiBDaGFuZ2UgbWFkZS4NCg0KPsKn
NS4yLjEsIGZpcnN0IGJ1bGxldDogSSBkb27igJl0IGtub3cgaG93IHRvIGludGVycHJldCDigJxT
SE9VTEQgbm9ybWFsbHnigJ0uDQoNClByb3Bvc2VkIGNoYW5nZSIgIFJlbW92ZSB0aGUgd29yZCAi
bm9ybWFsbHkiDQoNCj7CpzUuMi4yLCBmaXJzdCBwYXJhZ3JhcGg6IElzIHRoZXJlIGEgcmVhc29u
IHRvIGNpdGUgdGhlIG9ic29sZXRlIFJGQyAyMzI2Pw0KDQpUaGlzIGFsc28gY2FtZSB1cCBhcyBw
YXJ0IG9mIHRoZSBJLi1ELiBuaXRzLiAgSSBkZWNpZGVkIHRvIGxlYXZlIHRoZSAyMzI2IHJlZmVy
ZW5jZSBpbiBiZWNhdXNlIEkgZGlkIG5vdCB3YW50IHRvIGltcGx5IHRoYXQgRkxFWCBGRUMgY2Fu
bm90IGJlIHVzZWQgZm9yIFJUU1AgMS4wLCBhbmQgUlRTUCAyLjAgaXMgbm90IGJhY2t3YXJkcy1j
b21wYXRpYmxlLg0KDQo+wqc2LjMuMzogLSBsaXN0IGl0ZW0gMjogIlRoZSBwYWRkaW5nIG9mIG9j
dGV0IDAgTVVTVCBiZSBhZGRlZCBhdCB0aGUgZW5kIG9mIHRoZSBiaXQgc3RyaW5nLuKAnTogSSBh
c3N1bWUgdGhhdCBtZWFucyDigJxwYWRkZWQgd2l0aCB6ZXJvc+KAnSwgYnV0IGl0IGNvdWxkIGJl
IGludGVycHJldGVkIHRvIG1lYW4g4oCccGFkIHRoZSB6ZXJvdGggYnl0ZeKAnS4NCg0KUHJvcG9z
ZWQgY2hhbmdlOiAgIlRoZSB6ZXJvLXBhZGRpbmcgb2N0ZXRzIE1VU1QgLi4uIg0KDQo+LSBsaXN0
IGl0ZW0gNTogU2hvdWxkIOKAnG51bV9yZWNvdmVyZWRfdW50aWxfdGhpc19pdGVyYXRpb27igJ0g
c2F5IOKAnGJlZm9yZV90aGlzX2l0ZXJhdGlvbuKAnT8NCg0KVGhlIGN1cnJlbnQgU2VjLiA2LjMu
MyBsaXN0IGl0ZW0gNSByZWFkcyAiIEFwcGVuZCB0aGUgcmVjb3ZlcmVkIGJpdCBzdHJpbmcgKFkg
b2N0ZXRzKSB0byB0aGUgbmV3IHBhY2tldCBnZW5lcmF0ZWQgaW4gU2VjdGlvbiA2LjMuMi4iDQoN
CklmIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBlbnN1aW5nIHNlY3Rpb25zLCBJIHRoaW5rIHRo
ZSBuYW1lIG9mIHRoZSB2YXJpYWJsZSBpcyBmaW5lIGFzIGlzLg0KDQo+wqc5LCBsYXN0IHBhcmFn
cmFwaDogSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGludGVudCBvZiB0aGUgbGFzdCBzZW50ZW5j
ZS4NCg0KT3JpZ2luYWxseSBzdWdnZXN0ZWQgaW4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y
Zy9hcmNoL21zZy9wYXlsb2FkL0FJSHc1RFNBQkVKTGE2bFNPTHJ5TGRJMGVCay4gIFRoZSBhcHBs
aWNhdGlvbiBzb3VyY2UgZGF0YSBtYXkgbm90IGJlIHBlcmZlY3RseSBtYXRjaGVkIHdpdGggRkxF
WCBGRUMgc291cmNlIHBhcnRpdGlvbmluZy4gIElmIHRoaXMgaXMgdGhlIGNhc2UsIHRoZXJlIGlz
IGEgcG9zc2liaWxpdHkgZm9yIHVucHJvdGVjdGVkIHNvdXJjZSBkYXRhIGlmLCBmb3IgaW5zdGFu
Y2UsIHRoZSBGTEVYIEZFQyBpbXBsZW1lbnRhdGlvbiBkaXNjYXJkcyBkYXRhIHRoYXQgZG9lcyBu
b3QgZml0IHBlcmZlY3RseSBpbnRvIGl0cyBzb3VyY2UgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMu
DQoNCkFkZGl0aW9uYWwgY2hhbmdlcyB0byBiZSBtYWRlIGluIG5leHQgdmVyc2lvbjoNCg0KU2Vj
LiA0LjIuMTogICJyZXBhaXJlIiBjaGFuZ2VkIHRvICJyZXBhaXIiDQoNCkZpZ3VyZSAyIGlzIGlu
Y29ycmVjdGx5IGZvcm1hdHRlZCAodG9wIG9mIGRyYXdpbmcpLg0KDQpDaGFuZ2UgSVAgYWRkcmVz
cyBpbiBleGFtcGxlIGluIFNlY3Rpb24gNy4xLjIgdG8gYSB1bmljYXN0IGFkZHJlc3MgKDE5Mi4w
LjIuMC8yNCkgYXMgcGVyIGRpc2N1c3Npb24gaW4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y
Zy9hcmNoL21zZy9wYXlsb2FkL3VETU81YnAyZWRsS1g4WlBBUFppS0JGNG5Jay4gDQoNCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0u
Y29tPiANClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDE4LCAyMDE4IDk6MDEgUE0NClRvOiBkcmFm
dC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZS5hbGxAaWV0Zi5vcmcNCkNjOiBwYXls
b2FkQGlldGYub3JnDQpTdWJqZWN0OiBBRCBFdmFsdWF0aW9uIG9mIGRyYWZ0LWlldGYtcGF5bG9h
ZC1mbGV4aWJsZS1mZWMtc2NoZW1lLTEzDQoNCkhpLA0KDQpUaGlzIGlzIG15IEFEIEV2YWx1YXRp
b24gb2YgZHJhZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUtMTMuDQoNClRoZSBk
b2N1bWVudCBpcyBvdmVyYWxsIGluIHByZXR0eSBnb29kIHNoYXBlLiBJdOKAmXMgbW9yZSByZWFk
YWJsZSB0aGFuIEkgZXhwZWN0ZWQsIGdpdmVuIHRoZSBzdWJqZWN0IG1hdHRlci4gSSB3b3VsZCBs
aWtlIHRvIGRpc2N1c3MgbXkgc3Vic3RhbnRpdmUgY29tbWVudHMvcXVlc3Rpb25zIHByaW9yIHRv
IElFVEYgTEMuDQoNClRoYW5rcyENCg0KQmVuLg0KDQoqKiogU3Vic3RhbnRpdmUqKioNCg0KR2Vu
ZXJhbDogRG8gSSByZWFkIGNvcnJlY3RseSB0aGF0IHRoaXMgZG9jdW1lbnQgY2FuIGNvbXBsZXRl
bHkgc3RhbmQgYWxvbmUgZnJvbSBSRkMgNjM2Mz8gVGhhdCBpcywgdGhlIGNhbGN1bGF0aW9uIG9m
IHRoZSBwcm90ZWN0aW9uIHN0cmVhbSBhbmQgcmVjb25zdHJ1Y3Rpb24gb2YgbG9zdCBzb3VyY2Ug
cGFja2V0cyBpcyBjb21wbGV0ZWx5IHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50PyBJIGRvbuKA
mXQgc2VlIHRoYXQgYXMgYSBwcm9ibGVtLCBidXQgaWYgaXTigJlzIGNvcnJlY3Qgc29tZSBpbnRy
b2R1Y3Rpb24gdGV4dCB0byB0aGF0IGVmZmVjdCB3b3VsZCBiZSBoZWxwZnVsLiBJcyBhIG5vcm1h
dGl2ZSByZWZlcmVuY2UgdG8gNjM2MyBldmVuIG5lZWRlZD8NCg0KIElmIHRoYXTigJlzIF9ub3Rf
IHRoZSBpbnRlbnQsIHRoZW4gd2UgbmVlZCBzb21lIGRpc2N1c3Npb24gYWJvdXQgd2hlcmUgSSB3
ZW50IHdyb25nIGluIHJlYWRpbmcgaXQuDQoNCsKnMjogVW5sZXNzIHRoZXJl4oCZcyBhIHN0cm9u
ZyByZWFzb24gb3RoZXJ3aXNlLCBwbGVhc2UgdXNlIHRoZSB1cGRhdGVkIGtleSB3b3JkIGJvaWxl
cnBsYXRlIGZyb20gUkZDIDgxNzQuDQoNCsKnNC4yOiAiVGhlIEZFQyByZXBhaXIgcGFja2V0cyBN
VVNUIGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpZGVudGlmaWVzIHRoZSBzb3VyY2UgYmxvY2su
Li7igJ06IFRoZSBNVVNUIHNlZW1zIG1vcmUgbGlrZSBhIHN0YXRlbWVudCBvZiBmYWN0IHRoYW4g
YSBub3JtYXRpdmUgcmVxdWlyZW1lbnQuDQoNCsKnNC4yLjE6DQoNCi0gVGhlcmXigJlzIGEgbnVt
YmVyIG9mIDIxMTkvODE3NCBrZXl3b3JkcyBpbiB0aGlzIHNlY3Rpb24gdGhhdCBzZWVtIG1vcmUg
bmF0dXJhbCBjb25zZXF1ZW5jZXMgb2YgdXNpbmcgUlRQIHRoYW4gbmV3IG5vcm1hdGl2ZSByZXF1
aXJlbWVudHMuIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZXkgc2hvdWxkbuKAmXQgdXNlIG5vcm1h
dGl2ZSBrZXl3b3JkcyB1bmxlc3MgaW4gdGhlIGZvcm0gb2YgZGlyZWN0IHF1b3Rlcy4NCg0KLSAx
MHRoIHBhcmFncmFwaDogIlRoZSByZXBhaXIgc3RyZWFtc+KAmSBTU1JD4oCZcyBDTkFNRSBTSE9V
TEQgYmUgaWRlbnRpY2FsIHRvIHRoZSBDTkFNRSBvZiB0aGUgc291cmNlIFJUUCBzdHJlYW0ocykg
dGhhdCB0aGlzIHJlcGFpciBzdHJlYW0gcHJvdGVjdHMu4oCdDQpXaHkgaXMgdGhlIFNIT1VMRCBu
b3QgYSBNVVNUPyBXaGF0IGhhcHBlbnMgaWYgaXQgaXMgdmlvbGF0ZWQ/DQoNCg0KLSAxMXRoIHBh
cmFncmFwaDogInN1Y2gNCnNjZW5hcmlvcywgdXNpbmcgdGhlIHNhbWUgQ05BTUUgZm9yIHRoZSBz
b3VyY2UgYW5kIHJlcGFpciBSVFAgc3RyZWFtcyBtZWFucyB0aGF0IHRoZSBSVFAgU291cmNlIGFu
ZCB0aGUgRkVDIFNvdXJjZSBNVVNUIHNoYXJlIHRoZSBzYW1lIENOQU1FIChmb3IgdGhpcyBzcGVj
aWZpYyBzb3VyY2UtcmVwYWlyIHN0cmVhbSBhc3NvY2lhdGlvbiku4oCdDQoNClRoYXQgTVVTVCBz
ZWVtcyBsaWtlIGEgc3RhdGVtZW50IG9mIGZhY3QuDQoNCsKnNC4yLjI6IFBsZWFzZSBhZGQgYSBz
aG9ydCBleHBsYW5hdGlvbiBvZiB3aHkgd2UgbmVlZCB0d28gZGlmZmVyZW50IEZFQyBwYWNrZXQg
Zm9ybWF0cy4gKE5vdCBjb3VudGluZyB0aGUgcmV0cmFuc21pc3Npb24gcGFja2V0OyB0aGUgcmVh
c29uaW5nIHRoZXJlIGlzIHByZXR0eSBvYnZpb3VzLikNCg0Kwqc1LjEuMSAoYW5kIHN1YnNlcXVl
bnQgbWVkaWEgdHlwZSBkZWZpbml0aW9ucykNCg0KLSBQbGVhc2UgY29uc2lkZXIgdXNpbmcgdGhl
IElFU0cgKGllc2dAaWV0Zi5vcmcpIGFzIHRoZSBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0
aW9uLiBXb3JraW5nIGdyb3VwcyBjb21lIGFuZCBnbywgYW5kIGF1dGhvcnMgY2hhbmdlIGpvYnMu
IEJ1dCBzb21lb25lIG9uIHRoZSBJRVNHIHNob3VsZCAoaG9wZWZ1bGx5KSBhbHdheXMgYmUgYWJs
ZSB0byBmaW5kIHRoZSByaWdodCBwZXJzb24sDQoNCi0gQ2hhbmdlIGNvbnRyb2w6ICBJbiA1LjEu
MSwgc2hvdWxkbuKAmXQgdGhhdCBiZSB0aGUgUEFZTE9BRCB3b3JraW5nIGdyb3VwIChvciBpdOKA
mXMgc3VjY2Vzc29yIGFzIGRlbGVnYXRlZCBieSB0aGUgSUVTRy4uLikNCg0KLSBBcmUgdGhlc2Ug
cmVnaXN0cmF0aW9ucyByZWFsbHkgaW50ZW5kZWQgdG8gYmUgcHJvdmlzaW9uYWw/DQoNCsKnNS4y
LjEsIGxhc3QgYnVsbGV0OiAiQW55IHVua25vd24gb3B0aW9uIGluIHRoZSBvZmZlciBNVVNUIGJl
IGlnbm9yZWQgYW5kIGRlbGV0ZWQgZnJvbSB0aGUgYW5zd2VyLuKAnTogSXMgdGhhdCBhIGEgbmV3
IHJlcXVpcmVtZW50IHNwZWNpZmljIHRvIGZsZXgtZmVjLCBvciBqdXN0IGEgbm9ybWFsIG9mZmVy
L2Fuc3dlciByZXF1aXJlbWVudD8NCg0Kwqc2LjMuMS4xLCBsYXN0IHBhcmFncmFwaDogVGhpcyBp
cyB0aGUgb25seSBtZW50aW9uIG9mIOKAnHN0YWlyY2FzZeKAnSBpbiB0aGUgZHJhZnQuIFBsZWFz
ZSBhZGQgb3IgY2l0ZSBhIGRlZmluaXRpb24uDQoNCsKnODoNCi0gInRoZSBwb3RlbnRpYWwgaW1w
YWN0cyBvZiB1c2luZyBGRUMgTVVTVCBiZSBjb25zaWRlcmVk4oCdIGlzIHZhZ3VlIGZvciBhIE1V
U1QuIFdoby93aGF0IGRvZXMgdGhpcyBhcHBseSB0bz8gSXMgdGhlIGltcGxlbWVudG9yIGV4cGVj
dGVkIHRvIGtub3cgaW4gYWR2YW5jZSB3aGV0aGVyIHRoZWlyIGltcGxlbWVudGF0aW9uIHdpbGwg
YmUgdXNlZCBpbiBhIGNvbmdlc3Rpb24tcHJvbmUgbmV0d29yaz8gKElmIHRoYXQgaXMgdGhlIGlu
dGVudCwgSSBzdWdnZXN0IG5vbi1ub3JtYXRpdmUgZ3VpZGFuY2UuKQ0KLSDigJxJbiBhIG5ldHdv
cmstZnJpZW5kbHkgaW1wbGVtZW50YXRpb27igJ06IERvIHlvdSBleHBlY3QgdG8gc2VlIG5ldHdv
cmstdW5mcmllbmRseSBpbXBsZW1lbnRhdGlvbnM/IElzIHRoYXQgb2theT8NCg0Kwqc5LCBsYXN0
IHBhcmFncmFwaDogV2hhdCBhcmUgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyBvZiB1bnVzZWQg
c291cmNlLWJ1ZmZlcnM/IElzIHRoaXMgYSBwb3RlbnRpYWwgRG9TIHZlY3Rvcj8NCg0KDQoqKiog
RWRpdG9yaWFsICoqKg0KDQotIEFic3RyYWN0OiBJ4oCZbSBub3Qgc3VyZSBob3cgdG8gaW50ZXJw
cmV0IHRoZSBwaHJhc2Ug4oCcZGVjZW50IGNvbXBsZXhpdHnigJ0uIEhvdyBtdWNoIGNvbXBsZXhp
dHkgcXVhbGlmaWVzIGFzIOKAnGRlY2VudOKAnT8NCg0KwqcxLA0KDQotIGZpcnN0IHBhcmFncmFw
aDogUGxlYXNlIGFkZCAgb3IgY2l0ZSBhIGRlZmluaXRpb24gZm9yIEZFQy4gSeKAmW0gbm90IHN1
cmUgYWxsIHJlYWRlcnMgd2lsbCB1bmRlcnN0YW5kIGl0IHRoZSBzYW1lIHdheSB0aGUgYXV0aG9y
cyBkby4gKEkgd2FzIHBlcnNvbmFsbHkgc3VycHJpc2VkIHRvIGZpbmQgZGlzY3Vzc2lvbiBhYm91
dCByZWFjdGluZyB0byBmZWVkYmFjaywgc2luY2UgSSB0aG91Z2h0IG9mIEZFQyBhcyBzb21ldGhp
bmcgdXNlZCB3aGVuIG5vIGZlZWRiYWNrIGNoYW5uZWwgd2FzIGF2YWlsYWJsZS4pDQoNCi0gMm5k
IHBhcmFncmFwaDogcy9SZWR1bmFkbmN5L1JlZHVuZGFuY3nigJ0NCg0KwqcxLjEuMToNCg0KLSBJ
dCB3b3VsZCBiZSBoZWxwZnVsIHRvIGRlc2NyaWJlIHdoYXQgTCBhbmQgRCByZXByZXNlbnQgaGVy
ZSwgb3IgYXQgbGVhc3QgZ2l2ZSBhIGZvcndhcmQgcmVmZXJlbmNlIHRvIHRoZSBkZWZpbml0aW9u
LiAoSSBub3RlIHRoYXQgYSBsb3Qgb2YgdGV4dCBnb2VzIGJ5IGJlZm9yZSB5b3UgZ2V0IHRvIHRo
ZSAgZGVmaW5pdGlvbnMgb3IgdGhlIDIxMTkgYm9pbGVycGxhdGUuKQ0KDQotIERvZXMgMS1EIGFu
ZCBsYXRlciAyLUQgc3RhbmQgZm9yIOKAnG9uZSBkaW1lbnNpb25hbOKAnSBhbmQg4oCcdHdvIGRp
bWVuc2lvbmFs4oCdPyBJZiBzbywgcGxlYXNlIGV4cGFuZCAgYm90aCBmaXJzdCBtZW50aW9uLiAo
QXMgaXQgd2FzLCBJIGdvdCBhIGJpdCBjb25mdXNlZCBieSB0cnlpbmcgdG8gY29uZmxhdGUgdGhl
IOKAnETigJ0gaW4g4oCcMS1E4oCdIHdpdGggdGhlIOKAnETigJ0gaW4g4oCcTHhE4oCdLikNCg0K
wqcxLjEuNToNCi0gImFzc3VtaW5nIHRoYXQgZWFjaCByZXBhaXIgcGFja2V0IGNhcnJpZXMgYW4g
ZXF1YWwgbnVtYmVyIG9mIGJ5dGVzIGNhcnJpZWQgYnkgYSBzb3VyY2UgcGFja2V0LOKAnQ0Kcy8g
4oCcYnl0ZXMgY2FycmllZOKAnS/igJxieXRlcyBhcyBjYXJyaWVk4oCdDQoNCsKnNC4yLCBsYXN0
IHBhcmFncmFwaDogTWlzc2luZyBhcnRpY2xlIGJlZm9yZSDigJhSZXBhaXIg4oCcUGF5bG9hZOKA
nSDigJgNCg0Kwqc0LjIuMiwgcGFyYWdyYXBoIGFmdGVyIEZpZ3VyZSAxMDoNClRoZSB0ZXh0IHNl
ZW1zIHRvIGJlIHN1Z2dlc3QgdGhlcmUgaXMgb25lIHNvdXJjZSBwYWNrZXQgcHJvdGVjdGVkIGJ5
IGEgZ2l2ZW4gcmVwYWlyIHBhY2tldC4gSUlVQywgdGhhdOKAmXMgbm90IHRoZSBjYXNlOyBhIGdp
dmVuIEZFQyBwYWNrZXQgcHJvdGVjdHMgc2V2ZXJhbCBzb3VyY2UgcGFja2V0cywgZG9lc27igJl0
IGl0Pw0KDQrCpzUuMiwgZmlyc3QgcGFyYWdyYXBoOiBzLyAiQXBwbGljYXRpb25zIHRoYXQgYXJl
IHVzaW5nIFJUUCB0cmFuc3BvcnTigJ0gLyDigJxBcHBsaWNhdGlvbnMgdGhhdCB1c2UgdGhlIFJU
UCB0cmFuc3BvcnTigJ0NCg0Kwqc1LjIuMSwgZmlyc3QgYnVsbGV0OiBJIGRvbuKAmXQga25vdyBo
b3cgdG8gaW50ZXJwcmV0IOKAnFNIT1VMRCBub3JtYWxseeKAnS4NCg0Kwqc1LjIuMiwgZmlyc3Qg
cGFyYWdyYXBoOiBJcyB0aGVyZSBhIHJlYXNvbiB0byBjaXRlIHRoZSBvYnNvbGV0ZSBSRkMgMjMy
Nj8NCg0Kwqc2LjMuMzoNCi0gbGlzdCBpdGVtIDI6ICJUaGUgcGFkZGluZyBvZiBvY3RldCAwIE1V
U1QgYmUgYWRkZWQgYXQgdGhlIGVuZCBvZiB0aGUgYml0IHN0cmluZy7igJ06IEkgYXNzdW1lIHRo
YXQgbWVhbnMg4oCccGFkZGVkIHdpdGggemVyb3PigJ0sIGJ1dCBpdCBjb3VsZCBiZSBpbnRlcnBy
ZXRlZCB0byBtZWFuIOKAnHBhZCB0aGUgemVyb3RoIGJ5dGXigJ0uDQoNCi0gbGlzdCBpdGVtIDU6
IFNob3VsZCDigJxudW1fcmVjb3ZlcmVkX3VudGlsX3RoaXNfaXRlcmF0aW9u4oCdIHNheSDigJxi
ZWZvcmVfdGhpc19pdGVyYXRpb27igJ0/DQoNCsKnOSwgbGFzdCBwYXJhZ3JhcGg6IEkgZG9u4oCZ
dCB1bmRlcnN0YW5kIHRoZSBpbnRlbnQgb2YgdGhlIGxhc3Qgc2VudGVuY2UuDQoNCg0KDQoNCg0K


From nobody Sat Dec 22 21:14:39 2018
Return-Path: <ben@nostrum.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681C0126F72; Sat, 22 Dec 2018 21:14:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.679
X-Spam-Level: 
X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Io77-_XPxrkU; Sat, 22 Dec 2018 21:14:35 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BB7012008A; Sat, 22 Dec 2018 21:14:35 -0800 (PST)
Received: from [10.0.1.45] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id wBN5EXsa045362 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 22 Dec 2018 23:14:34 -0600 (CST) (envelope-from ben@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1545542074; bh=G5WocH7NY410Cz+nVJ68PKTn7uVunoxFL2/p32P7fcw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=PKuFiuUJVXQVT0VZA2jr33a9glRDnF64Q7iE3c/i3qPA/T4rHFky3ViG8nWKrukxX s1tSof2DF50IwxJE2p6W/sq3nJbJL+3LWvQvwsAn8+CTNKjB+3Hya8iQ0VuMRfUPFv +0fLPyDToC9Cju3hBbBNCNhEw1ZsxXQcjCQw34FM=
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.45]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <F3D73813-1E03-4413-B2C3-53D57934D44C@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F802ADD4-BD17-4A4B-8AC4-BAE90E021F92"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Sat, 22 Dec 2018 23:14:32 -0600
In-Reply-To: <485343397e554f97be3e0a5c9df8ef4d@NASANEXM01C.na.qualcomm.com>
Cc: "draft-ietf-payload-flexible-fec-scheme.all@ietf.org" <draft-ietf-payload-flexible-fec-scheme.all@ietf.org>,  "payload@ietf.org" <payload@ietf.org>
To: Giridhar Mandyam <mandyam@qti.qualcomm.com>
References: <3462BDFF-84C6-4FE5-857D-50B457AF15FE@nostrum.com> <485343397e554f97be3e0a5c9df8ef4d@NASANEXM01C.na.qualcomm.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/kx_C9UjQpE2ItfCYkE3eJMgKSPk>
Subject: Re: [payload] AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Dec 2018 05:14:37 -0000

--Apple-Mail=_F802ADD4-BD17-4A4B-8AC4-BAE90E021F92
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_325D7088-B091-467D-BB22-7876C8752C0C"


--Apple-Mail=_325D7088-B091-467D-BB22-7876C8752C0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi, thanks for the quick response! Comments inline. I removed sections =
that seem resolved.

Ben.

> On Dec 22, 2018, at 7:38 PM, Giridhar Mandyam =
<mandyam@qti.qualcomm.com> wrote:
>=20
> Thank you for the careful review.  Before submitting rev 14, I would =
like to get agreement on the following proposed changes.
> -Giri
>=20
>> General: Do I read correctly that this document can completely stand =
alone from RFC 6363? That is, the calculation of the protection stream =
and reconstruction of lost source packets is completely specified in =
this document? I don=E2=80=99t see that as a problem, but if it=E2=80=99s =
correct some introduction text to that effect would be helpful. Is a =
normative reference to 6363 even needed?
>=20
> FLEX FEC certainly was inspired by FEC FRAME, but the document can =
stand on its own.    Since several definitions are leveraged from RFC =
6363, I believe a normative reference is still appropriate.  My =
suggestion is to add one sentence to the last paragraph of Section 1.
>=20
> Proposed change:  Add "This document also leverages several =
definitions along with the basic source/repair header description from =
RFC 6363 in their application to the parity codes defined here.=E2=80=9D

That helps. I might suggest something along the lines of =E2=80=9CWhile =
this document fully defines the use of FEC to protect RTP streams, it =
also leverages...=E2=80=9D

[...]


>> =C2=A74.2.1:
>> - There=E2=80=99s a number of 2119/8174 keywords in this section that =
seem more natural consequences of using RTP than new normative =
requirements. If that is the case, they shouldn=E2=80=99t use normative =
keywords unless in the form of direct quotes.
>=20
> Apologies - I had trouble identifying such instances.  All instances =
of such keywords are related to requirements with respect to RFC 3550.  =
Do you have specific examples?

- definition of sequence number. Doesn=E2=80=99t RTP already require the =
sequence number to increment by one, and recommend the use of a random =
starting value?

- definition of time stamp: I initially thought that the SHALL reflected =
a requirement already in 3550, but now I realize that transmission time =
is not the same as sampling time.  So this one is probably okay.

- SSRC: 3550 already says SSRCs SHOULD be assigned randomly, so the =
requirement is a statement of fact as far as _this_ spec is concerned. =
(The text even mentions =E2=80=9Cas suggested by RFC 3350", although =
3550 does more than =E2=80=9Csuggest=E2=80=9D it.)

- "the collisions MUST be resolved as described in [RFC3550]=E2=80=9D : =
again, that follows naturally from using RTP. It does not define a new =
requirement.

>=20
>> - 10th paragraph: "The repair streams=E2=80=99 SSRC=E2=80=99s CNAME =
SHOULD be identical to the CNAME of the source RTP stream(s) that this =
repair stream protects.=E2=80=9D Why is the SHOULD not a MUST? What =
happens if it is violated?
>=20
> Proposed change:  Agreed that the requirement makes more sense as a =
MUST.  Will change accordingly.

I concur with the change, but it is a material change. Please point it =
out to the WG in case anyone objects. (It may not be safe to assume =
people are reading this note in that level of detail, especially over =
the holidays :-)) To be clear, I don=E2=80=99t want to block progress of =
the draft over it; if anyone objects they can do so as part of the IETF =
last call.

[...]

>=20
>> =C2=A74.2.2: Please add a short explanation of why we need two =
different FEC packet formats. (Not counting the retransmission packet; =
the reasoning there is pretty obvious.)
>=20
> Proposed change:  Add additional sentence to first paragraph of Sec. =
4.2.2:  "Two of these variants are meant to describe different methods =
for deriving the source data from a source packet for a repair packet.  =
The third variant is for a straight retransmission of the source =
packet.=E2=80=9D

That=E2=80=99s useful, but it doesn=E2=80=99t explain _why_ we need two =
different methods.

>=20
>> =C2=A75.1.1 (and subsequent media type definitions) - Please consider =
using the IESG (iesg@ietf.org) as the contact for further information. =
Working groups come and go, and authors change jobs. But someone on the =
IESG should (hopefully) always be able to find the right person,
>=20
> TENTATIVE proposed change:  I am happy to swap out Varun's email for =
IESG, but this does not seem to be a widespread practice even for =
recently-published RFC's.  Can you confirm that this is now becoming a =
best practice for contact info regarding registries?

It=E2=80=99s been common of late. The reasoning is that the IESG email =
address is the least likely to change of any contact we might give.

>=20
>> - Change control:  In 5.1.1, shouldn=E2=80=99t that be the PAYLOAD =
working group (or it=E2=80=99s successor as delegated by the IESG...)
>=20
> Proposed change:  Change to "IETF Audio/Video Payloads Transport =
Payloads Working Group=E2=80=9D

I suggest adding =E2=80=9C... or it=E2=80=99s successor as delegated by =
the IESG.


>=20
>> - Are these registrations really intended to be provisional?
>=20
> At this point, no.
>=20
> Proposed change:  Eliminate mention of provisional registration for =
all media types.

I agree. However this is another material change that should be pointed =
out to the WG.

>=20
>> =C2=A75.2.1, last bullet: "Any unknown option in the offer MUST be =
ignored and deleted from the answer.=E2=80=9D: Is that a a new =
requirement specific to flex-fec, or just a normal offer/answer =
requirement?
>=20
> RFC 3264 Section 6 states
> 'For each "m=3D" line in the offer, there MUST be a corresponding "m=3D"=
 line in the answer.  The answer MUST contain exactly the same number of =
"m=3D" lines as the offer.  This allows for streams to be matched up =
based on their order.  This implies that if the offer contained zero =
"m=3D" lines, the answer MUST contain zero "m=3D" lines.'
>=20
> I don't believe this is normal offer/answer.  It is specific to FLEX =
FEC.

Okay.

[...]

>=20
>> - =E2=80=9CIn a network-friendly implementation=E2=80=9D: Do you =
expect to see network-unfriendly implementations? Is that okay?
>=20
> I don't view "network-friendly" as being a static condition.  There =
are scenarios where an FEC transmitter/receiver pair have negotiated a =
connection which is network-friendly for one application, but may not be =
for a different application.  There was a discussion about when FEC is =
appropriate and when it is not on the WebRTC mailing lists - see =
https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0156.html.   =
"Network-unfriendly" implementations could conceivably occur when an FEC =
session has been negotiated between endpoints, but neither endpoint has =
assessed transmission conditions.

Is that a reasonably implementation? It sounds like a bug to me. (I =
probably could have phrased my question better as =E2=80=9C are =
network-unfriendly implementations ever acceptable=E2=80=9D.)

> In short, I think the text is fine as is.

I disagree. =E2=80=9CNetwork-friendly=E2=80=9D is a condition that =
triggers a SHOULD. I think there=E2=80=99s a high chance you will see =
different implementors interpret that condition differently. If the =
intent is to give normative guidance, there needs to be enough =
information to avoid that. OTOH, if the intent is to point out things an =
implementer needs to think about, then the normative SHOULD may not be =
appropriate.

>=20
>> =C2=A79, last paragraph: What are the security implications of unused =
source-buffers? Is this a potential DoS vector?
>=20
> It could be.  Unused source buffers combined with potentially large =
packet size (e.g. for bundled protection) could eventually result in a =
lack of resources (e.g. memory) in an endpoint.
>=20
> Proposed additional clarifying text: Following  "Given that FLEX FEC =
enables the protection of multiple source streams, there exists the =
possibility that multiple source buffers may be created that may not be =
used" add  "An attacker could leverage unused source buffers to as a =
means of occupying memory in a FLEX FEC endpoint.=E2=80=9D

Works for me.

[...]

>=20
>> - 2nd paragraph: s/Redunadncy/Redundancy=E2=80=9D
>=20
> Proposed change:   "Redunadncy" changed to "Redundancy".  Thank you =
for catching this.
>=20
>> =C2=A71.1.1: - It would be helpful to describe what L and D represent =
here, or at least give a forward reference to the definition. (I note =
that a lot of text goes by before you get to the  definitions or the =
2119 boilerplate.)
>=20
> Current text states:  " Consider a group of D x L source packets that =
have sequence numbers starting from 1 running to D x L, and a repair =
packet is generated by applying the XOR operation to every L consecutive =
packets as sketched in Figure 3."
>=20
> I don't think that there is a further definition required.  However, =
an addition sentence could follow the above description to clarify.
>=20
> Proposed text:  "In general, D and L represent values that describe =
how packets are grouped together for parity code generation when =
interleaving all D x L source packets.=E2=80=9D

That=E2=80=99s kind of circular explanation. I was just looking for =
something along the lines of =E2=80=98 =E2=80=9CD=E2=80=9D and =E2=80=9CL=E2=
=80=9D represent the depth and length, respectively=E2=80=9D.

[...]
>=20
>> =C2=A74.2.2, paragraph after Figure 10: The text seems to be suggest =
there is one source packet protected by a given repair packet. IIUC, =
that=E2=80=99s not the case; a given FEC packet protects several source =
packets, doesn=E2=80=99t it?
>=20
> The text reads in part "... includes repair of everything following =
the fixed 12-byte RTP header of the source packet ...".
>=20
> "... everything following ..." implies more than just a single source =
RTP packet.

Let=E2=80=99s say for argument that the repair packet protects 2 source =
packets. Is the 12-byte RTP header of the 2nd packet protected?

(Even if the answer is yes, it would be helpful to say " ... and =
subsequent packets...")

[...]

>> =C2=A75.2.2, first paragraph: Is there a reason to cite the obsolete =
RFC 2326?
>=20
> This also came up as part of the I.-D. nits.  I decided to leave the =
2326 reference in because I did not want to imply that FLEX FEC cannot =
be used for RTSP 1.0, and RTSP 2.0 is not backwards-compatible.
>=20

I suggest adding a few words to explain that.

[...]

>=20
>> =C2=A79, last paragraph: I don=E2=80=99t understand the intent of the =
last sentence.
>=20
> Originally suggested in =
https://mailarchive.ietf.org/arch/msg/payload/AIHw5DSABEJLa6lSOLryLdI0eBk.=
  The application source data may not be perfectly matched with FLEX FEC =
source partitioning.  If this is the case, there is a possibility for =
unprotected source data if, for instance, the FLEX FEC implementation =
discards data that does not fit perfectly into its source processing =
requirements.

That explanation is more clear than the text in the draft. I suggest =
including it.

[...]

--Apple-Mail=_325D7088-B091-467D-BB22-7876C8752C0C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hi, =
thanks for the quick response! Comments inline. I removed sections that =
seem resolved.<div class=3D""><br class=3D""></div><div class=3D"">Ben.<br=
 class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Dec 22, 2018, at 7:38 PM, Giridhar Mandyam &lt;<a =
href=3D"mailto:mandyam@qti.qualcomm.com" =
class=3D"">mandyam@qti.qualcomm.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"">Thank =
you for the careful review. &nbsp;Before submitting rev 14, I would like =
to get agreement on the following proposed changes.<br class=3D"">-Giri<br=
 class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">General: =
Do I read correctly that this document can completely stand alone from =
RFC 6363? That is, the calculation of the protection stream and =
reconstruction of lost source packets is completely specified in this =
document? I don=E2=80=99t see that as a problem, but if it=E2=80=99s =
correct some introduction text to that effect would be helpful. Is a =
normative reference to 6363 even needed?<br class=3D""></blockquote><br =
class=3D"">FLEX FEC certainly was inspired by FEC FRAME, but the =
document can stand on its own. &nbsp;&nbsp;&nbsp;Since several =
definitions are leveraged from RFC 6363, I believe a normative reference =
is still appropriate. &nbsp;My suggestion is to add one sentence to the =
last paragraph of Section 1.<br class=3D""><br class=3D"">Proposed =
change: &nbsp;Add "This document also leverages several definitions =
along with the basic source/repair header description from RFC 6363 in =
their application to the parity codes defined =
here.=E2=80=9D</div></div></blockquote><div><br class=3D""></div><div>That=
 helps. I might suggest something along the lines of =E2=80=9CWhile this =
document fully defines the use of FEC to protect RTP streams, it also =
leverages...=E2=80=9D</div><div><br =
class=3D""></div><div>[...]</div><div><br class=3D""></div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D""><blockquote type=3D"cite" class=3D"">=C2=A74.2.1:<br =
class=3D"">- There=E2=80=99s a number of 2119/8174 keywords in this =
section that seem more natural consequences of using RTP than new =
normative requirements. If that is the case, they shouldn=E2=80=99t use =
normative keywords unless in the form of direct quotes.<br =
class=3D""></blockquote><br class=3D"">Apologies - I had trouble =
identifying such instances. &nbsp;All instances of such keywords are =
related to requirements with respect to RFC 3550. &nbsp;Do you have =
specific examples?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>- definition of sequence number. Doesn=E2=80=99t =
RTP already require the sequence number to increment by one, and =
recommend the use of a random starting value?</div><div><br =
class=3D""></div><div>- definition of time stamp: I initially thought =
that the SHALL reflected a requirement already in 3550, but now I =
realize that transmission time is not the same as sampling time. =
&nbsp;So this one is probably okay.</div><div><br class=3D""></div><div>- =
SSRC: 3550 already says SSRCs SHOULD be assigned randomly, so the =
requirement is a statement of fact as far as _this_ spec is concerned. =
(The text even mentions =E2=80=9Cas suggested by RFC 3350", although =
3550 does more than =E2=80=9Csuggest=E2=80=9D it.)</div><div><br =
class=3D""></div><div>- "<span style=3D"font-family: Courier;" =
class=3D"">the collisions&nbsp;</span><font face=3D"Courier" =
class=3D"">MUST be resolved as described in [RFC3550]=E2=80=9D : again, =
that follows naturally from using RTP. It does not define a new =
requirement.</font></div><div><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">- 10th paragraph: "The =
repair streams=E2=80=99 SSRC=E2=80=99s CNAME SHOULD be identical to the =
CNAME of the source RTP stream(s) that this repair stream protects.=E2=80=9D=
 Why is the SHOULD not a MUST? What happens if it is violated?<br =
class=3D""></blockquote><br class=3D"">Proposed change: &nbsp;Agreed =
that the requirement makes more sense as a MUST. &nbsp;Will change =
accordingly.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>I concur with the change, but it is a material =
change. Please point it out to the WG in case anyone objects. (It may =
not be safe to assume people are reading this note in that level of =
detail, especially over the holidays :-)) To be clear, I don=E2=80=99t =
want to block progress of the draft over it; if anyone objects they can =
do so as part of the IETF last call.</div><div><br =
class=3D""></div><div>[...]</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">=C2=A74.2.2: Please add a short explanation of =
why we need two different FEC packet formats. (Not counting the =
retransmission packet; the reasoning there is pretty obvious.)<br =
class=3D""></blockquote><br class=3D"">Proposed change: &nbsp;Add =
additional sentence to first paragraph of Sec. 4.2.2: &nbsp;"Two of =
these variants are meant to describe different methods for deriving the =
source data from a source packet for a repair packet. &nbsp;The third =
variant is for a straight retransmission of the source =
packet.=E2=80=9D</div></div></blockquote><div><br =
class=3D""></div><div>That=E2=80=99s useful, but it doesn=E2=80=99t =
explain _why_ we need two different methods.</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">=C2=A75.1.1=
 (and subsequent media type definitions) - Please consider using the =
IESG (<a href=3D"mailto:iesg@ietf.org" class=3D"">iesg@ietf.org</a>) as =
the contact for further information. Working groups come and go, and =
authors change jobs. But someone on the IESG should (hopefully) always =
be able to find the right person,<br class=3D""></blockquote><br =
class=3D"">TENTATIVE proposed change: &nbsp;I am happy to swap out =
Varun's email for IESG, but this does not seem to be a widespread =
practice even for recently-published RFC's. &nbsp;Can you confirm that =
this is now becoming a best practice for contact info regarding =
registries?<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>It=E2=80=99s been common of late. The reasoning is =
that the IESG email address is the least likely to change of any contact =
we might give.</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">- Change control: &nbsp;In 5.1.1, shouldn=E2=80=99=
t that be the PAYLOAD working group (or it=E2=80=99s successor as =
delegated by the IESG...)<br class=3D""></blockquote><br =
class=3D"">Proposed change: &nbsp;Change to "IETF Audio/Video Payloads =
Transport Payloads Working Group=E2=80=9D</div></div></blockquote><div><br=
 class=3D""></div><div>I suggest adding =E2=80=9C... or it=E2=80=99s =
successor as delegated by the IESG.</div><div><br class=3D""></div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">- Are =
these registrations really intended to be provisional?<br =
class=3D""></blockquote><br class=3D"">At this point, no.<br =
class=3D""><br class=3D"">Proposed change: &nbsp;Eliminate mention of =
provisional registration for all media types.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>I =
agree. However this is another material change that should be pointed =
out to the WG.</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">=C2=A75.2.1, last bullet: "Any unknown option =
in the offer MUST be ignored and deleted from the answer.=E2=80=9D: Is =
that a a new requirement specific to flex-fec, or just a normal =
offer/answer requirement?<br class=3D""></blockquote><br class=3D"">RFC =
3264 Section 6 states<br class=3D"">'For each "m=3D" line in the offer, =
there MUST be a corresponding "m=3D" line in the answer. &nbsp;The =
answer MUST contain exactly the same number of "m=3D" lines as the =
offer. &nbsp;This allows for streams to be matched up based on their =
order. &nbsp;This implies that if the offer contained zero "m=3D" lines, =
the answer MUST contain zero "m=3D" lines.'<br class=3D""><br class=3D"">I=
 don't believe this is normal offer/answer. &nbsp;It is specific to FLEX =
FEC.<br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>Okay.</div><div><br =
class=3D""></div><div>[...]</div><div><br class=3D""></div><blockquote =
type=3D"cite" class=3D""><div class=3D""><div class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D"">- =E2=80=9CIn a =
network-friendly implementation=E2=80=9D: Do you expect to see =
network-unfriendly implementations? Is that okay?<br =
class=3D""></blockquote><br class=3D"">I don't view "network-friendly" =
as being a static condition. &nbsp;There are scenarios where an FEC =
transmitter/receiver pair have negotiated a connection which is =
network-friendly for one application, but may not be for a different =
application. &nbsp;There was a discussion about when FEC is appropriate =
and when it is not on the WebRTC mailing lists - see <a =
href=3D"https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0156.ht=
ml" =
class=3D"">https://lists.w3.org/Archives/Public/public-webrtc/2018Nov/0156=
.html</a>. &nbsp;&nbsp;"Network-unfriendly" implementations could =
conceivably occur when an FEC session has been negotiated between =
endpoints, but neither endpoint has assessed transmission conditions. =
<br class=3D""></div></div></blockquote><div><br class=3D""></div><div>Is =
that a reasonably implementation? It sounds like a bug to me. (I =
probably could have phrased my question better as =E2=80=9C are =
network-unfriendly implementations ever acceptable=E2=80=9D.)</div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div =
class=3D"">In short, I think the text is fine as is. &nbsp;<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>I =
disagree. =E2=80=9CNetwork-friendly=E2=80=9D is a condition that =
triggers a SHOULD. I think there=E2=80=99s a high chance you will see =
different implementors interpret that condition differently. If the =
intent is to give normative guidance, there needs to be enough =
information to avoid that. OTOH, if the intent is to point out things an =
implementer needs to think about, then the normative SHOULD may not be =
appropriate.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div=
 class=3D""><div class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">=C2=A79, last paragraph: What are the security implications =
of unused source-buffers? Is this a potential DoS vector?<br =
class=3D""></blockquote><br class=3D"">It could be. &nbsp;Unused source =
buffers combined with potentially large packet size (e.g. for bundled =
protection) could eventually result in a lack of resources (e.g. memory) =
in an endpoint.<br class=3D""><br class=3D"">Proposed additional =
clarifying text: Following &nbsp;"Given that FLEX FEC enables the =
protection of multiple source streams, there exists the possibility that =
multiple source buffers may be created that may not be used" add =
&nbsp;"An attacker could leverage unused source buffers to as a means of =
occupying memory in a FLEX FEC =
endpoint.=E2=80=9D</div></div></blockquote><div><br =
class=3D""></div><div>Works for me.</div><div><br =
class=3D""></div><div>[...]</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D"">- 2nd paragraph: s/Redunadncy/Redundancy=E2=80=9D=
<br class=3D""></blockquote><br class=3D"">Proposed change: =
&nbsp;&nbsp;"Redunadncy" changed to "Redundancy". &nbsp;Thank you for =
catching this.<br class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">=C2=A71.1.1: - It would be helpful to describe what L and D =
represent here, or at least give a forward reference to the definition. =
(I note that a lot of text goes by before you get to the =
&nbsp;definitions or the 2119 boilerplate.)<br class=3D""></blockquote><br=
 class=3D"">Current text states: &nbsp;" Consider a group of D x L =
source packets that have sequence numbers starting from 1 running to D x =
L, and a repair packet is generated by applying the XOR operation to =
every L consecutive packets as sketched in Figure 3."<br class=3D""><br =
class=3D"">I don't think that there is a further definition required. =
&nbsp;However, an addition sentence could follow the above description =
to clarify. <br class=3D""><br class=3D"">Proposed text: &nbsp;"In =
general, D and L represent values that describe how packets are grouped =
together for parity code generation when interleaving all D x L source =
packets.=E2=80=9D</div></div></blockquote><div><br =
class=3D""></div><div>That=E2=80=99s kind of circular explanation. I was =
just looking for something along the lines of =E2=80=98 =E2=80=9CD=E2=80=9D=
 and =E2=80=9CL=E2=80=9D represent the depth and length, =
respectively=E2=80=9D.</div><div><br =
class=3D""></div><div>[...]</div><blockquote type=3D"cite" class=3D""><div=
 class=3D""><div class=3D""><br class=3D""><blockquote type=3D"cite" =
class=3D"">=C2=A74.2.2, paragraph after Figure 10: The text seems to be =
suggest there is one source packet protected by a given repair packet. =
IIUC, that=E2=80=99s not the case; a given FEC packet protects several =
source packets, doesn=E2=80=99t it?<br class=3D""></blockquote><br =
class=3D"">The text reads in part "... includes repair of everything =
following the fixed 12-byte RTP header of the source packet ...". =
&nbsp;<br class=3D""><br class=3D"">"... everything following ..." =
implies more than just a single source RTP packet. &nbsp;<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>Let=E2=80=
=99s say for argument that the repair packet protects 2 source packets. =
Is the 12-byte RTP header of the 2nd packet protected?</div><div><br =
class=3D""></div><div>(Even if the answer is yes, it would be helpful to =
say " ... and subsequent packets...")</div><div><br =
class=3D""></div><div>[...]</div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D""><div class=3D""><blockquote type=3D"cite" =
class=3D"">=C2=A75.2.2, first paragraph: Is there a reason to cite the =
obsolete RFC 2326?<br class=3D""></blockquote><br class=3D"">This also =
came up as part of the I.-D. nits. &nbsp;I decided to leave the 2326 =
reference in because I did not want to imply that FLEX FEC cannot be =
used for RTSP 1.0, and RTSP 2.0 is not backwards-compatible.<br =
class=3D""><br class=3D""></div></div></blockquote><div><br =
class=3D""></div><div>I suggest adding a few words to explain =
that.</div><div><br class=3D""></div><div>[...]</div><div><br =
class=3D""></div><blockquote type=3D"cite" class=3D""><div class=3D""><div=
 class=3D""><br class=3D""><blockquote type=3D"cite" class=3D"">=C2=A79, =
last paragraph: I don=E2=80=99t understand the intent of the last =
sentence.<br class=3D""></blockquote><br class=3D"">Originally suggested =
in <a =
href=3D"https://mailarchive.ietf.org/arch/msg/payload/AIHw5DSABEJLa6lSOLry=
LdI0eBk" =
class=3D"">https://mailarchive.ietf.org/arch/msg/payload/AIHw5DSABEJLa6lSO=
LryLdI0eBk</a>. &nbsp;The application source data may not be perfectly =
matched with FLEX FEC source partitioning. &nbsp;If this is the case, =
there is a possibility for unprotected source data if, for instance, the =
FLEX FEC implementation discards data that does not fit perfectly into =
its source processing requirements.<br =
class=3D""></div></div></blockquote><div><br class=3D""></div><div>That =
explanation is more clear than the text in the draft. I suggest =
including it.</div></div><br class=3D""></div><div =
class=3D"">[...]</div></body></html>=

--Apple-Mail=_325D7088-B091-467D-BB22-7876C8752C0C--

--Apple-Mail=_F802ADD4-BD17-4A4B-8AC4-BAE90E021F92
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlwfGbgACgkQgFZKbJXz
1A2ILhAApqCOpyQvYWIeiD3L8P2+zVq02lFR5XIMEDSAOH8w2u98iknsN/+KcLVT
22c6KLlLWp9jGvh7xKekbLRxirSw2FU1nt96Nedh23DeFtcbPuH66cQ9ESVZV0z8
R1hcykyhPivhOivVBNLXww/gcpycc9GrAV+YKTd5rrORBh6xGGBHR1xzzzFym4N+
euEPMqb3OrZCA01w8M5RFndMmgBTU0IemPmUuCCEE9f3It36ANdcpdEZEIzWYHg4
KgpVCiMJBwwskkbxRmQ4oTkd/nrStgJaX7bJGk3ZGykwa58DLtjYLZGG5xDAxs5A
E780NqDjKeUYyezwniSM40QJV+/LBf5gxqIe/GdnpQuprvDsL4jRJ4A+GPWZGOkb
LBoF0Vj28+sRwirRYlniwoxfN1sW4MT36EgkuEkN62yUZu1TJqyE5oB9oOryuwOl
TFG9QbH9f13aAB3AIpztdYXZaejr6C5uvweB6EEV+h4kEfgfhs27Lwu9B0uHeKUj
YgVtf+Tg6BvHxeX4suElevoAmZPZgMQyg1qJNYzkpgmMUcvTUzMivwLBNQaAch8/
CkPEjI+EHDlnmSTbGCOsYwgrqpODKyf3CEdbEF84Ez4MF9LfwJJz2WPIySMdPGLL
9ltD/YkpjZjLRICfmw2uYi6eHjION4XuucG/x3Efa909rRPdNQw=
=qOrg
-----END PGP SIGNATURE-----

--Apple-Mail=_F802ADD4-BD17-4A4B-8AC4-BAE90E021F92--


From nobody Wed Dec 26 08:40:45 2018
Return-Path: <mandyam@qti.qualcomm.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9151F131051; Wed, 26 Dec 2018 08:40:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JDzMAx0k1C3; Wed, 26 Dec 2018 08:40:39 -0800 (PST)
Received: from alexa-out-sd-01.qualcomm.com (alexa-out-sd-01.qualcomm.com [199.106.114.38]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA11131053; Wed, 26 Dec 2018 08:40:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1545842438; x=1577378438; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3/3tx0rW0buUEV2z3p//rrsVUicYTaAt+dyM+9qPr7g=; b=YNTAM9sZaiVIT+EV+l2sXNNH+DyHcMrAJ1WnxBYLGlg/+819k9ndu74e DMZniLBjMHDsOJmUhHqnQlXriIL5MZ1G5wQU/N9ef4vSU3H/eVtbPs14V oJhExe4B8GZzMUsFvOhQFWboG/atsaTsCewBFB4vXg+O4rhrnM1iGxJZN Q=;
X-IronPort-AV: E=Sophos; i="5.56,401,1539673200"; d="scan'208,217"; a="19495808"
Received: from unknown (HELO ironmsg04-sd.qualcomm.com) ([10.53.140.144]) by alexa-out-sd-01.qualcomm.com with ESMTP; 26 Dec 2018 08:40:37 -0800
Received: from nasanexm01h.na.qualcomm.com ([10.85.0.34]) by ironmsg04-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 26 Dec 2018 08:40:37 -0800
Received: from NASANEXM01C.na.qualcomm.com (10.85.0.83) by NASANEXM01H.na.qualcomm.com (10.85.0.34) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 26 Dec 2018 08:40:36 -0800
Received: from NASANEXM01C.na.qualcomm.com ([10.85.0.83]) by NASANEXM01C.na.qualcomm.com ([10.85.0.83]) with mapi id 15.00.1395.000; Wed, 26 Dec 2018 08:40:36 -0800
From: Giridhar Mandyam <mandyam@qti.qualcomm.com>
To: Ben Campbell <ben@nostrum.com>
CC: "draft-ietf-payload-flexible-fec-scheme.all@ietf.org" <draft-ietf-payload-flexible-fec-scheme.all@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13
Thread-Index: AQHUl1fULReBgVYI4UmKkArmKMKaIqWIRViAgAQO2gCABOFlEA==
Date: Wed, 26 Dec 2018 16:40:36 +0000
Message-ID: <0341aad5c46241edbba503e834f0d098@NASANEXM01C.na.qualcomm.com>
References: <3462BDFF-84C6-4FE5-857D-50B457AF15FE@nostrum.com> <485343397e554f97be3e0a5c9df8ef4d@NASANEXM01C.na.qualcomm.com> <F3D73813-1E03-4413-B2C3-53D57934D44C@nostrum.com>
In-Reply-To: <F3D73813-1E03-4413-B2C3-53D57934D44C@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [199.106.107.6]
Content-Type: multipart/alternative; boundary="_000_0341aad5c46241edbba503e834f0d098NASANEXM01Cnaqualcommco_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/t-JKXuPvIeJ9VDbqw7pDwyc9vfA>
Subject: Re: [payload] AD Evaluation of draft-ietf-payload-flexible-fec-scheme-13
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Dec 2018 16:40:44 -0000

--_000_0341aad5c46241edbba503e834f0d098NASANEXM01Cnaqualcommco_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgcmVzcG9uc2UuDQoNCj4+IEZMRVggRkVDIGNlcnRh
aW5seSB3YXMgaW5zcGlyZWQgYnkgRkVDIEZSQU1FLCBidXQgdGhlIGRvY3VtZW50IGNhbiBzdGFu
ZCBvbiBpdHMgb3duLiAgICBTaW5jZSBzZXZlcmFsIGRlZmluaXRpb25zIGFyZSBsZXZlcmFnZWQg
ZnJvbSBSRkMgNjM2MywgSSBiZWxpZXZlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSBpcyBzdGlsbCBh
cHByb3ByaWF0ZS4gIE15IHN1Z2dlc3Rpb24gaXMgdG8gYWRkIG9uZSBzZW50ZW5jZSB0byB0aGUg
bGFzdCBwYXJhZ3JhcGggb2YgU2VjdGlvbiAxLg0KPj4gUHJvcG9zZWQgY2hhbmdlOiAgQWRkICJU
aGlzIGRvY3VtZW50IGFsc28gbGV2ZXJhZ2VzIHNldmVyYWwgZGVmaW5pdGlvbnMgYWxvbmcgd2l0
aCB0aGUgYmFzaWMgc291cmNlL3JlcGFpciBoZWFkZXIgZGVzY3JpcHRpb24gZnJvbSBSRkMgNjM2
MyBpbiB0aGVpciBhcHBsaWNhdGlvbiB0byB0aGUgcGFyaXR5IGNvZGVzIGRlZmluZWQgaGVyZS7i
gJ0NCg0KPiBUaGF0IGhlbHBzLiBJIG1pZ2h0IHN1Z2dlc3Qgc29tZXRoaW5nIGFsb25nIHRoZSBs
aW5lcyBvZiDigJxXaGlsZSB0aGlzIGRvY3VtZW50IGZ1bGx5IGRlZmluZXMgdGhlIHVzZSBvZiBG
RUMgdG8gcHJvdGVjdCBSVFAgc3RyZWFtcywgaXQgYWxzbyBsZXZlcmFnZXMuLi7igJ0NCg0KTW9k
aWZpZWQgcHJvcG9zZWQgY2hhbmdlOiAg4oCcV2hpbGUgdGhpcyBkb2N1bWVudCBmdWxseSBkZWZp
bmVzIHRoZSB1c2Ugb2YgRkVDIHRvIHByb3RlY3QgUlRQIHN0cmVhbXMsIGl0IGFsc28gbGV2ZXJh
Z2VzIHNldmVyYWwgZGVmaW5pdGlvbnMgYWxvbmcgd2l0aCB0aGUgYmFzaWMgc291cmNlL3JlcGFp
ciBoZWFkZXIgZGVzY3JpcHRpb24gZnJvbSBSRkMgNjM2MyBpbiB0aGVpciBhcHBsaWNhdGlvbiB0
byB0aGUgcGFyaXR5IGNvZGVzIGRlZmluZWQgaGVyZS7igJ0NCg0KPj4+NC4yLjE6IC0gVGhlcmXi
gJlzIGEgbnVtYmVyIG9mIDIxMTkvODE3NCBrZXl3b3JkcyBpbiB0aGlzIHNlY3Rpb24gdGhhdCBz
ZWVtIG1vcmUgbmF0dXJhbCBjb25zZXF1ZW5jZXMgb2YgdXNpbmcgUlRQIHRoYW4gbmV3IG5vcm1h
dGl2ZSByZXF1aXJlbWVudHMuIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZXkgc2hvdWxkbuKAmXQg
dXNlIG5vcm1hdGl2ZSBrZXl3b3JkcyB1bmxlc3MgaW4gdGhlIGZvcm0gb2YgZGlyZWN0IHF1b3Rl
cy4NCj4+IEFwb2xvZ2llcyAtIEkgaGFkIHRyb3VibGUgaWRlbnRpZnlpbmcgc3VjaCBpbnN0YW5j
ZXMuICBBbGwgaW5zdGFuY2VzIG9mIHN1Y2gga2V5d29yZHMgYXJlIHJlbGF0ZWQgdG8gcmVxdWly
ZW1lbnRzIHdpdGggcmVzcGVjdCB0byBSRkMgMzU1MC4gIERvIHlvdSBoYXZlIHNwZWNpZmljIGV4
YW1wbGVzPw0KDQo+LSBkZWZpbml0aW9uIG9mIHNlcXVlbmNlIG51bWJlci4gRG9lc27igJl0IFJU
UCBhbHJlYWR5IHJlcXVpcmUgdGhlIHNlcXVlbmNlIG51bWJlciB0byBpbmNyZW1lbnQgYnkgb25l
LCBhbmQgcmVjb21tZW5kIHRoZSB1c2Ugb2YgYSByYW5kb20gc3RhcnRpbmcgdmFsdWU/DQoNClBy
b3Bvc2VkIGNoYW5nZTogIOKAnFNlcXVlbmNlIE51bWJlciAoU04pOiBUaGUgc2VxdWVuY2UgbnVt
YmVyIGZvbGxvd3MgdGhlIHN0YW5kYXJkIGRlZmluaXRpb24gcHJvdmlkZWQgaW4gW1JGQzM1NTBd
LiBUaGVyZWZvcmUgaXQgbXVzdCBiZSBvbmUgaGlnaGVyIHRoYW4gdGhlIHNlcXVlbmNlIG51bWJl
ciBpbiB0aGUgcHJldmlvdXNseSB0cmFuc21pdHRlZCByZXBhaXIgcGFja2V0LCBhbmQgdGhlIGlu
aXRpYWwgdmFsdWUgb2YgdGhlIHNlcXVlbmNlIG51bWJlciBzaG91bGQgYmUgcmFuZG9tIChpLmUu
IHVucHJlZGljdGFibGUpLuKAnQ0KDQo+LSBTU1JDOiAzNTUwIGFscmVhZHkgc2F5cyBTU1JDcyBT
SE9VTEQgYmUgYXNzaWduZWQgcmFuZG9tbHksIHNvIHRoZSByZXF1aXJlbWVudCBpcyBhIHN0YXRl
bWVudCBvZiBmYWN0IGFzIGZhciBhcyBfdGhpc18gc3BlYyBpcyBjb25jZXJuZWQuIChUaGUgdGV4
dCBldmVuIG1lbnRpb25zIOKAnGFzIHN1Z2dlc3RlZCBieSBSRkMgMzM1MCIsIGFsdGhvdWdoIDM1
NTAgZG9lcyBtb3JlIHRoYW4g4oCcc3VnZ2VzdOKAnSBpdC4pDQoNClNlY3Rpb24gOCBvZiBSRkMg
MzU1MCBkb2VzIG5vdCB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIHN1Y2ggYXMgTVVTVCBvciBTSEFM
TCwgYnV0IHRoZSBleGlzdGluZyB0ZXh0IGNhbiBzdGFuZCB0byBiZSBjbGFyaWZpZWQuDQoNClBy
b3Bvc2VkIGNoYW5nZTogIOKAnFN5bmNocm9uaXphdGlvbiBTb3VyY2UgKFNTUkMpOiBUaGUgU1NS
QyB2YWx1ZSBmb3IgZWFjaCByZXBhaXIgc3RyZWFtIFNIQUxMIGJlIHJhbmRvbWx5IGFzc2lnbmVk
IGFzIHBlciB0aGUgZ3VpZGVsaW5lcyBvZiBTZWN0aW9uIDggb2YgW1JGQzM1NTBdLiDigKbigJ0N
Cg0KPi0gInRoZSBjb2xsaXNpb25zIE1VU1QgYmUgcmVzb2x2ZWQgYXMgZGVzY3JpYmVkIGluIFtS
RkMzNTUwXeKAnSA6IGFnYWluLCB0aGF0IGZvbGxvd3MgbmF0dXJhbGx5IGZyb20gdXNpbmcgUlRQ
LiBJdCBkb2VzIG5vdCBkZWZpbmUgYSBuZXcgcmVxdWlyZW1lbnQuDQoNClByb3Bvc2VkIGNoYW5n
ZTogIOKAnOKApiB0aGUgY29sbGlzaW9ucyBtdXN0IGJlIHJlc29sdmVkIGFzIGRlc2NyaWJlZCBp
biDigKbigJ0NCg0KPj4+LSAxMHRoIHBhcmFncmFwaDogIlRoZSByZXBhaXIgc3RyZWFtc+KAmSBT
U1JD4oCZcyBDTkFNRSBTSE9VTEQgYmUgaWRlbnRpY2FsIHRvIHRoZSBDTkFNRSBvZiB0aGUgc291
cmNlIFJUUCBzdHJlYW0ocykgdGhhdCB0aGlzIHJlcGFpciBzdHJlYW0gcHJvdGVjdHMu4oCdIFdo
eSBpcyB0aGUgU0hPVUxEIG5vdCBhIE1VU1Q/IFdoYXQgaGFwcGVucyBpZiBpdCBpcyB2aW9sYXRl
ZD8NCg0KPj5Qcm9wb3NlZCBjaGFuZ2U6ICBBZ3JlZWQgdGhhdCB0aGUgcmVxdWlyZW1lbnQgbWFr
ZXMgbW9yZSBzZW5zZSBhcyBhIE1VU1QuICBXaWxsIGNoYW5nZSBhY2NvcmRpbmdseS4NCg0KPkkg
Y29uY3VyIHdpdGggdGhlIGNoYW5nZSwgYnV0IGl0IGlzIGEgbWF0ZXJpYWwgY2hhbmdlLiBQbGVh
c2UgcG9pbnQgaXQgb3V0IHRvIHRoZSBXRyBpbiBjYXNlIGFueW9uZSBvYmplY3RzLiAoSXQgbWF5
IG5vdCBiZSBzYWZlIHRvIGFzc3VtZSBwZW9wbGUgYXJlIHJlYWRpbmcgdGhpcyBub3RlIGluIHRo
YXQgbGV2ZWwgb2YgZGV0YWlsLCBlc3BlY2lhbGx5IG92ZXIgdGhlIGhvbGlkYXlzIDotKSkgVG8g
YmUgY2xlYXIsIEkgZG9u4oCZdCB3YW50IHRvIGJsb2NrIHByb2dyZXNzIG9mIHRoZSBkcmFmdCBv
dmVyIGl0OyBpZiBhbnlvbmUgb2JqZWN0cyB0aGV5IGNhbiBkbyBzbyBhcyBwYXJ0IG9mIHRoZSBJ
RVRGIGxhc3QgY2FsbC4NCg0KSSB3aWxsIHBvaW50IHRoaXMgb3V0IGluIGEgZm9sbG93LW9uIGVt
YWlsIHRvIHRoZSBXRyBsaXN0IGFmdGVyIEkgc3VibWl0IHRoZSBuZXh0IHJldmlzaW9uLg0KDQo+
Pj7CpzQuMi4yOiBQbGVhc2UgYWRkIGEgc2hvcnQgZXhwbGFuYXRpb24gb2Ygd2h5IHdlIG5lZWQg
dHdvIGRpZmZlcmVudCBGRUMgcGFja2V0IGZvcm1hdHMuIChOb3QgY291bnRpbmcgdGhlIHJldHJh
bnNtaXNzaW9uIHBhY2tldDsgdGhlIHJlYXNvbmluZyB0aGVyZSBpcyBwcmV0dHkgb2J2aW91cy4p
DQoNCj4+UHJvcG9zZWQgY2hhbmdlOiAgQWRkIGFkZGl0aW9uYWwgc2VudGVuY2UgdG8gZmlyc3Qg
cGFyYWdyYXBoIG9mIFNlYy4gNC4yLjI6ICAiVHdvIG9mIHRoZXNlIHZhcmlhbnRzIGFyZSBtZWFu
dCB0byBkZXNjcmliZSBkaWZmZXJlbnQgbWV0aG9kcyBmb3IgZGVyaXZpbmcgdGhlIHNvdXJjZSBk
YXRhIGZyb20gYSBzb3VyY2UgcGFja2V0IGZvciBhIHJlcGFpciBwYWNrZXQuICBUaGUgdGhpcmQg
dmFyaWFudCBpcyBmb3IgYSBzdHJhaWdodCByZXRyYW5zbWlzc2lvbiBvZiB0aGUgc291cmNlIHBh
Y2tldC7igJ0NCg0KPlRoYXTigJlzIHVzZWZ1bCwgYnV0IGl0IGRvZXNu4oCZdCBleHBsYWluIF93
aHlfIHdlIG5lZWQgdHdvIGRpZmZlcmVudCBtZXRob2RzLg0KDQpNb2RpZmllZCBwcm9wb3NlZCBj
aGFuZ2U6ICBBZGQgYWRkaXRpb25hbCBzZW50ZW5jZXMgdG8gZmlyc3QgcGFyYWdyYXBoIG9mIFNl
Yy4gNC4yLjI6ICAiVHdvIG9mIHRoZXNlIHZhcmlhbnRzIGFyZSBtZWFudCB0byBkZXNjcmliZSBk
aWZmZXJlbnQgbWV0aG9kcyBmb3IgZGVyaXZpbmcgdGhlIHNvdXJjZSBkYXRhIGZyb20gYSBzb3Vy
Y2UgcGFja2V0IGZvciBhIHJlcGFpciBwYWNrZXQuICBUaGlzIGFsbG93cyBmb3IgY3VzdG9taXpp
bmcgdGhlIEZFQyBtZXRob2QgdG8gYWxsb3cgZm9yIHJvYnVzdG5lc3MgYWdhaW5zdCBkaWZmZXJl
bnQgbGV2ZWxzIG9mIGJ1cnN0IGVycm9ycyBhbmQgcmFuZG9tIHBhY2tldCBsb3NzZXMuICBUaGUg
dGhpcmQgdmFyaWFudCBpcyBmb3IgYSBzdHJhaWdodCByZXRyYW5zbWlzc2lvbiBvZiB0aGUgc291
cmNlIHBhY2tldC7igJ0NCg0KPj4+wqc1LjEuMSAoYW5kIHN1YnNlcXVlbnQgbWVkaWEgdHlwZSBk
ZWZpbml0aW9ucykgLSBQbGVhc2UgY29uc2lkZXIgdXNpbmcgdGhlIElFU0cgKGllc2dAaWV0Zi5v
cmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+KSBhcyB0aGUgY29udGFjdCBmb3IgZnVydGhlciBpbmZv
cm1hdGlvbi4gV29ya2luZyBncm91cHMgY29tZSBhbmQgZ28sIGFuZCBhdXRob3JzIGNoYW5nZSBq
b2JzLiBCdXQgc29tZW9uZSBvbiB0aGUgSUVTRyBzaG91bGQgKGhvcGVmdWxseSkgYWx3YXlzIGJl
IGFibGUgdG8gZmluZCB0aGUgcmlnaHQgcGVyc29uLA0KDQo+PlRFTlRBVElWRSBwcm9wb3NlZCBj
aGFuZ2U6ICBJIGFtIGhhcHB5IHRvIHN3YXAgb3V0IFZhcnVuJ3MgZW1haWwgZm9yIElFU0csIGJ1
dCB0aGlzIGRvZXMgbm90IHNlZW0gdG8gYmUgYSB3aWRlc3ByZWFkIHByYWN0aWNlIGV2ZW4gZm9y
IHJlY2VudGx5LXB1Ymxpc2hlZCBSRkMncy4gIENhbiB5b3UgY29uZmlybSB0aGF0IHRoaXMgaXMg
bm93IGJlY29taW5nIGEgYmVzdCBwcmFjdGljZSBmb3IgY29udGFjdCBpbmZvIHJlZ2FyZGluZyBy
ZWdpc3RyaWVzPw0KDQo+SXTigJlzIGJlZW4gY29tbW9uIG9mIGxhdGUuIFRoZSByZWFzb25pbmcg
aXMgdGhhdCB0aGUgSUVTRyBlbWFpbCBhZGRyZXNzIGlzIHRoZSBsZWFzdCBsaWtlbHkgdG8gY2hh
bmdlIG9mIGFueSBjb250YWN0IHdlIG1pZ2h0IGdpdmUuDQoNClByb3Bvc2VkIGNoYW5nZTogU3dh
cCBvdXQgcGVyc29uYWwgZW1haWwgY29udGFjdChzKSBmb3IgSUVTRyBhZGRyZXNzLg0KDQo+Pj4t
IENoYW5nZSBjb250cm9sOiAgSW4gNS4xLjEsIHNob3VsZG7igJl0IHRoYXQgYmUgdGhlIFBBWUxP
QUQgd29ya2luZyBncm91cCAob3IgaXTigJlzIHN1Y2Nlc3NvciBhcyBkZWxlZ2F0ZWQgYnkgdGhl
IElFU0cuLi4pDQoNCj4+UHJvcG9zZWQgY2hhbmdlOiAgQ2hhbmdlIHRvICJJRVRGIEF1ZGlvL1Zp
ZGVvIFBheWxvYWRzIFRyYW5zcG9ydCBQYXlsb2FkcyBXb3JraW5nIEdyb3Vw4oCdDQoNCj5JIHN1
Z2dlc3QgYWRkaW5nIOKAnC4uLiBvciBpdOKAmXMgc3VjY2Vzc29yIGFzIGRlbGVnYXRlZCBieSB0
aGUgSUVTRy4NCg0KTW9kaWZpZWQgcHJvcG9zZWQgY2hhbmdlOiAgQ2hhbmdlIHRvIOKAnElFVEYg
QXVkaW8vVmlkZW8gUGF5bG9hZHMgVHJhbnNwb3J0IFBheWxvYWRzIFdvcmtpbmcgR3JvdXAgb3Ig
aXRzIHN1Y2Nlc3NvciBhcyBkZXNpZ25hdGVkIGJ5IHRoZSBJRVNH4oCdDQoNCj4+Pi0gQXJlIHRo
ZXNlIHJlZ2lzdHJhdGlvbnMgcmVhbGx5IGludGVuZGVkIHRvIGJlIHByb3Zpc2lvbmFsPw0KDQo+
PkF0IHRoaXMgcG9pbnQsIG5vLg0KPj5Qcm9wb3NlZCBjaGFuZ2U6ICBFbGltaW5hdGUgbWVudGlv
biBvZiBwcm92aXNpb25hbCByZWdpc3RyYXRpb24gZm9yIGFsbCBtZWRpYSB0eXBlcy4NCg0KPkkg
YWdyZWUuIEhvd2V2ZXIgdGhpcyBpcyBhbm90aGVyIG1hdGVyaWFsIGNoYW5nZSB0aGF0IHNob3Vs
ZCBiZSBwb2ludGVkIG91dCB0byB0aGUgV0cuDQoNCkkgd2lsbCBwb2ludCB0aGlzIG91dCBpbiBh
IGZvbGxvdy1vbiBlbWFpbCB0byB0aGUgV0cgbGlzdCBhZnRlciBJIHN1Ym1pdCB0aGUgbmV4dCBy
ZXZpc2lvbi4NCg0KPj4+LSDigJxJbiBhIG5ldHdvcmstZnJpZW5kbHkgaW1wbGVtZW50YXRpb27i
gJ06IERvIHlvdSBleHBlY3QgdG8gc2VlIG5ldHdvcmstdW5mcmllbmRseSBpbXBsZW1lbnRhdGlv
bnM/IElzIHRoYXQgb2theT8NCg0KPj5JIGRvbid0IHZpZXcgIm5ldHdvcmstZnJpZW5kbHkiIGFz
IGJlaW5nIGEgc3RhdGljIGNvbmRpdGlvbi4gIFRoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgYW4g
RkVDIHRyYW5zbWl0dGVyL3JlY2VpdmVyIHBhaXIgaGF2ZSBuZWdvdGlhdGVkIGEgY29ubmVjdGlv
biB3aGljaCBpcyBuZXR3b3JrLWZyaWVuZGx5IGZvciBvbmUgYXBwbGljYXRpb24sIGJ1dCBtYXkg
bm90IGJlIGZvciBhIGRpZmZlcmVudCBhcHBsaWNhdGlvbi4gIFRoZXJlIHdhcyBhIGRpc2N1c3Np
b24gYWJvdXQgd2hlbiBGRUMgaXMgYXBwcm9wcmlhdGUgYW5kIHdoZW4gaXQgaXMgbm90IG9uIHRo
ZSBXZWJSVEMgbWFpbGluZyBsaXN0cyAtIHNlZSBodHRwczovL2xpc3RzLnczLm9yZy9BcmNoaXZl
cy9QdWJsaWMvcHVibGljLXdlYnJ0Yy8yMDE4Tm92LzAxNTYuaHRtbC4gICAiTmV0d29yay11bmZy
aWVuZGx5IiBpbXBsZW1lbnRhdGlvbnMgY291bGQgY29uY2VpdmFibHkgb2NjdXIgd2hlbiBhbiBG
RUMgc2Vzc2lvbiBoYXMgYmVlbiBuZWdvdGlhdGVkIGJldHdlZW4gZW5kcG9pbnRzLCBidXQgbmVp
dGhlciBlbmRwb2ludCBoYXMgYXNzZXNzZWQgdHJhbnNtaXNzaW9uIGNvbmRpdGlvbnMuDQoNCj5J
cyB0aGF0IGEgcmVhc29uYWJseSBpbXBsZW1lbnRhdGlvbj8gSXQgc291bmRzIGxpa2UgYSBidWcg
dG8gbWUuIChJIHByb2JhYmx5IGNvdWxkIGhhdmUgcGhyYXNlZCBteSBxdWVzdGlvbiBiZXR0ZXIg
YXMg4oCcIGFyZSBuZXR3b3JrLXVuZnJpZW5kbHkgaW1wbGVtZW50YXRpb25zIGV2ZXIgYWNjZXB0
YWJsZeKAnS4pDQoNCj4+SW4gc2hvcnQsIEkgdGhpbmsgdGhlIHRleHQgaXMgZmluZSBhcyBpcy4N
Cg0KPkkgZGlzYWdyZWUuIOKAnE5ldHdvcmstZnJpZW5kbHnigJ0gaXMgYSBjb25kaXRpb24gdGhh
dCB0cmlnZ2VycyBhIFNIT1VMRC4gSSB0aGluayB0aGVyZeKAmXMgYSBoaWdoIGNoYW5jZSB5b3Ug
d2lsbCBzZWUgZGlmZmVyZW50IGltcGxlbWVudG9ycyBpbnRlcnByZXQgdGhhdCBjb25kaXRpb24g
ZGlmZmVyZW50bHkuIElmIHRoZSBpbnRlbnQgaXMgdG8gZ2l2ZSBub3JtYXRpdmUgZ3VpZGFuY2Us
IHRoZXJlIG5lZWRzIHRvIGJlIGVub3VnaCBpbmZvcm1hdGlvbiB0byBhdm9pZCB0aGF0LiBPVE9I
LCBpZiB0aGUgaW50ZW50IGlzIHRvIHBvaW50IG91dCB0aGluZ3MgYW4gaW1wbGVtZW50ZXIgbmVl
ZHMgdG8gdGhpbmsgYWJvdXQsIHRoZW4gdGhlIG5vcm1hdGl2ZSBTSE9VTEQgbWF5IG5vdCBiZSBh
cHByb3ByaWF0ZS4NCg0KWWVzLCBJIGFncmVlIHdpdGggeW91ciBpbnRlcnByZXRhdGlvbi4NCg0K
UHJvcG9zZWQgY2hhbmdlOiAg4oCcSW4gYSBuZXR3b3JrLWZyaWVuZGx5IGltcGxlbWVudGF0aW9u
LCBhbiBhcHBsaWNhdGlvbiBzaG91bGQgYXZvaWQgc2VuZGluZy9yZWNlaXZpbmcgRkVDIHJlcGFp
ciBzdHJlYW1zIGlmIGl0IGtub3dzIHRoYXQgc2VuZGluZy9yZWNlaXZpbmcgdGhvc2UgRkVDIHJl
cGFpciBzdHJlYW1zIHdvdWxkIG5vdCBoZWxwIGF0IGFsbCBpbiByZWNvdmVyaW5nIHRoZSBtaXNz
aW5nIHBhY2tldHMu4oCdDQoNCkVuc3VpbmcgbGFuZ3VhZ2Ugb24gUkVDT01NRU5ERUQgcHJhY3Rp
Y2VzIGNhbiByZW1haW4gdW5jaGFuZ2VkLg0KDQoNCj4+PsKnMS4xLjE6IC0gSXQgd291bGQgYmUg
aGVscGZ1bCB0byBkZXNjcmliZSB3aGF0IEwgYW5kIEQgcmVwcmVzZW50IGhlcmUsIG9yIGF0IGxl
YXN0IGdpdmUgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0aGUgZGVmaW5pdGlvbi4gKEkgbm90ZSB0
aGF0IGEgbG90IG9mIHRleHQgZ29lcyBieSBiZWZvcmUgeW91IGdldCB0byB0aGUgIGRlZmluaXRp
b25zIG9yIHRoZSAyMTE5IGJvaWxlcnBsYXRlLikNCg0KPj5DdXJyZW50IHRleHQgc3RhdGVzOiAg
IiBDb25zaWRlciBhIGdyb3VwIG9mIEQgeCBMIHNvdXJjZSBwYWNrZXRzIHRoYXQgaGF2ZSBzZXF1
ZW5jZSBudW1iZXJzIHN0YXJ0aW5nIGZyb20gMSBydW5uaW5nIHRvIEQgeCBMLCBhbmQgYSByZXBh
aXIgcGFja2V0IGlzIGdlbmVyYXRlZCBieSBhcHBseWluZyB0aGUgWE9SIG9wZXJhdGlvbiB0byBl
dmVyeSBMIGNvbnNlY3V0aXZlIHBhY2tldHMgYXMgc2tldGNoZWQgaW4gRmlndXJlIDMuIg0KPj5J
IGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBmdXJ0aGVyIGRlZmluaXRpb24gcmVxdWlyZWQu
ICBIb3dldmVyLCBhbiBhZGRpdGlvbiBzZW50ZW5jZSBjb3VsZCBmb2xsb3cgdGhlIGFib3ZlIGRl
c2NyaXB0aW9uIHRvIGNsYXJpZnkuDQo+PlByb3Bvc2VkIHRleHQ6ICAiSW4gZ2VuZXJhbCwgRCBh
bmQgTCByZXByZXNlbnQgdmFsdWVzIHRoYXQgZGVzY3JpYmUgaG93IHBhY2tldHMgYXJlIGdyb3Vw
ZWQgdG9nZXRoZXIgZm9yIHBhcml0eSBjb2RlIGdlbmVyYXRpb24gd2hlbiBpbnRlcmxlYXZpbmcg
YWxsIEQgeCBMIHNvdXJjZSBwYWNrZXRzLuKAnQ0KDQo+VGhhdOKAmXMga2luZCBvZiBjaXJjdWxh
ciBleHBsYW5hdGlvbi4gSSB3YXMganVzdCBsb29raW5nIGZvciBzb21ldGhpbmcgYWxvbmcgdGhl
IGxpbmVzIG9mIOKAmCDigJxE4oCdIGFuZCDigJxM4oCdIHJlcHJlc2VudCB0aGUgZGVwdGggYW5k
IGxlbmd0aCwgcmVzcGVjdGl2ZWx54oCdLg0KDQpQcm9wb3NlZCBjaGFuZ2U6ICBBZGQgZm9sbG93
aW5nIHNlbnRlbmNlIOKAkyDigJxJbiBnZW5lcmFsIEQgYW5kIEwgcmVwcmVzZW50IHZhbHVlcyB0
aGF0IGRlc2NyaWJlIGhvdyBwYWNrZXRzIGFyZSBncm91cGVkIHRvZ2V0aGVyIGZyb20gYSBkZXB0
aCBhbmQgbGVuZ3RoIHBlcnNwZWN0aXZlIChyZXNwZWN0aXZlbHkpIHdoZW4gaW50ZXJsZWF2aW5n
IGFsbCBEIHggTCBzb3VyY2UgcGFja2V0cy7igJ0NCg0KPj4+wqc0LjIuMiwgcGFyYWdyYXBoIGFm
dGVyIEZpZ3VyZSAxMDogVGhlIHRleHQgc2VlbXMgdG8gYmUgc3VnZ2VzdCB0aGVyZSBpcyBvbmUg
c291cmNlIHBhY2tldCBwcm90ZWN0ZWQgYnkgYSBnaXZlbiByZXBhaXIgcGFja2V0LiBJSVVDLCB0
aGF04oCZcyBub3QgdGhlIGNhc2U7IGEgZ2l2ZW4gRkVDIHBhY2tldCBwcm90ZWN0cyBzZXZlcmFs
IHNvdXJjZSBwYWNrZXRzLCBkb2VzbuKAmXQgaXQ/DQoNCj4+VGhlIHRleHQgcmVhZHMgaW4gcGFy
dCAiLi4uIGluY2x1ZGVzIHJlcGFpciBvZiBldmVyeXRoaW5nIGZvbGxvd2luZyB0aGUgZml4ZWQg
MTItYnl0ZSBSVFAgaGVhZGVyIG9mIHRoZSBzb3VyY2UgcGFja2V0IC4uLiIuDQo+PiIuLi4gZXZl
cnl0aGluZyBmb2xsb3dpbmcgLi4uIiBpbXBsaWVzIG1vcmUgdGhhbiBqdXN0IGEgc2luZ2xlIHNv
dXJjZSBSVFAgcGFja2V0Lg0KDQo+TGV04oCZcyBzYXkgZm9yIGFyZ3VtZW50IHRoYXQgdGhlIHJl
cGFpciBwYWNrZXQgcHJvdGVjdHMgMiBzb3VyY2UgcGFja2V0cy4gSXMgdGhlIDEyLWJ5dGUgUlRQ
IGhlYWRlciBvZiB0aGUgMm5kIHBhY2tldCBwcm90ZWN0ZWQ/DQo+KEV2ZW4gaWYgdGhlIGFuc3dl
ciBpcyB5ZXMsIGl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gc2F5ICIgLi4uIGFuZCBzdWJzZXF1ZW50
IHBhY2tldHMuLi4iKQ0KDQpBcyBwZXIgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIFNlYy4gNC4xOiAg
IlRoZSBzb3VyY2UgcGFja2V0cyBhcmUgZnVsbCBSVFAgcGFja2V0cyB3aXRoIG9wdGlvbmFsIENT
UkMgbGlzdCwgUlRQIGhlYWRlciBleHRlbnNpb24sIGFuZCBwYWRkaW5nLiBJZiBhbnkgb2YgdGhl
c2Ugb3B0aW9uYWwgZWxlbWVudHMgYXJlIHByZXNlbnQgaW4gdGhlIHNvdXJjZSBSVFAgcGFja2V0
LCBhbmQgdGhhdCBzb3VyY2UgcGFja2V0IGlzIGxvc3QsIHRoZXkgYXJlIHJlY292ZXJlZCBieSB0
aGUgRkVDIHJlcGFpciBvcGVyYXRpb24sIHdoaWNoIHJlY292ZXJzIHRoZSBmdWxsIHNvdXJjZSBS
VFAgcGFja2V0IGluY2x1ZGluZyB0aGVzZSBvcHRpb25hbCBlbGVtZW50cy7igJ0NCg0KUHJvcG9z
ZWQgY2hhbmdlOiAgQ2hhbmdlIOKAnC4uLiBpbmNsdWRlcyByZXBhaXIgb2YgZXZlcnl0aGluZyBm
b2xsb3dpbmcgdGhlIGZpeGVkIDEyLWJ5dGUgUlRQIGhlYWRlciBvZiB0aGUgc291cmNlIHBhY2tl
dCAuLi4iIHRvIOKAnC4uLiBpbmNsdWRlcyByZXBhaXIgb2YgZXZlcnl0aGluZyBmb2xsb3dpbmcg
dGhlIGZpeGVkIDEyLWJ5dGUgUlRQIGhlYWRlciBvZiB0aGUgc291cmNlIHBhY2tldCBhbG9uZyB3
aXRoIHN1YnNlcXVlbnQgc291cmNlIHBhY2tldHMgLi4uIg0KDQo+Pj7CpzksIGxhc3QgcGFyYWdy
YXBoOiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgaW50ZW50IG9mIHRoZSBsYXN0IHNlbnRlbmNl
Lg0KDQo+Pk9yaWdpbmFsbHkgc3VnZ2VzdGVkIGluIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v
cmcvYXJjaC9tc2cvcGF5bG9hZC9BSUh3NURTQUJFSkxhNmxTT0xyeUxkSTBlQmsuICBUaGUgYXBw
bGljYXRpb24gc291cmNlIGRhdGEgbWF5IG5vdCBiZSBwZXJmZWN0bHkgbWF0Y2hlZCB3aXRoIEZM
RVggRkVDIHNvdXJjZSBwYXJ0aXRpb25pbmcuICBJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVyZSBp
cyBhIHBvc3NpYmlsaXR5IGZvciB1bnByb3RlY3RlZCBzb3VyY2UgZGF0YSBpZiwgZm9yIGluc3Rh
bmNlLCB0aGUgRkxFWCBGRUMgaW1wbGVtZW50YXRpb24gZGlzY2FyZHMgZGF0YSB0aGF0IGRvZXMg
bm90IGZpdCBwZXJmZWN0bHkgaW50byBpdHMgc291cmNlIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRz
Lg0KDQo+VGhhdCBleHBsYW5hdGlvbiBpcyBtb3JlIGNsZWFyIHRoYW4gdGhlIHRleHQgaW4gdGhl
IGRyYWZ0LiBJIHN1Z2dlc3QgaW5jbHVkaW5nIGl0Lg0KDQpQcm9wb3NlZCBjaGFuZ2U6ICBSZXBs
YWNlIOKAnEluIGFkZGl0aW9uLCB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBhIEZMRVggRkVDIGlt
cGxlbWVudGF0aW9uIGFuZCBoaWdoZXItbGF5ZXIgYXBwbGljYXRpb25zIG1heSBiZSBhZmZlY3Rl
ZCBieSBub24tdW5pZm9ybSBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cyBvZiB0aGUgRkVDIHNjaGVt
ZeKAnSB3aXRoIOKAnE1vcmVvdmVyIHRoZSBhcHBsaWNhdGlvbiBzb3VyY2UgZGF0YSBtYXkgbm90
IGJlIHBlcmZlY3RseSBtYXRjaGVkIHdpdGggRkxFWCBGRUMgc291cmNlIHBhcnRpdGlvbmluZy4g
IElmIHRoaXMgaXMgdGhlIGNhc2UsIHRoZXJlIGlzIGEgcG9zc2liaWxpdHkgZm9yIHVucHJvdGVj
dGVkIHNvdXJjZSBkYXRhIGlmLCBmb3IgaW5zdGFuY2UsIHRoZSBGTEVYIEZFQyBpbXBsZW1lbnRh
dGlvbiBkaXNjYXJkcyBkYXRhIHRoYXQgZG9lcyBub3QgZml0IHBlcmZlY3RseSBpbnRvIGl0cyBz
b3VyY2UgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMu4oCdDQoNClRoYW5rcywNCg0KLUdpcmkgTWFu
ZHlhbQ0KDQoNCkZyb206IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPg0KU2VudDogU2F0
dXJkYXksIERlY2VtYmVyIDIyLCAyMDE4IDk6MTUgUE0NClRvOiBHaXJpZGhhciBNYW5keWFtIDxt
YW5keWFtQHF0aS5xdWFsY29tbS5jb20+DQpDYzogZHJhZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxl
LWZlYy1zY2hlbWUuYWxsQGlldGYub3JnOyBwYXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSZTog
QUQgRXZhbHVhdGlvbiBvZiBkcmFmdC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZS0x
Mw0KDQpIaSwgdGhhbmtzIGZvciB0aGUgcXVpY2sgcmVzcG9uc2UhIENvbW1lbnRzIGlubGluZS4g
SSByZW1vdmVkIHNlY3Rpb25zIHRoYXQgc2VlbSByZXNvbHZlZC4NCg0KQmVuLg0KDQoNCk9uIERl
YyAyMiwgMjAxOCwgYXQgNzozOCBQTSwgR2lyaWRoYXIgTWFuZHlhbSA8bWFuZHlhbUBxdGkucXVh
bGNvbW0uY29tPG1haWx0bzptYW5keWFtQHF0aS5xdWFsY29tbS5jb20+PiB3cm90ZToNCg0KVGhh
bmsgeW91IGZvciB0aGUgY2FyZWZ1bCByZXZpZXcuICBCZWZvcmUgc3VibWl0dGluZyByZXYgMTQs
IEkgd291bGQgbGlrZSB0byBnZXQgYWdyZWVtZW50IG9uIHRoZSBmb2xsb3dpbmcgcHJvcG9zZWQg
Y2hhbmdlcy4NCi1HaXJpDQoNCg0KR2VuZXJhbDogRG8gSSByZWFkIGNvcnJlY3RseSB0aGF0IHRo
aXMgZG9jdW1lbnQgY2FuIGNvbXBsZXRlbHkgc3RhbmQgYWxvbmUgZnJvbSBSRkMgNjM2Mz8gVGhh
dCBpcywgdGhlIGNhbGN1bGF0aW9uIG9mIHRoZSBwcm90ZWN0aW9uIHN0cmVhbSBhbmQgcmVjb25z
dHJ1Y3Rpb24gb2YgbG9zdCBzb3VyY2UgcGFja2V0cyBpcyBjb21wbGV0ZWx5IHNwZWNpZmllZCBp
biB0aGlzIGRvY3VtZW50PyBJIGRvbuKAmXQgc2VlIHRoYXQgYXMgYSBwcm9ibGVtLCBidXQgaWYg
aXTigJlzIGNvcnJlY3Qgc29tZSBpbnRyb2R1Y3Rpb24gdGV4dCB0byB0aGF0IGVmZmVjdCB3b3Vs
ZCBiZSBoZWxwZnVsLiBJcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gNjM2MyBldmVuIG5lZWRl
ZD8NCg0KRkxFWCBGRUMgY2VydGFpbmx5IHdhcyBpbnNwaXJlZCBieSBGRUMgRlJBTUUsIGJ1dCB0
aGUgZG9jdW1lbnQgY2FuIHN0YW5kIG9uIGl0cyBvd24uICAgIFNpbmNlIHNldmVyYWwgZGVmaW5p
dGlvbnMgYXJlIGxldmVyYWdlZCBmcm9tIFJGQyA2MzYzLCBJIGJlbGlldmUgYSBub3JtYXRpdmUg
cmVmZXJlbmNlIGlzIHN0aWxsIGFwcHJvcHJpYXRlLiAgTXkgc3VnZ2VzdGlvbiBpcyB0byBhZGQg
b25lIHNlbnRlbmNlIHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDEuDQoNClByb3Bv
c2VkIGNoYW5nZTogIEFkZCAiVGhpcyBkb2N1bWVudCBhbHNvIGxldmVyYWdlcyBzZXZlcmFsIGRl
ZmluaXRpb25zIGFsb25nIHdpdGggdGhlIGJhc2ljIHNvdXJjZS9yZXBhaXIgaGVhZGVyIGRlc2Ny
aXB0aW9uIGZyb20gUkZDIDYzNjMgaW4gdGhlaXIgYXBwbGljYXRpb24gdG8gdGhlIHBhcml0eSBj
b2RlcyBkZWZpbmVkIGhlcmUu4oCdDQoNClRoYXQgaGVscHMuIEkgbWlnaHQgc3VnZ2VzdCBzb21l
dGhpbmcgYWxvbmcgdGhlIGxpbmVzIG9mIOKAnFdoaWxlIHRoaXMgZG9jdW1lbnQgZnVsbHkgZGVm
aW5lcyB0aGUgdXNlIG9mIEZFQyB0byBwcm90ZWN0IFJUUCBzdHJlYW1zLCBpdCBhbHNvIGxldmVy
YWdlcy4uLuKAnQ0KDQpbLi4uXQ0KDQoNCsKnNC4yLjE6DQotIFRoZXJl4oCZcyBhIG51bWJlciBv
ZiAyMTE5LzgxNzQga2V5d29yZHMgaW4gdGhpcyBzZWN0aW9uIHRoYXQgc2VlbSBtb3JlIG5hdHVy
YWwgY29uc2VxdWVuY2VzIG9mIHVzaW5nIFJUUCB0aGFuIG5ldyBub3JtYXRpdmUgcmVxdWlyZW1l
bnRzLiBJZiB0aGF0IGlzIHRoZSBjYXNlLCB0aGV5IHNob3VsZG7igJl0IHVzZSBub3JtYXRpdmUg
a2V5d29yZHMgdW5sZXNzIGluIHRoZSBmb3JtIG9mIGRpcmVjdCBxdW90ZXMuDQoNCkFwb2xvZ2ll
cyAtIEkgaGFkIHRyb3VibGUgaWRlbnRpZnlpbmcgc3VjaCBpbnN0YW5jZXMuICBBbGwgaW5zdGFu
Y2VzIG9mIHN1Y2gga2V5d29yZHMgYXJlIHJlbGF0ZWQgdG8gcmVxdWlyZW1lbnRzIHdpdGggcmVz
cGVjdCB0byBSRkMgMzU1MC4gIERvIHlvdSBoYXZlIHNwZWNpZmljIGV4YW1wbGVzPw0KDQotIGRl
ZmluaXRpb24gb2Ygc2VxdWVuY2UgbnVtYmVyLiBEb2VzbuKAmXQgUlRQIGFscmVhZHkgcmVxdWly
ZSB0aGUgc2VxdWVuY2UgbnVtYmVyIHRvIGluY3JlbWVudCBieSBvbmUsIGFuZCByZWNvbW1lbmQg
dGhlIHVzZSBvZiBhIHJhbmRvbSBzdGFydGluZyB2YWx1ZT8NCg0KLSBkZWZpbml0aW9uIG9mIHRp
bWUgc3RhbXA6IEkgaW5pdGlhbGx5IHRob3VnaHQgdGhhdCB0aGUgU0hBTEwgcmVmbGVjdGVkIGEg
cmVxdWlyZW1lbnQgYWxyZWFkeSBpbiAzNTUwLCBidXQgbm93IEkgcmVhbGl6ZSB0aGF0IHRyYW5z
bWlzc2lvbiB0aW1lIGlzIG5vdCB0aGUgc2FtZSBhcyBzYW1wbGluZyB0aW1lLiAgU28gdGhpcyBv
bmUgaXMgcHJvYmFibHkgb2theS4NCg0KLSBTU1JDOiAzNTUwIGFscmVhZHkgc2F5cyBTU1JDcyBT
SE9VTEQgYmUgYXNzaWduZWQgcmFuZG9tbHksIHNvIHRoZSByZXF1aXJlbWVudCBpcyBhIHN0YXRl
bWVudCBvZiBmYWN0IGFzIGZhciBhcyBfdGhpc18gc3BlYyBpcyBjb25jZXJuZWQuIChUaGUgdGV4
dCBldmVuIG1lbnRpb25zIOKAnGFzIHN1Z2dlc3RlZCBieSBSRkMgMzM1MCIsIGFsdGhvdWdoIDM1
NTAgZG9lcyBtb3JlIHRoYW4g4oCcc3VnZ2VzdOKAnSBpdC4pDQoNCi0gInRoZSBjb2xsaXNpb25z
IE1VU1QgYmUgcmVzb2x2ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMzNTUwXeKAnSA6IGFnYWluLCB0
aGF0IGZvbGxvd3MgbmF0dXJhbGx5IGZyb20gdXNpbmcgUlRQLiBJdCBkb2VzIG5vdCBkZWZpbmUg
YSBuZXcgcmVxdWlyZW1lbnQuDQoNCg0KDQotIDEwdGggcGFyYWdyYXBoOiAiVGhlIHJlcGFpciBz
dHJlYW1z4oCZIFNTUkPigJlzIENOQU1FIFNIT1VMRCBiZSBpZGVudGljYWwgdG8gdGhlIENOQU1F
IG9mIHRoZSBzb3VyY2UgUlRQIHN0cmVhbShzKSB0aGF0IHRoaXMgcmVwYWlyIHN0cmVhbSBwcm90
ZWN0cy7igJ0gV2h5IGlzIHRoZSBTSE9VTEQgbm90IGEgTVVTVD8gV2hhdCBoYXBwZW5zIGlmIGl0
IGlzIHZpb2xhdGVkPw0KDQpQcm9wb3NlZCBjaGFuZ2U6ICBBZ3JlZWQgdGhhdCB0aGUgcmVxdWly
ZW1lbnQgbWFrZXMgbW9yZSBzZW5zZSBhcyBhIE1VU1QuICBXaWxsIGNoYW5nZSBhY2NvcmRpbmds
eS4NCg0KSSBjb25jdXIgd2l0aCB0aGUgY2hhbmdlLCBidXQgaXQgaXMgYSBtYXRlcmlhbCBjaGFu
Z2UuIFBsZWFzZSBwb2ludCBpdCBvdXQgdG8gdGhlIFdHIGluIGNhc2UgYW55b25lIG9iamVjdHMu
IChJdCBtYXkgbm90IGJlIHNhZmUgdG8gYXNzdW1lIHBlb3BsZSBhcmUgcmVhZGluZyB0aGlzIG5v
dGUgaW4gdGhhdCBsZXZlbCBvZiBkZXRhaWwsIGVzcGVjaWFsbHkgb3ZlciB0aGUgaG9saWRheXMg
Oi0pKSBUbyBiZSBjbGVhciwgSSBkb27igJl0IHdhbnQgdG8gYmxvY2sgcHJvZ3Jlc3Mgb2YgdGhl
IGRyYWZ0IG92ZXIgaXQ7IGlmIGFueW9uZSBvYmplY3RzIHRoZXkgY2FuIGRvIHNvIGFzIHBhcnQg
b2YgdGhlIElFVEYgbGFzdCBjYWxsLg0KDQpbLi4uXQ0KDQoNCg0KDQrCpzQuMi4yOiBQbGVhc2Ug
YWRkIGEgc2hvcnQgZXhwbGFuYXRpb24gb2Ygd2h5IHdlIG5lZWQgdHdvIGRpZmZlcmVudCBGRUMg
cGFja2V0IGZvcm1hdHMuIChOb3QgY291bnRpbmcgdGhlIHJldHJhbnNtaXNzaW9uIHBhY2tldDsg
dGhlIHJlYXNvbmluZyB0aGVyZSBpcyBwcmV0dHkgb2J2aW91cy4pDQoNClByb3Bvc2VkIGNoYW5n
ZTogIEFkZCBhZGRpdGlvbmFsIHNlbnRlbmNlIHRvIGZpcnN0IHBhcmFncmFwaCBvZiBTZWMuIDQu
Mi4yOiAgIlR3byBvZiB0aGVzZSB2YXJpYW50cyBhcmUgbWVhbnQgdG8gZGVzY3JpYmUgZGlmZmVy
ZW50IG1ldGhvZHMgZm9yIGRlcml2aW5nIHRoZSBzb3VyY2UgZGF0YSBmcm9tIGEgc291cmNlIHBh
Y2tldCBmb3IgYSByZXBhaXIgcGFja2V0LiAgVGhlIHRoaXJkIHZhcmlhbnQgaXMgZm9yIGEgc3Ry
YWlnaHQgcmV0cmFuc21pc3Npb24gb2YgdGhlIHNvdXJjZSBwYWNrZXQu4oCdDQoNClRoYXTigJlz
IHVzZWZ1bCwgYnV0IGl0IGRvZXNu4oCZdCBleHBsYWluIF93aHlfIHdlIG5lZWQgdHdvIGRpZmZl
cmVudCBtZXRob2RzLg0KDQoNCg0KDQrCpzUuMS4xIChhbmQgc3Vic2VxdWVudCBtZWRpYSB0eXBl
IGRlZmluaXRpb25zKSAtIFBsZWFzZSBjb25zaWRlciB1c2luZyB0aGUgSUVTRyAoaWVzZ0BpZXRm
Lm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4pIGFzIHRoZSBjb250YWN0IGZvciBmdXJ0aGVyIGlu
Zm9ybWF0aW9uLiBXb3JraW5nIGdyb3VwcyBjb21lIGFuZCBnbywgYW5kIGF1dGhvcnMgY2hhbmdl
IGpvYnMuIEJ1dCBzb21lb25lIG9uIHRoZSBJRVNHIHNob3VsZCAoaG9wZWZ1bGx5KSBhbHdheXMg
YmUgYWJsZSB0byBmaW5kIHRoZSByaWdodCBwZXJzb24sDQoNClRFTlRBVElWRSBwcm9wb3NlZCBj
aGFuZ2U6ICBJIGFtIGhhcHB5IHRvIHN3YXAgb3V0IFZhcnVuJ3MgZW1haWwgZm9yIElFU0csIGJ1
dCB0aGlzIGRvZXMgbm90IHNlZW0gdG8gYmUgYSB3aWRlc3ByZWFkIHByYWN0aWNlIGV2ZW4gZm9y
IHJlY2VudGx5LXB1Ymxpc2hlZCBSRkMncy4gIENhbiB5b3UgY29uZmlybSB0aGF0IHRoaXMgaXMg
bm93IGJlY29taW5nIGEgYmVzdCBwcmFjdGljZSBmb3IgY29udGFjdCBpbmZvIHJlZ2FyZGluZyBy
ZWdpc3RyaWVzPw0KDQpJdOKAmXMgYmVlbiBjb21tb24gb2YgbGF0ZS4gVGhlIHJlYXNvbmluZyBp
cyB0aGF0IHRoZSBJRVNHIGVtYWlsIGFkZHJlc3MgaXMgdGhlIGxlYXN0IGxpa2VseSB0byBjaGFu
Z2Ugb2YgYW55IGNvbnRhY3Qgd2UgbWlnaHQgZ2l2ZS4NCg0KDQoNCg0KLSBDaGFuZ2UgY29udHJv
bDogIEluIDUuMS4xLCBzaG91bGRu4oCZdCB0aGF0IGJlIHRoZSBQQVlMT0FEIHdvcmtpbmcgZ3Jv
dXAgKG9yIGl04oCZcyBzdWNjZXNzb3IgYXMgZGVsZWdhdGVkIGJ5IHRoZSBJRVNHLi4uKQ0KDQpQ
cm9wb3NlZCBjaGFuZ2U6ICBDaGFuZ2UgdG8gIklFVEYgQXVkaW8vVmlkZW8gUGF5bG9hZHMgVHJh
bnNwb3J0IFBheWxvYWRzIFdvcmtpbmcgR3JvdXDigJ0NCg0KSSBzdWdnZXN0IGFkZGluZyDigJwu
Li4gb3IgaXTigJlzIHN1Y2Nlc3NvciBhcyBkZWxlZ2F0ZWQgYnkgdGhlIElFU0cuDQoNCg0KDQoN
Cg0KLSBBcmUgdGhlc2UgcmVnaXN0cmF0aW9ucyByZWFsbHkgaW50ZW5kZWQgdG8gYmUgcHJvdmlz
aW9uYWw/DQoNCkF0IHRoaXMgcG9pbnQsIG5vLg0KDQpQcm9wb3NlZCBjaGFuZ2U6ICBFbGltaW5h
dGUgbWVudGlvbiBvZiBwcm92aXNpb25hbCByZWdpc3RyYXRpb24gZm9yIGFsbCBtZWRpYSB0eXBl
cy4NCg0KSSBhZ3JlZS4gSG93ZXZlciB0aGlzIGlzIGFub3RoZXIgbWF0ZXJpYWwgY2hhbmdlIHRo
YXQgc2hvdWxkIGJlIHBvaW50ZWQgb3V0IHRvIHRoZSBXRy4NCg0KDQoNCg0Kwqc1LjIuMSwgbGFz
dCBidWxsZXQ6ICJBbnkgdW5rbm93biBvcHRpb24gaW4gdGhlIG9mZmVyIE1VU1QgYmUgaWdub3Jl
ZCBhbmQgZGVsZXRlZCBmcm9tIHRoZSBhbnN3ZXIu4oCdOiBJcyB0aGF0IGEgYSBuZXcgcmVxdWly
ZW1lbnQgc3BlY2lmaWMgdG8gZmxleC1mZWMsIG9yIGp1c3QgYSBub3JtYWwgb2ZmZXIvYW5zd2Vy
IHJlcXVpcmVtZW50Pw0KDQpSRkMgMzI2NCBTZWN0aW9uIDYgc3RhdGVzDQonRm9yIGVhY2ggIm09
IiBsaW5lIGluIHRoZSBvZmZlciwgdGhlcmUgTVVTVCBiZSBhIGNvcnJlc3BvbmRpbmcgIm09IiBs
aW5lIGluIHRoZSBhbnN3ZXIuICBUaGUgYW5zd2VyIE1VU1QgY29udGFpbiBleGFjdGx5IHRoZSBz
YW1lIG51bWJlciBvZiAibT0iIGxpbmVzIGFzIHRoZSBvZmZlci4gIFRoaXMgYWxsb3dzIGZvciBz
dHJlYW1zIHRvIGJlIG1hdGNoZWQgdXAgYmFzZWQgb24gdGhlaXIgb3JkZXIuICBUaGlzIGltcGxp
ZXMgdGhhdCBpZiB0aGUgb2ZmZXIgY29udGFpbmVkIHplcm8gIm09IiBsaW5lcywgdGhlIGFuc3dl
ciBNVVNUIGNvbnRhaW4gemVybyAibT0iIGxpbmVzLicNCg0KSSBkb24ndCBiZWxpZXZlIHRoaXMg
aXMgbm9ybWFsIG9mZmVyL2Fuc3dlci4gIEl0IGlzIHNwZWNpZmljIHRvIEZMRVggRkVDLg0KDQpP
a2F5Lg0KDQpbLi4uXQ0KDQoNCg0KLSDigJxJbiBhIG5ldHdvcmstZnJpZW5kbHkgaW1wbGVtZW50
YXRpb27igJ06IERvIHlvdSBleHBlY3QgdG8gc2VlIG5ldHdvcmstdW5mcmllbmRseSBpbXBsZW1l
bnRhdGlvbnM/IElzIHRoYXQgb2theT8NCg0KSSBkb24ndCB2aWV3ICJuZXR3b3JrLWZyaWVuZGx5
IiBhcyBiZWluZyBhIHN0YXRpYyBjb25kaXRpb24uICBUaGVyZSBhcmUgc2NlbmFyaW9zIHdoZXJl
IGFuIEZFQyB0cmFuc21pdHRlci9yZWNlaXZlciBwYWlyIGhhdmUgbmVnb3RpYXRlZCBhIGNvbm5l
Y3Rpb24gd2hpY2ggaXMgbmV0d29yay1mcmllbmRseSBmb3Igb25lIGFwcGxpY2F0aW9uLCBidXQg
bWF5IG5vdCBiZSBmb3IgYSBkaWZmZXJlbnQgYXBwbGljYXRpb24uICBUaGVyZSB3YXMgYSBkaXNj
dXNzaW9uIGFib3V0IHdoZW4gRkVDIGlzIGFwcHJvcHJpYXRlIGFuZCB3aGVuIGl0IGlzIG5vdCBv
biB0aGUgV2ViUlRDIG1haWxpbmcgbGlzdHMgLSBzZWUgaHR0cHM6Ly9saXN0cy53My5vcmcvQXJj
aGl2ZXMvUHVibGljL3B1YmxpYy13ZWJydGMvMjAxOE5vdi8wMTU2Lmh0bWwuICAgIk5ldHdvcmst
dW5mcmllbmRseSIgaW1wbGVtZW50YXRpb25zIGNvdWxkIGNvbmNlaXZhYmx5IG9jY3VyIHdoZW4g
YW4gRkVDIHNlc3Npb24gaGFzIGJlZW4gbmVnb3RpYXRlZCBiZXR3ZWVuIGVuZHBvaW50cywgYnV0
IG5laXRoZXIgZW5kcG9pbnQgaGFzIGFzc2Vzc2VkIHRyYW5zbWlzc2lvbiBjb25kaXRpb25zLg0K
DQpJcyB0aGF0IGEgcmVhc29uYWJseSBpbXBsZW1lbnRhdGlvbj8gSXQgc291bmRzIGxpa2UgYSBi
dWcgdG8gbWUuIChJIHByb2JhYmx5IGNvdWxkIGhhdmUgcGhyYXNlZCBteSBxdWVzdGlvbiBiZXR0
ZXIgYXMg4oCcIGFyZSBuZXR3b3JrLXVuZnJpZW5kbHkgaW1wbGVtZW50YXRpb25zIGV2ZXIgYWNj
ZXB0YWJsZeKAnS4pDQoNCg0KSW4gc2hvcnQsIEkgdGhpbmsgdGhlIHRleHQgaXMgZmluZSBhcyBp
cy4NCg0KSSBkaXNhZ3JlZS4g4oCcTmV0d29yay1mcmllbmRseeKAnSBpcyBhIGNvbmRpdGlvbiB0
aGF0IHRyaWdnZXJzIGEgU0hPVUxELiBJIHRoaW5rIHRoZXJl4oCZcyBhIGhpZ2ggY2hhbmNlIHlv
dSB3aWxsIHNlZSBkaWZmZXJlbnQgaW1wbGVtZW50b3JzIGludGVycHJldCB0aGF0IGNvbmRpdGlv
biBkaWZmZXJlbnRseS4gSWYgdGhlIGludGVudCBpcyB0byBnaXZlIG5vcm1hdGl2ZSBndWlkYW5j
ZSwgdGhlcmUgbmVlZHMgdG8gYmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIGF2b2lkIHRoYXQuIE9U
T0gsIGlmIHRoZSBpbnRlbnQgaXMgdG8gcG9pbnQgb3V0IHRoaW5ncyBhbiBpbXBsZW1lbnRlciBu
ZWVkcyB0byB0aGluayBhYm91dCwgdGhlbiB0aGUgbm9ybWF0aXZlIFNIT1VMRCBtYXkgbm90IGJl
IGFwcHJvcHJpYXRlLg0KDQoNCg0KDQrCpzksIGxhc3QgcGFyYWdyYXBoOiBXaGF0IGFyZSB0aGUg
c2VjdXJpdHkgaW1wbGljYXRpb25zIG9mIHVudXNlZCBzb3VyY2UtYnVmZmVycz8gSXMgdGhpcyBh
IHBvdGVudGlhbCBEb1MgdmVjdG9yPw0KDQpJdCBjb3VsZCBiZS4gIFVudXNlZCBzb3VyY2UgYnVm
ZmVycyBjb21iaW5lZCB3aXRoIHBvdGVudGlhbGx5IGxhcmdlIHBhY2tldCBzaXplIChlLmcuIGZv
ciBidW5kbGVkIHByb3RlY3Rpb24pIGNvdWxkIGV2ZW50dWFsbHkgcmVzdWx0IGluIGEgbGFjayBv
ZiByZXNvdXJjZXMgKGUuZy4gbWVtb3J5KSBpbiBhbiBlbmRwb2ludC4NCg0KUHJvcG9zZWQgYWRk
aXRpb25hbCBjbGFyaWZ5aW5nIHRleHQ6IEZvbGxvd2luZyAgIkdpdmVuIHRoYXQgRkxFWCBGRUMg
ZW5hYmxlcyB0aGUgcHJvdGVjdGlvbiBvZiBtdWx0aXBsZSBzb3VyY2Ugc3RyZWFtcywgdGhlcmUg
ZXhpc3RzIHRoZSBwb3NzaWJpbGl0eSB0aGF0IG11bHRpcGxlIHNvdXJjZSBidWZmZXJzIG1heSBi
ZSBjcmVhdGVkIHRoYXQgbWF5IG5vdCBiZSB1c2VkIiBhZGQgICJBbiBhdHRhY2tlciBjb3VsZCBs
ZXZlcmFnZSB1bnVzZWQgc291cmNlIGJ1ZmZlcnMgdG8gYXMgYSBtZWFucyBvZiBvY2N1cHlpbmcg
bWVtb3J5IGluIGEgRkxFWCBGRUMgZW5kcG9pbnQu4oCdDQoNCldvcmtzIGZvciBtZS4NCg0KWy4u
Ll0NCg0KDQoNCg0KLSAybmQgcGFyYWdyYXBoOiBzL1JlZHVuYWRuY3kvUmVkdW5kYW5jeeKAnQ0K
DQpQcm9wb3NlZCBjaGFuZ2U6ICAgIlJlZHVuYWRuY3kiIGNoYW5nZWQgdG8gIlJlZHVuZGFuY3ki
LiAgVGhhbmsgeW91IGZvciBjYXRjaGluZyB0aGlzLg0KDQoNCsKnMS4xLjE6IC0gSXQgd291bGQg
YmUgaGVscGZ1bCB0byBkZXNjcmliZSB3aGF0IEwgYW5kIEQgcmVwcmVzZW50IGhlcmUsIG9yIGF0
IGxlYXN0IGdpdmUgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0aGUgZGVmaW5pdGlvbi4gKEkgbm90
ZSB0aGF0IGEgbG90IG9mIHRleHQgZ29lcyBieSBiZWZvcmUgeW91IGdldCB0byB0aGUgIGRlZmlu
aXRpb25zIG9yIHRoZSAyMTE5IGJvaWxlcnBsYXRlLikNCg0KQ3VycmVudCB0ZXh0IHN0YXRlczog
ICIgQ29uc2lkZXIgYSBncm91cCBvZiBEIHggTCBzb3VyY2UgcGFja2V0cyB0aGF0IGhhdmUgc2Vx
dWVuY2UgbnVtYmVycyBzdGFydGluZyBmcm9tIDEgcnVubmluZyB0byBEIHggTCwgYW5kIGEgcmVw
YWlyIHBhY2tldCBpcyBnZW5lcmF0ZWQgYnkgYXBwbHlpbmcgdGhlIFhPUiBvcGVyYXRpb24gdG8g
ZXZlcnkgTCBjb25zZWN1dGl2ZSBwYWNrZXRzIGFzIHNrZXRjaGVkIGluIEZpZ3VyZSAzLiINCg0K
SSBkb24ndCB0aGluayB0aGF0IHRoZXJlIGlzIGEgZnVydGhlciBkZWZpbml0aW9uIHJlcXVpcmVk
LiAgSG93ZXZlciwgYW4gYWRkaXRpb24gc2VudGVuY2UgY291bGQgZm9sbG93IHRoZSBhYm92ZSBk
ZXNjcmlwdGlvbiB0byBjbGFyaWZ5Lg0KDQpQcm9wb3NlZCB0ZXh0OiAgIkluIGdlbmVyYWwsIEQg
YW5kIEwgcmVwcmVzZW50IHZhbHVlcyB0aGF0IGRlc2NyaWJlIGhvdyBwYWNrZXRzIGFyZSBncm91
cGVkIHRvZ2V0aGVyIGZvciBwYXJpdHkgY29kZSBnZW5lcmF0aW9uIHdoZW4gaW50ZXJsZWF2aW5n
IGFsbCBEIHggTCBzb3VyY2UgcGFja2V0cy7igJ0NCg0KVGhhdOKAmXMga2luZCBvZiBjaXJjdWxh
ciBleHBsYW5hdGlvbi4gSSB3YXMganVzdCBsb29raW5nIGZvciBzb21ldGhpbmcgYWxvbmcgdGhl
IGxpbmVzIG9mIOKAmCDigJxE4oCdIGFuZCDigJxM4oCdIHJlcHJlc2VudCB0aGUgZGVwdGggYW5k
IGxlbmd0aCwgcmVzcGVjdGl2ZWx54oCdLg0KDQpbLi4uXQ0KDQoNCsKnNC4yLjIsIHBhcmFncmFw
aCBhZnRlciBGaWd1cmUgMTA6IFRoZSB0ZXh0IHNlZW1zIHRvIGJlIHN1Z2dlc3QgdGhlcmUgaXMg
b25lIHNvdXJjZSBwYWNrZXQgcHJvdGVjdGVkIGJ5IGEgZ2l2ZW4gcmVwYWlyIHBhY2tldC4gSUlV
QywgdGhhdOKAmXMgbm90IHRoZSBjYXNlOyBhIGdpdmVuIEZFQyBwYWNrZXQgcHJvdGVjdHMgc2V2
ZXJhbCBzb3VyY2UgcGFja2V0cywgZG9lc27igJl0IGl0Pw0KDQpUaGUgdGV4dCByZWFkcyBpbiBw
YXJ0ICIuLi4gaW5jbHVkZXMgcmVwYWlyIG9mIGV2ZXJ5dGhpbmcgZm9sbG93aW5nIHRoZSBmaXhl
ZCAxMi1ieXRlIFJUUCBoZWFkZXIgb2YgdGhlIHNvdXJjZSBwYWNrZXQgLi4uIi4NCg0KIi4uLiBl
dmVyeXRoaW5nIGZvbGxvd2luZyAuLi4iIGltcGxpZXMgbW9yZSB0aGFuIGp1c3QgYSBzaW5nbGUg
c291cmNlIFJUUCBwYWNrZXQuDQoNCkxldOKAmXMgc2F5IGZvciBhcmd1bWVudCB0aGF0IHRoZSBy
ZXBhaXIgcGFja2V0IHByb3RlY3RzIDIgc291cmNlIHBhY2tldHMuIElzIHRoZSAxMi1ieXRlIFJU
UCBoZWFkZXIgb2YgdGhlIDJuZCBwYWNrZXQgcHJvdGVjdGVkPw0KDQooRXZlbiBpZiB0aGUgYW5z
d2VyIGlzIHllcywgaXQgd291bGQgYmUgaGVscGZ1bCB0byBzYXkgIiAuLi4gYW5kIHN1YnNlcXVl
bnQgcGFja2V0cy4uLiIpDQoNClsuLi5dDQoNCg0Kwqc1LjIuMiwgZmlyc3QgcGFyYWdyYXBoOiBJ
cyB0aGVyZSBhIHJlYXNvbiB0byBjaXRlIHRoZSBvYnNvbGV0ZSBSRkMgMjMyNj8NCg0KVGhpcyBh
bHNvIGNhbWUgdXAgYXMgcGFydCBvZiB0aGUgSS4tRC4gbml0cy4gIEkgZGVjaWRlZCB0byBsZWF2
ZSB0aGUgMjMyNiByZWZlcmVuY2UgaW4gYmVjYXVzZSBJIGRpZCBub3Qgd2FudCB0byBpbXBseSB0
aGF0IEZMRVggRkVDIGNhbm5vdCBiZSB1c2VkIGZvciBSVFNQIDEuMCwgYW5kIFJUU1AgMi4wIGlz
IG5vdCBiYWNrd2FyZHMtY29tcGF0aWJsZS4NCg0KSSBzdWdnZXN0IGFkZGluZyBhIGZldyB3b3Jk
cyB0byBleHBsYWluIHRoYXQuDQoNClsuLi5dDQoNCg0KDQrCpzksIGxhc3QgcGFyYWdyYXBoOiBJ
IGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgaW50ZW50IG9mIHRoZSBsYXN0IHNlbnRlbmNlLg0KDQpP
cmlnaW5hbGx5IHN1Z2dlc3RlZCBpbiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv
bXNnL3BheWxvYWQvQUlIdzVEU0FCRUpMYTZsU09McnlMZEkwZUJrLiAgVGhlIGFwcGxpY2F0aW9u
IHNvdXJjZSBkYXRhIG1heSBub3QgYmUgcGVyZmVjdGx5IG1hdGNoZWQgd2l0aCBGTEVYIEZFQyBz
b3VyY2UgcGFydGl0aW9uaW5nLiAgSWYgdGhpcyBpcyB0aGUgY2FzZSwgdGhlcmUgaXMgYSBwb3Nz
aWJpbGl0eSBmb3IgdW5wcm90ZWN0ZWQgc291cmNlIGRhdGEgaWYsIGZvciBpbnN0YW5jZSwgdGhl
IEZMRVggRkVDIGltcGxlbWVudGF0aW9uIGRpc2NhcmRzIGRhdGEgdGhhdCBkb2VzIG5vdCBmaXQg
cGVyZmVjdGx5IGludG8gaXRzIHNvdXJjZSBwcm9jZXNzaW5nIHJlcXVpcmVtZW50cy4NCg0KVGhh
dCBleHBsYW5hdGlvbiBpcyBtb3JlIGNsZWFyIHRoYW4gdGhlIHRleHQgaW4gdGhlIGRyYWZ0LiBJ
IHN1Z2dlc3QgaW5jbHVkaW5nIGl0Lg0KDQpbLi4uXQ0K

--_000_0341aad5c46241edbba503e834f0d098NASANEXM01Cnaqualcommco_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl
bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov
KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvdXJpZXI7
DQoJcGFub3NlLTE6MiA3IDQgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQg
NiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6
MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y
bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo
DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln
aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu
LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y
bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt
YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w
aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox
ODQ1OTc3MjkyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk
czoxMDU5NjA4OTMyIC00MjA4NTIwODggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2
OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwx
DQoJe21zby1sZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl
dDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv
LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250
LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglt
c28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDIN
Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0
Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs
aXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu
Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z
by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u
dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv
cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu
Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2
ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv
grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv
bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp
c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp
ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs
bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv
bnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXtt
YXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgcmVzcG9uc2UuJm5ic3A7
IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBGTEVYIEZFQyBjZXJ0YWlubHkgd2Fz
IGluc3BpcmVkIGJ5IEZFQyBGUkFNRSwgYnV0IHRoZSBkb2N1bWVudCBjYW4gc3RhbmQgb24gaXRz
IG93bi4gJm5ic3A7Jm5ic3A7Jm5ic3A7U2luY2Ugc2V2ZXJhbCBkZWZpbml0aW9ucyBhcmUgbGV2
ZXJhZ2VkIGZyb20gUkZDIDYzNjMsIEkgYmVsaWV2ZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgaXMg
c3RpbGwgYXBwcm9wcmlhdGUuICZuYnNwO015IHN1Z2dlc3Rpb24gaXMgdG8gYWRkIG9uZSBzZW50
ZW5jZQ0KIHRvIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDEuPGJyPg0KJmd0OyZndDsg
UHJvcG9zZWQgY2hhbmdlOiAmbmJzcDtBZGQgJnF1b3Q7VGhpcyBkb2N1bWVudCBhbHNvIGxldmVy
YWdlcyBzZXZlcmFsIGRlZmluaXRpb25zIGFsb25nIHdpdGggdGhlIGJhc2ljIHNvdXJjZS9yZXBh
aXIgaGVhZGVyIGRlc2NyaXB0aW9uIGZyb20gUkZDIDYzNjMgaW4gdGhlaXIgYXBwbGljYXRpb24g
dG8gdGhlIHBhcml0eSBjb2RlcyBkZWZpbmVkIGhlcmUu4oCdPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZndDsgVGhhdCBoZWxwcy4gSSBtaWdodCBzdWdnZXN0IHNvbWV0aGluZyBhbG9uZyB0aGUg
bGluZXMgb2Yg4oCcV2hpbGUgdGhpcyBkb2N1bWVudCBmdWxseSBkZWZpbmVzIHRoZSB1c2Ugb2Yg
RkVDIHRvIHByb3RlY3QgUlRQIHN0cmVhbXMsIGl0IGFsc28gbGV2ZXJhZ2VzLi4u4oCdPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk1vZGlmaWVkIHByb3Bvc2VkIGNoYW5nZTombmJzcDsg4oCcV2hp
bGUgdGhpcyBkb2N1bWVudCBmdWxseSBkZWZpbmVzIHRoZSB1c2Ugb2YgRkVDIHRvIHByb3RlY3Qg
UlRQIHN0cmVhbXMsIGl0IGFsc28gbGV2ZXJhZ2VzIHNldmVyYWwgZGVmaW5pdGlvbnMgYWxvbmcg
d2l0aCB0aGUgYmFzaWMgc291cmNlL3JlcGFpciBoZWFkZXIgZGVzY3JpcHRpb24gZnJvbSBSRkMg
NjM2MyBpbiB0aGVpciBhcHBsaWNhdGlvbiB0byB0aGUgcGFyaXR5DQogY29kZXMgZGVmaW5lZCBo
ZXJlLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZndDs0LjIuMTogLSBUaGVy
ZeKAmXMgYSBudW1iZXIgb2YgMjExOS84MTc0IGtleXdvcmRzIGluIHRoaXMgc2VjdGlvbiB0aGF0
IHNlZW0gbW9yZSBuYXR1cmFsIGNvbnNlcXVlbmNlcyBvZiB1c2luZyBSVFAgdGhhbiBuZXcgbm9y
bWF0aXZlIHJlcXVpcmVtZW50cy4gSWYgdGhhdCBpcyB0aGUgY2FzZSwgdGhleSBzaG91bGRu4oCZ
dCB1c2Ugbm9ybWF0aXZlIGtleXdvcmRzIHVubGVzcyBpbiB0aGUgZm9ybSBvZiBkaXJlY3QNCiBx
dW90ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBBcG9s
b2dpZXMgLSBJIGhhZCB0cm91YmxlIGlkZW50aWZ5aW5nIHN1Y2ggaW5zdGFuY2VzLiAmbmJzcDtB
bGwgaW5zdGFuY2VzIG9mIHN1Y2gga2V5d29yZHMgYXJlIHJlbGF0ZWQgdG8gcmVxdWlyZW1lbnRz
IHdpdGggcmVzcGVjdCB0byBSRkMgMzU1MC4gJm5ic3A7RG8geW91IGhhdmUgc3BlY2lmaWMgZXhh
bXBsZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDstIGRlZmluaXRpb24gb2Ygc2VxdWVu
Y2UgbnVtYmVyLiBEb2VzbuKAmXQgUlRQIGFscmVhZHkgcmVxdWlyZSB0aGUgc2VxdWVuY2UgbnVt
YmVyIHRvIGluY3JlbWVudCBieSBvbmUsIGFuZCByZWNvbW1lbmQgdGhlIHVzZSBvZiBhIHJhbmRv
bSBzdGFydGluZyB2YWx1ZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0
b3NwYWNlOm5vbmUiPlByb3Bvc2VkIGNoYW5nZTombmJzcDsg4oCcU2VxdWVuY2UgTnVtYmVyIChT
Tik6IFRoZSBzZXF1ZW5jZSBudW1iZXIgZm9sbG93cyB0aGUgc3RhbmRhcmQgZGVmaW5pdGlvbiBw
cm92aWRlZCBpbiBbUkZDMzU1MF0uIFRoZXJlZm9yZSBpdCBtdXN0IGJlIG9uZSBoaWdoZXIgdGhh
biB0aGUgc2VxdWVuY2UgbnVtYmVyIGluIHRoZSBwcmV2aW91c2x5IHRyYW5zbWl0dGVkIHJlcGFp
cg0KIHBhY2tldCwgYW5kIHRoZSBpbml0aWFsIHZhbHVlIG9mIHRoZSBzZXF1ZW5jZSBudW1iZXIg
c2hvdWxkIGJlIHJhbmRvbSAoaS5lLiB1bnByZWRpY3RhYmxlKS7igJ08bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jmd0Oy0gU1NSQzogMzU1MCBhbHJlYWR5IHNheXMgU1NSQ3MgU0hPVUxEIGJlIGFz
c2lnbmVkIHJhbmRvbWx5LCBzbyB0aGUgcmVxdWlyZW1lbnQgaXMgYSBzdGF0ZW1lbnQgb2YgZmFj
dCBhcyBmYXIgYXMgX3RoaXNfIHNwZWMgaXMgY29uY2VybmVkLiAoVGhlIHRleHQgZXZlbiBtZW50
aW9ucyDigJxhcyBzdWdnZXN0ZWQgYnkgUkZDIDMzNTAmcXVvdDssIGFsdGhvdWdoIDM1NTAgZG9l
cyBtb3JlIHRoYW4g4oCcc3VnZ2VzdOKAnSBpdC4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNl
Y3Rpb24gOCBvZiBSRkMgMzU1MCBkb2VzIG5vdCB1c2Ugbm9ybWF0aXZlIGxhbmd1YWdlIHN1Y2gg
YXMgTVVTVCBvciBTSEFMTCwgYnV0IHRoZSBleGlzdGluZyB0ZXh0IGNhbiBzdGFuZCB0byBiZSBj
bGFyaWZpZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpu
b25lIj5Qcm9wb3NlZCBjaGFuZ2U6Jm5ic3A7IOKAnFN5bmNocm9uaXphdGlvbiBTb3VyY2UgKFNT
UkMpOiBUaGUgU1NSQyB2YWx1ZSBmb3IgZWFjaCByZXBhaXIgc3RyZWFtIFNIQUxMIGJlIHJhbmRv
bWx5IGFzc2lnbmVkIGFzIHBlciB0aGUgZ3VpZGVsaW5lcyBvZiBTZWN0aW9uIDggb2YgW1JGQzM1
NTBdLiDigKbigJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0
ZXh0LWF1dG9zcGFjZTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPiZndDstICZxdW90O3RoZSBjb2xsaXNpb25zJm5ic3A7TVVTVCBiZSByZXNvbHZlZCBh
cyBkZXNjcmliZWQgaW4gW1JGQzM1NTBd4oCdIDogYWdhaW4sIHRoYXQgZm9sbG93cyBuYXR1cmFs
bHkgZnJvbSB1c2luZyBSVFAuIEl0IGRvZXMgbm90IGRlZmluZSBhIG5ldyByZXF1aXJlbWVudC48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj
ZTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJ0ZXh0LWF1dG9zcGFjZTpub25lIj5Qcm9wb3NlZCBjaGFuZ2U6Jm5ic3A7IOKAnOKApiB0aGUg
Y29sbGlzaW9ucyBtdXN0IGJlIHJlc29sdmVkIGFzIGRlc2NyaWJlZCBpbiDigKbigJ08bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25l
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7Jmd0
Oy0gMTB0aCBwYXJhZ3JhcGg6ICZxdW90O1RoZSByZXBhaXIgc3RyZWFtc+KAmSBTU1JD4oCZcyBD
TkFNRSBTSE9VTEQgYmUgaWRlbnRpY2FsIHRvIHRoZSBDTkFNRSBvZiB0aGUgc291cmNlIFJUUCBz
dHJlYW0ocykgdGhhdCB0aGlzIHJlcGFpciBzdHJlYW0gcHJvdGVjdHMu4oCdIFdoeSBpcyB0aGUg
U0hPVUxEIG5vdCBhIE1VU1Q/IFdoYXQgaGFwcGVucyBpZiBpdCBpcyB2aW9sYXRlZD88bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsmZ3Q7UHJvcG9zZWQgY2hh
bmdlOiAmbmJzcDtBZ3JlZWQgdGhhdCB0aGUgcmVxdWlyZW1lbnQgbWFrZXMgbW9yZSBzZW5zZSBh
cyBhIE1VU1QuICZuYnNwO1dpbGwgY2hhbmdlIGFjY29yZGluZ2x5LjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mZ3Q7SSBjb25jdXIgd2l0aCB0aGUgY2hhbmdlLCBidXQgaXQgaXMgYSBtYXRlcmlh
bCBjaGFuZ2UuIFBsZWFzZSBwb2ludCBpdCBvdXQgdG8gdGhlIFdHIGluIGNhc2UgYW55b25lIG9i
amVjdHMuIChJdCBtYXkgbm90IGJlIHNhZmUgdG8gYXNzdW1lIHBlb3BsZSBhcmUgcmVhZGluZyB0
aGlzIG5vdGUgaW4gdGhhdCBsZXZlbCBvZiBkZXRhaWwsIGVzcGVjaWFsbHkgb3ZlciB0aGUgaG9s
aWRheXMgOi0pKSBUbyBiZSBjbGVhciwNCiBJIGRvbuKAmXQgd2FudCB0byBibG9jayBwcm9ncmVz
cyBvZiB0aGUgZHJhZnQgb3ZlciBpdDsgaWYgYW55b25lIG9iamVjdHMgdGhleSBjYW4gZG8gc28g
YXMgcGFydCBvZiB0aGUgSUVURiBsYXN0IGNhbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgcG9pbnQgdGhpcyBvdXQgaW4gYSBmb2xs
b3ctb24gZW1haWwgdG8gdGhlIFdHIGxpc3QgYWZ0ZXIgSSBzdWJtaXQgdGhlIG5leHQgcmV2aXNp
b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7Jmd0O8KnNC4yLjI6IFBsZWFzZSBh
ZGQgYSBzaG9ydCBleHBsYW5hdGlvbiBvZiB3aHkgd2UgbmVlZCB0d28gZGlmZmVyZW50IEZFQyBw
YWNrZXQgZm9ybWF0cy4gKE5vdCBjb3VudGluZyB0aGUgcmV0cmFuc21pc3Npb24gcGFja2V0OyB0
aGUgcmVhc29uaW5nIHRoZXJlIGlzIHByZXR0eSBvYnZpb3VzLik8bzpwPjwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsmZ3Q7UHJvcG9zZWQgY2hhbmdlOiAmbmJzcDtB
ZGQgYWRkaXRpb25hbCBzZW50ZW5jZSB0byBmaXJzdCBwYXJhZ3JhcGggb2YgU2VjLiA0LjIuMjog
Jm5ic3A7JnF1b3Q7VHdvIG9mIHRoZXNlIHZhcmlhbnRzIGFyZSBtZWFudCB0byBkZXNjcmliZSBk
aWZmZXJlbnQgbWV0aG9kcyBmb3IgZGVyaXZpbmcgdGhlIHNvdXJjZSBkYXRhIGZyb20gYSBzb3Vy
Y2UgcGFja2V0IGZvciBhIHJlcGFpciBwYWNrZXQuICZuYnNwO1RoZSB0aGlyZCB2YXJpYW50IGlz
IGZvciBhIHN0cmFpZ2h0IHJldHJhbnNtaXNzaW9uDQogb2YgdGhlIHNvdXJjZSBwYWNrZXQu4oCd
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtUaGF04oCZcyB1c2VmdWwsIGJ1dCBpdCBkb2Vz
buKAmXQgZXhwbGFpbiBfd2h5XyB3ZSBuZWVkIHR3byBkaWZmZXJlbnQgbWV0aG9kcy48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+TW9kaWZpZWQgcHJvcG9zZWQgY2hhbmdlOiZuYnNwOyBBZGQgYWRk
aXRpb25hbCBzZW50ZW5jZXMgdG8gZmlyc3QgcGFyYWdyYXBoIG9mIFNlYy4gNC4yLjI6ICZuYnNw
OyZxdW90O1R3byBvZiB0aGVzZSB2YXJpYW50cyBhcmUgbWVhbnQgdG8gZGVzY3JpYmUgZGlmZmVy
ZW50IG1ldGhvZHMgZm9yIGRlcml2aW5nIHRoZSBzb3VyY2UgZGF0YSBmcm9tIGEgc291cmNlIHBh
Y2tldCBmb3IgYSByZXBhaXIgcGFja2V0LiAmbmJzcDtUaGlzIGFsbG93cyBmb3INCiBjdXN0b21p
emluZyB0aGUgRkVDIG1ldGhvZCB0byBhbGxvdyBmb3Igcm9idXN0bmVzcyBhZ2FpbnN0IGRpZmZl
cmVudCBsZXZlbHMgb2YgYnVyc3QgZXJyb3JzIGFuZCByYW5kb20gcGFja2V0IGxvc3Nlcy4mbmJz
cDsgVGhlIHRoaXJkIHZhcmlhbnQgaXMgZm9yIGEgc3RyYWlnaHQgcmV0cmFuc21pc3Npb24gb2Yg
dGhlIHNvdXJjZSBwYWNrZXQu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7Jmd0
O8KnNS4xLjEgKGFuZCBzdWJzZXF1ZW50IG1lZGlhIHR5cGUgZGVmaW5pdGlvbnMpIC0gUGxlYXNl
IGNvbnNpZGVyIHVzaW5nIHRoZSBJRVNHICg8YSBocmVmPSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+
aWVzZ0BpZXRmLm9yZzwvYT4pIGFzIHRoZSBjb250YWN0IGZvciBmdXJ0aGVyIGluZm9ybWF0aW9u
LiBXb3JraW5nIGdyb3VwcyBjb21lIGFuZCBnbywgYW5kIGF1dGhvcnMgY2hhbmdlIGpvYnMuIEJ1
dCBzb21lb25lDQogb24gdGhlIElFU0cgc2hvdWxkIChob3BlZnVsbHkpIGFsd2F5cyBiZSBhYmxl
IHRvIGZpbmQgdGhlIHJpZ2h0IHBlcnNvbiw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZn
dDtURU5UQVRJVkUgcHJvcG9zZWQgY2hhbmdlOiAmbmJzcDtJIGFtIGhhcHB5IHRvIHN3YXAgb3V0
IFZhcnVuJ3MgZW1haWwgZm9yIElFU0csIGJ1dCB0aGlzIGRvZXMgbm90IHNlZW0gdG8gYmUgYSB3
aWRlc3ByZWFkIHByYWN0aWNlIGV2ZW4gZm9yIHJlY2VudGx5LXB1Ymxpc2hlZCBSRkMncy4gJm5i
c3A7Q2FuIHlvdSBjb25maXJtIHRoYXQgdGhpcyBpcyBub3cgYmVjb21pbmcgYSBiZXN0IHByYWN0
aWNlIGZvciBjb250YWN0IGluZm8NCiByZWdhcmRpbmcgcmVnaXN0cmllcz88bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jmd0O0l04oCZcyBiZWVuIGNvbW1vbiBvZiBsYXRlLiBUaGUgcmVhc29uaW5n
IGlzIHRoYXQgdGhlIElFU0cgZW1haWwgYWRkcmVzcyBpcyB0aGUgbGVhc3QgbGlrZWx5IHRvIGNo
YW5nZSBvZiBhbnkgY29udGFjdCB3ZSBtaWdodCBnaXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5Qcm9wb3NlZCBjaGFuZ2U6IFN3YXAgb3V0IHBlcnNvbmFsIGVtYWlsIGNvbnRhY3QocykgZm9y
IElFU0cgYWRkcmVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsmZ3Q7LSBDaGFu
Z2UgY29udHJvbDogJm5ic3A7SW4gNS4xLjEsIHNob3VsZG7igJl0IHRoYXQgYmUgdGhlIFBBWUxP
QUQgd29ya2luZyBncm91cCAob3IgaXTigJlzIHN1Y2Nlc3NvciBhcyBkZWxlZ2F0ZWQgYnkgdGhl
IElFU0cuLi4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQomZ3Q7
Jmd0O1Byb3Bvc2VkIGNoYW5nZTogJm5ic3A7Q2hhbmdlIHRvICZxdW90O0lFVEYgQXVkaW8vVmlk
ZW8gUGF5bG9hZHMgVHJhbnNwb3J0IFBheWxvYWRzIFdvcmtpbmcgR3JvdXDigJ08bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jmd0O0kgc3VnZ2VzdCBhZGRpbmcg4oCcLi4uIG9yIGl04oCZcyBzdWNj
ZXNzb3IgYXMgZGVsZWdhdGVkIGJ5IHRoZSBJRVNHLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N
b2RpZmllZCBwcm9wb3NlZCBjaGFuZ2U6Jm5ic3A7IENoYW5nZSB0byDigJxJRVRGIEF1ZGlvL1Zp
ZGVvIFBheWxvYWRzIFRyYW5zcG9ydCBQYXlsb2FkcyBXb3JraW5nIEdyb3VwIG9yIGl0cyBzdWNj
ZXNzb3IgYXMgZGVzaWduYXRlZCBieSB0aGUgSUVTR+KAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mZ3Q7Jmd0OyZndDstIEFyZSB0aGVzZSByZWdpc3RyYXRpb25zIHJlYWxseSBpbnRlbmRlZCB0
byBiZSBwcm92aXNpb25hbD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi
cj4NCiZndDsmZ3Q7QXQgdGhpcyBwb2ludCwgbm8uPGJyPg0KJmd0OyZndDtQcm9wb3NlZCBjaGFu
Z2U6ICZuYnNwO0VsaW1pbmF0ZSBtZW50aW9uIG9mIHByb3Zpc2lvbmFsIHJlZ2lzdHJhdGlvbiBm
b3IgYWxsIG1lZGlhIHR5cGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SSBhZ3JlZS4g
SG93ZXZlciB0aGlzIGlzIGFub3RoZXIgbWF0ZXJpYWwgY2hhbmdlIHRoYXQgc2hvdWxkIGJlIHBv
aW50ZWQgb3V0IHRvIHRoZSBXRy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3aWxsIHBvaW50
IHRoaXMgb3V0IGluIGEgZm9sbG93LW9uIGVtYWlsIHRvIHRoZSBXRyBsaXN0IGFmdGVyIEkgc3Vi
bWl0IHRoZSBuZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZn
dDstIOKAnEluIGEgbmV0d29yay1mcmllbmRseSBpbXBsZW1lbnRhdGlvbuKAnTogRG8geW91IGV4
cGVjdCB0byBzZWUgbmV0d29yay11bmZyaWVuZGx5IGltcGxlbWVudGF0aW9ucz8gSXMgdGhhdCBv
a2F5PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyZndDtJ
IGRvbid0IHZpZXcgJnF1b3Q7bmV0d29yay1mcmllbmRseSZxdW90OyBhcyBiZWluZyBhIHN0YXRp
YyBjb25kaXRpb24uICZuYnNwO1RoZXJlIGFyZSBzY2VuYXJpb3Mgd2hlcmUgYW4gRkVDIHRyYW5z
bWl0dGVyL3JlY2VpdmVyIHBhaXIgaGF2ZSBuZWdvdGlhdGVkIGEgY29ubmVjdGlvbiB3aGljaCBp
cyBuZXR3b3JrLWZyaWVuZGx5IGZvciBvbmUgYXBwbGljYXRpb24sIGJ1dCBtYXkgbm90IGJlIGZv
ciBhIGRpZmZlcmVudCBhcHBsaWNhdGlvbi4gJm5ic3A7VGhlcmUgd2FzIGEgZGlzY3Vzc2lvbg0K
IGFib3V0IHdoZW4gRkVDIGlzIGFwcHJvcHJpYXRlIGFuZCB3aGVuIGl0IGlzIG5vdCBvbiB0aGUg
V2ViUlRDIG1haWxpbmcgbGlzdHMgLSBzZWUNCjxhIGhyZWY9Imh0dHBzOi8vbGlzdHMudzMub3Jn
L0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtd2VicnRjLzIwMThOb3YvMDE1Ni5odG1sIj5odHRwczov
L2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMvcHVibGljLXdlYnJ0Yy8yMDE4Tm92LzAxNTYu
aHRtbDwvYT4uICZuYnNwOyZuYnNwOyZxdW90O05ldHdvcmstdW5mcmllbmRseSZxdW90OyBpbXBs
ZW1lbnRhdGlvbnMgY291bGQgY29uY2VpdmFibHkgb2NjdXIgd2hlbiBhbiBGRUMgc2Vzc2lvbiBo
YXMgYmVlbiBuZWdvdGlhdGVkIGJldHdlZW4NCiBlbmRwb2ludHMsIGJ1dCBuZWl0aGVyIGVuZHBv
aW50IGhhcyBhc3Nlc3NlZCB0cmFuc21pc3Npb24gY29uZGl0aW9ucy4gPG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZndDtJcyB0aGF0IGEgcmVhc29uYWJseSBpbXBsZW1lbnRhdGlvbj8gSXQgc291
bmRzIGxpa2UgYSBidWcgdG8gbWUuIChJIHByb2JhYmx5IGNvdWxkIGhhdmUgcGhyYXNlZCBteSBx
dWVzdGlvbiBiZXR0ZXIgYXMg4oCcIGFyZSBuZXR3b3JrLXVuZnJpZW5kbHkgaW1wbGVtZW50YXRp
b25zIGV2ZXIgYWNjZXB0YWJsZeKAnS4pPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0O0luIHNob3J0LCBJIHRoaW5rIHRoZSB0ZXh0IGlzIGZp
bmUgYXMgaXMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7SSBkaXNhZ3JlZS4g
4oCcTmV0d29yay1mcmllbmRseeKAnSBpcyBhIGNvbmRpdGlvbiB0aGF0IHRyaWdnZXJzIGEgU0hP
VUxELiBJIHRoaW5rIHRoZXJl4oCZcyBhIGhpZ2ggY2hhbmNlIHlvdSB3aWxsIHNlZSBkaWZmZXJl
bnQgaW1wbGVtZW50b3JzIGludGVycHJldCB0aGF0IGNvbmRpdGlvbiBkaWZmZXJlbnRseS4gSWYg
dGhlIGludGVudCBpcyB0byBnaXZlIG5vcm1hdGl2ZSBndWlkYW5jZSwgdGhlcmUgbmVlZHMgdG8g
YmUNCiBlbm91Z2ggaW5mb3JtYXRpb24gdG8gYXZvaWQgdGhhdC4gT1RPSCwgaWYgdGhlIGludGVu
dCBpcyB0byBwb2ludCBvdXQgdGhpbmdzIGFuIGltcGxlbWVudGVyIG5lZWRzIHRvIHRoaW5rIGFi
b3V0LCB0aGVuIHRoZSBub3JtYXRpdmUgU0hPVUxEIG1heSBub3QgYmUgYXBwcm9wcmlhdGUuPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgSSBhZ3JlZSB3aXRoIHlvdXIgaW50ZXJwcmV0YXRp
b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj5Q
cm9wb3NlZCBjaGFuZ2U6Jm5ic3A7IOKAnEluIGEgbmV0d29yay1mcmllbmRseSBpbXBsZW1lbnRh
dGlvbiwgYW4gYXBwbGljYXRpb24gc2hvdWxkIGF2b2lkIHNlbmRpbmcvcmVjZWl2aW5nIEZFQyBy
ZXBhaXIgc3RyZWFtcyBpZiBpdCBrbm93cyB0aGF0IHNlbmRpbmcvcmVjZWl2aW5nIHRob3NlIEZF
QyByZXBhaXIgc3RyZWFtcyB3b3VsZCBub3QgaGVscCBhdCBhbGwgaW4gcmVjb3ZlcmluZw0KIHRo
ZSBtaXNzaW5nIHBhY2tldHMu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+RW5zdWluZyBsYW5n
dWFnZSBvbiBSRUNPTU1FTkRFRCBwcmFjdGljZXMgY2FuIHJlbWFpbiB1bmNoYW5nZWQuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9u
ZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7Jmd0O8KnMS4xLjE6IC0g
SXQgd291bGQgYmUgaGVscGZ1bCB0byBkZXNjcmliZSB3aGF0IEwgYW5kIEQgcmVwcmVzZW50IGhl
cmUsIG9yIGF0IGxlYXN0IGdpdmUgYSBmb3J3YXJkIHJlZmVyZW5jZSB0byB0aGUgZGVmaW5pdGlv
bi4gKEkgbm90ZSB0aGF0IGEgbG90IG9mIHRleHQgZ29lcyBieSBiZWZvcmUgeW91IGdldCB0byB0
aGUgJm5ic3A7ZGVmaW5pdGlvbnMgb3IgdGhlIDIxMTkgYm9pbGVycGxhdGUuKTxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmd0OyZndDtDdXJyZW50IHRleHQgc3Rh
dGVzOiAmbmJzcDsmcXVvdDsgQ29uc2lkZXIgYSBncm91cCBvZiBEIHggTCBzb3VyY2UgcGFja2V0
cyB0aGF0IGhhdmUgc2VxdWVuY2UgbnVtYmVycyBzdGFydGluZyBmcm9tIDEgcnVubmluZyB0byBE
IHggTCwgYW5kIGEgcmVwYWlyIHBhY2tldCBpcyBnZW5lcmF0ZWQgYnkgYXBwbHlpbmcgdGhlIFhP
UiBvcGVyYXRpb24gdG8gZXZlcnkgTCBjb25zZWN1dGl2ZSBwYWNrZXRzIGFzIHNrZXRjaGVkIGlu
IEZpZ3VyZSAzLiZxdW90Ozxicj4NCiZndDsmZ3Q7SSBkb24ndCB0aGluayB0aGF0IHRoZXJlIGlz
IGEgZnVydGhlciBkZWZpbml0aW9uIHJlcXVpcmVkLiAmbmJzcDtIb3dldmVyLCBhbiBhZGRpdGlv
biBzZW50ZW5jZSBjb3VsZCBmb2xsb3cgdGhlIGFib3ZlIGRlc2NyaXB0aW9uIHRvIGNsYXJpZnku
DQo8YnI+DQomZ3Q7Jmd0O1Byb3Bvc2VkIHRleHQ6ICZuYnNwOyZxdW90O0luIGdlbmVyYWwsIEQg
YW5kIEwgcmVwcmVzZW50IHZhbHVlcyB0aGF0IGRlc2NyaWJlIGhvdyBwYWNrZXRzIGFyZSBncm91
cGVkIHRvZ2V0aGVyIGZvciBwYXJpdHkgY29kZSBnZW5lcmF0aW9uIHdoZW4gaW50ZXJsZWF2aW5n
IGFsbCBEIHggTCBzb3VyY2UgcGFja2V0cy7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0
O1RoYXTigJlzIGtpbmQgb2YgY2lyY3VsYXIgZXhwbGFuYXRpb24uIEkgd2FzIGp1c3QgbG9va2lu
ZyBmb3Igc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiDigJgg4oCcROKAnSBhbmQg4oCcTOKA
nSByZXByZXNlbnQgdGhlIGRlcHRoIGFuZCBsZW5ndGgsIHJlc3BlY3RpdmVseeKAnS48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25l
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0
LWF1dG9zcGFjZTpub25lIj5Qcm9wb3NlZCBjaGFuZ2U6Jm5ic3A7IEFkZCBmb2xsb3dpbmcgc2Vu
dGVuY2Ug4oCTIOKAnEluIGdlbmVyYWwgRCBhbmQgTCByZXByZXNlbnQgdmFsdWVzIHRoYXQgZGVz
Y3JpYmUgaG93IHBhY2tldHMgYXJlIGdyb3VwZWQgdG9nZXRoZXIgZnJvbSBhIGRlcHRoIGFuZCBs
ZW5ndGggcGVyc3BlY3RpdmUgKHJlc3BlY3RpdmVseSkgd2hlbiBpbnRlcmxlYXZpbmcgYWxsIEQg
eCBMIHNvdXJjZQ0KIHBhY2tldHMu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyZndDvCpzQuMi4yLCBwYXJhZ3JhcGggYWZ0ZXIg
RmlndXJlIDEwOiBUaGUgdGV4dCBzZWVtcyB0byBiZSBzdWdnZXN0IHRoZXJlIGlzIG9uZSBzb3Vy
Y2UgcGFja2V0IHByb3RlY3RlZCBieSBhIGdpdmVuIHJlcGFpciBwYWNrZXQuIElJVUMsIHRoYXTi
gJlzIG5vdCB0aGUgY2FzZTsgYSBnaXZlbiBGRUMgcGFja2V0IHByb3RlY3RzIHNldmVyYWwgc291
cmNlIHBhY2tldHMsIGRvZXNu4oCZdCBpdD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NCiZndDsmZ3Q7VGhlIHRleHQgcmVhZHMgaW4gcGFydCAmcXVvdDsuLi4gaW5j
bHVkZXMgcmVwYWlyIG9mIGV2ZXJ5dGhpbmcgZm9sbG93aW5nIHRoZSBmaXhlZCAxMi1ieXRlIFJU
UCBoZWFkZXIgb2YgdGhlIHNvdXJjZSBwYWNrZXQgLi4uJnF1b3Q7LiAmbmJzcDs8YnI+DQomZ3Q7
Jmd0OyZxdW90Oy4uLiBldmVyeXRoaW5nIGZvbGxvd2luZyAuLi4mcXVvdDsgaW1wbGllcyBtb3Jl
IHRoYW4ganVzdCBhIHNpbmdsZSBzb3VyY2UgUlRQIHBhY2tldC4gJm5ic3A7PG86cD48L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZndDtMZXTigJlzIHNheSBmb3IgYXJndW1lbnQgdGhhdCB0aGUgcmVwYWly
IHBhY2tldCBwcm90ZWN0cyAyIHNvdXJjZSBwYWNrZXRzLiBJcyB0aGUgMTItYnl0ZSBSVFAgaGVh
ZGVyIG9mIHRoZSAybmQgcGFja2V0IHByb3RlY3RlZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPiZndDsoRXZlbiBpZiB0aGUgYW5zd2VyIGlzIHllcywgaXQgd291bGQgYmUg
aGVscGZ1bCB0byBzYXkgJnF1b3Q7IC4uLiBhbmQgc3Vic2VxdWVudCBwYWNrZXRzLi4uJnF1b3Q7
KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw
YWNlOm5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPkFzIHBlciB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgU2Vj
LiA0LjE6Jm5ic3A7ICZxdW90O1RoZSBzb3VyY2UgcGFja2V0cyBhcmUgZnVsbCBSVFAgcGFja2V0
cyB3aXRoIG9wdGlvbmFsIENTUkMgbGlzdCwgUlRQIGhlYWRlciBleHRlbnNpb24sIGFuZCBwYWRk
aW5nLiBJZiBhbnkgb2YgdGhlc2Ugb3B0aW9uYWwgZWxlbWVudHMgYXJlIHByZXNlbnQgaW4gdGhl
IHNvdXJjZSBSVFAgcGFja2V0LA0KIGFuZCB0aGF0IHNvdXJjZSBwYWNrZXQgaXMgbG9zdCwgdGhl
eSBhcmUgcmVjb3ZlcmVkIGJ5IHRoZSBGRUMgcmVwYWlyIG9wZXJhdGlvbiwgd2hpY2ggcmVjb3Zl
cnMgdGhlIGZ1bGwgc291cmNlIFJUUCBwYWNrZXQgaW5jbHVkaW5nIHRoZXNlIG9wdGlvbmFsIGVs
ZW1lbnRzLuKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl
eHQtYXV0b3NwYWNlOm5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPlByb3Bvc2VkIGNoYW5nZTombmJzcDsg
Q2hhbmdlIOKAnC4uLiBpbmNsdWRlcyByZXBhaXIgb2YgZXZlcnl0aGluZyBmb2xsb3dpbmcgdGhl
IGZpeGVkIDEyLWJ5dGUgUlRQIGhlYWRlciBvZiB0aGUgc291cmNlIHBhY2tldCAuLi4mcXVvdDsg
dG8g4oCcLi4uIGluY2x1ZGVzIHJlcGFpciBvZiBldmVyeXRoaW5nIGZvbGxvd2luZyB0aGUgZml4
ZWQgMTItYnl0ZSBSVFAgaGVhZGVyIG9mIHRoZQ0KIHNvdXJjZSBwYWNrZXQgYWxvbmcgd2l0aCBz
dWJzZXF1ZW50IHNvdXJjZSBwYWNrZXRzIC4uLiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsmZ3Q7wqc5LCBsYXN0IHBhcmFn
cmFwaDogSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGludGVudCBvZiB0aGUgbGFzdCBzZW50ZW5j
ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZndDsmZ3Q7T3Jp
Z2luYWxseSBzdWdnZXN0ZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y
Zy9hcmNoL21zZy9wYXlsb2FkL0FJSHc1RFNBQkVKTGE2bFNPTHJ5TGRJMGVCayI+DQpodHRwczov
L21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3BheWxvYWQvQUlIdzVEU0FCRUpMYTZsU09M
cnlMZEkwZUJrPC9hPi4gJm5ic3A7VGhlIGFwcGxpY2F0aW9uIHNvdXJjZSBkYXRhIG1heSBub3Qg
YmUgcGVyZmVjdGx5IG1hdGNoZWQgd2l0aCBGTEVYIEZFQyBzb3VyY2UgcGFydGl0aW9uaW5nLiAm
bmJzcDtJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IGZvciB1bnBy
b3RlY3RlZCBzb3VyY2UgZGF0YSBpZiwgZm9yIGluc3RhbmNlLA0KIHRoZSBGTEVYIEZFQyBpbXBs
ZW1lbnRhdGlvbiBkaXNjYXJkcyBkYXRhIHRoYXQgZG9lcyBub3QgZml0IHBlcmZlY3RseSBpbnRv
IGl0cyBzb3VyY2UgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMuPG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZndDtUaGF0IGV4cGxhbmF0aW9uIGlzIG1vcmUgY2xlYXIgdGhhbiB0aGUgdGV4dCBpbiB0
aGUgZHJhZnQuIEkgc3VnZ2VzdCBpbmNsdWRpbmcgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+
UHJvcG9zZWQgY2hhbmdlOiZuYnNwOyBSZXBsYWNlIOKAnEluIGFkZGl0aW9uLCB0aGUgaW50ZXJh
Y3Rpb24gYmV0d2VlbiBhIEZMRVggRkVDIGltcGxlbWVudGF0aW9uIGFuZCBoaWdoZXItbGF5ZXIg
YXBwbGljYXRpb25zIG1heSBiZSBhZmZlY3RlZCBieSBub24tdW5pZm9ybSBwcm9jZXNzaW5nIHJl
cXVpcmVtZW50cyBvZiB0aGUgRkVDIHNjaGVtZeKAnSB3aXRoIOKAnE1vcmVvdmVyDQogdGhlIGFw
cGxpY2F0aW9uIHNvdXJjZSBkYXRhIG1heSBub3QgYmUgcGVyZmVjdGx5IG1hdGNoZWQgd2l0aCBG
TEVYIEZFQyBzb3VyY2UgcGFydGl0aW9uaW5nLiAmbmJzcDtJZiB0aGlzIGlzIHRoZSBjYXNlLCB0
aGVyZSBpcyBhIHBvc3NpYmlsaXR5IGZvciB1bnByb3RlY3RlZCBzb3VyY2UgZGF0YSBpZiwgZm9y
IGluc3RhbmNlLCB0aGUgRkxFWCBGRUMgaW1wbGVtZW50YXRpb24gZGlzY2FyZHMgZGF0YSB0aGF0
IGRvZXMgbm90IGZpdCBwZXJmZWN0bHkgaW50bw0KIGl0cyBzb3VyY2UgcHJvY2Vzc2luZyByZXF1
aXJlbWVudHMu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
dGV4dC1hdXRvc3BhY2U6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw
YWNlOm5vbmUiPi1HaXJpIE1hbmR5YW08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5
bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu
MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBCZW4g
Q2FtcGJlbGwgJmx0O2JlbkBub3N0cnVtLmNvbSZndDsgPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVy
ZGF5LCBEZWNlbWJlciAyMiwgMjAxOCA5OjE1IFBNPGJyPg0KPGI+VG86PC9iPiBHaXJpZGhhciBN
YW5keWFtICZsdDttYW5keWFtQHF0aS5xdWFsY29tbS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBk
cmFmdC1pZXRmLXBheWxvYWQtZmxleGlibGUtZmVjLXNjaGVtZS5hbGxAaWV0Zi5vcmc7IHBheWxv
YWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEFEIEV2YWx1YXRpb24gb2YgZHJh
ZnQtaWV0Zi1wYXlsb2FkLWZsZXhpYmxlLWZlYy1zY2hlbWUtMTM8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCB0aGFua3MgZm9yIHRoZSBxdWljayByZXNwb25zZSEg
Q29tbWVudHMgaW5saW5lLiBJIHJlbW92ZWQgc2VjdGlvbnMgdGhhdCBzZWVtIHJlc29sdmVkLjxv
OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVuLjxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDIyLCAyMDE4LCBh
dCA3OjM4IFBNLCBHaXJpZGhhciBNYW5keWFtICZsdDs8YSBocmVmPSJtYWlsdG86bWFuZHlhbUBx
dGkucXVhbGNvbW0uY29tIj5tYW5keWFtQHF0aS5xdWFsY29tbS5jb208L2E+Jmd0OyB3cm90ZTo8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBm
b3IgdGhlIGNhcmVmdWwgcmV2aWV3LiAmbmJzcDtCZWZvcmUgc3VibWl0dGluZyByZXYgMTQsIEkg
d291bGQgbGlrZSB0byBnZXQgYWdyZWVtZW50IG9uIHRoZSBmb2xsb3dpbmcgcHJvcG9zZWQgY2hh
bmdlcy48YnI+DQotR2lyaTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5HZW5lcmFsOiBEbyBJIHJlYWQgY29ycmVjdGx5IHRoYXQgdGhpcyBk
b2N1bWVudCBjYW4gY29tcGxldGVseSBzdGFuZCBhbG9uZSBmcm9tIFJGQyA2MzYzPyBUaGF0IGlz
LCB0aGUgY2FsY3VsYXRpb24gb2YgdGhlIHByb3RlY3Rpb24gc3RyZWFtIGFuZCByZWNvbnN0cnVj
dGlvbiBvZiBsb3N0IHNvdXJjZSBwYWNrZXRzIGlzIGNvbXBsZXRlbHkgc3BlY2lmaWVkIGluIHRo
aXMgZG9jdW1lbnQ/IEkgZG9u4oCZdCBzZWUNCiB0aGF0IGFzIGEgcHJvYmxlbSwgYnV0IGlmIGl0
4oCZcyBjb3JyZWN0IHNvbWUgaW50cm9kdWN0aW9uIHRleHQgdG8gdGhhdCBlZmZlY3Qgd291bGQg
YmUgaGVscGZ1bC4gSXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIDYzNjMgZXZlbiBuZWVkZWQ/
PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQpGTEVYIEZFQyBjZXJ0YWlubHkgd2FzIGluc3BpcmVkIGJ5IEZFQyBGUkFNRSwgYnV0IHRoZSBk
b2N1bWVudCBjYW4gc3RhbmQgb24gaXRzIG93bi4gJm5ic3A7Jm5ic3A7Jm5ic3A7U2luY2Ugc2V2
ZXJhbCBkZWZpbml0aW9ucyBhcmUgbGV2ZXJhZ2VkIGZyb20gUkZDIDYzNjMsIEkgYmVsaWV2ZSBh
IG5vcm1hdGl2ZSByZWZlcmVuY2UgaXMgc3RpbGwgYXBwcm9wcmlhdGUuICZuYnNwO015IHN1Z2dl
c3Rpb24gaXMgdG8gYWRkIG9uZSBzZW50ZW5jZSB0byB0aGUgbGFzdCBwYXJhZ3JhcGgNCiBvZiBT
ZWN0aW9uIDEuPGJyPg0KPGJyPg0KUHJvcG9zZWQgY2hhbmdlOiAmbmJzcDtBZGQgJnF1b3Q7VGhp
cyBkb2N1bWVudCBhbHNvIGxldmVyYWdlcyBzZXZlcmFsIGRlZmluaXRpb25zIGFsb25nIHdpdGgg
dGhlIGJhc2ljIHNvdXJjZS9yZXBhaXIgaGVhZGVyIGRlc2NyaXB0aW9uIGZyb20gUkZDIDYzNjMg
aW4gdGhlaXIgYXBwbGljYXRpb24gdG8gdGhlIHBhcml0eSBjb2RlcyBkZWZpbmVkIGhlcmUu4oCd
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBoZWxwcy4gSSBtaWdodCBzdWdnZXN0IHNvbWV0aGlu
ZyBhbG9uZyB0aGUgbGluZXMgb2Yg4oCcV2hpbGUgdGhpcyBkb2N1bWVudCBmdWxseSBkZWZpbmVz
IHRoZSB1c2Ugb2YgRkVDIHRvIHByb3RlY3QgUlRQIHN0cmVhbXMsIGl0IGFsc28gbGV2ZXJhZ2Vz
Li4u4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlsuLi5dPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJs
b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj7CpzQuMi4xOjxicj4NCi0gVGhlcmXigJlzIGEgbnVtYmVyIG9m
IDIxMTkvODE3NCBrZXl3b3JkcyBpbiB0aGlzIHNlY3Rpb24gdGhhdCBzZWVtIG1vcmUgbmF0dXJh
bCBjb25zZXF1ZW5jZXMgb2YgdXNpbmcgUlRQIHRoYW4gbmV3IG5vcm1hdGl2ZSByZXF1aXJlbWVu
dHMuIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoZXkgc2hvdWxkbuKAmXQgdXNlIG5vcm1hdGl2ZSBr
ZXl3b3JkcyB1bmxlc3MgaW4gdGhlIGZvcm0gb2YgZGlyZWN0IHF1b3Rlcy48bzpwPjwvbzpwPjwv
cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkFwb2xvZ2llcyAt
IEkgaGFkIHRyb3VibGUgaWRlbnRpZnlpbmcgc3VjaCBpbnN0YW5jZXMuICZuYnNwO0FsbCBpbnN0
YW5jZXMgb2Ygc3VjaCBrZXl3b3JkcyBhcmUgcmVsYXRlZCB0byByZXF1aXJlbWVudHMgd2l0aCBy
ZXNwZWN0IHRvIFJGQyAzNTUwLiAmbmJzcDtEbyB5b3UgaGF2ZSBzcGVjaWZpYyBleGFtcGxlcz88
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGRlZmluaXRpb24gb2Ygc2VxdWVuY2UgbnVtYmVyLiBEb2Vz
buKAmXQgUlRQIGFscmVhZHkgcmVxdWlyZSB0aGUgc2VxdWVuY2UgbnVtYmVyIHRvIGluY3JlbWVu
dCBieSBvbmUsIGFuZCByZWNvbW1lbmQgdGhlIHVzZSBvZiBhIHJhbmRvbSBzdGFydGluZyB2YWx1
ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
LSBkZWZpbml0aW9uIG9mIHRpbWUgc3RhbXA6IEkgaW5pdGlhbGx5IHRob3VnaHQgdGhhdCB0aGUg
U0hBTEwgcmVmbGVjdGVkIGEgcmVxdWlyZW1lbnQgYWxyZWFkeSBpbiAzNTUwLCBidXQgbm93IEkg
cmVhbGl6ZSB0aGF0IHRyYW5zbWlzc2lvbiB0aW1lIGlzIG5vdCB0aGUgc2FtZSBhcyBzYW1wbGlu
ZyB0aW1lLiAmbmJzcDtTbyB0aGlzIG9uZSBpcyBwcm9iYWJseSBva2F5LjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFNTUkM6IDM1NTAgYWxy
ZWFkeSBzYXlzIFNTUkNzIFNIT1VMRCBiZSBhc3NpZ25lZCByYW5kb21seSwgc28gdGhlIHJlcXVp
cmVtZW50IGlzIGEgc3RhdGVtZW50IG9mIGZhY3QgYXMgZmFyIGFzIF90aGlzXyBzcGVjIGlzIGNv
bmNlcm5lZC4gKFRoZSB0ZXh0IGV2ZW4gbWVudGlvbnMg4oCcYXMgc3VnZ2VzdGVkIGJ5IFJGQyAz
MzUwJnF1b3Q7LCBhbHRob3VnaCAzNTUwIGRvZXMgbW9yZSB0aGFuIOKAnHN1Z2dlc3TigJ0gaXQu
KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4t
ICZxdW90OzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDb3VyaWVyIj50aGUgY29sbGlzaW9ucyZu
YnNwO01VU1QgYmUgcmVzb2x2ZWQgYXMgZGVzY3JpYmVkIGluIFtSRkMzNTUwXeKAnSA6IGFnYWlu
LCB0aGF0IGZvbGxvd3MgbmF0dXJhbGx5IGZyb20gdXNpbmcgUlRQLiBJdCBkb2VzIG5vdCBkZWZp
bmUgYSBuZXcgcmVxdWlyZW1lbnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw
PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206
NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSAxMHRoIHBhcmFncmFwaDogJnF1b3Q7VGhl
IHJlcGFpciBzdHJlYW1z4oCZIFNTUkPigJlzIENOQU1FIFNIT1VMRCBiZSBpZGVudGljYWwgdG8g
dGhlIENOQU1FIG9mIHRoZSBzb3VyY2UgUlRQIHN0cmVhbShzKSB0aGF0IHRoaXMgcmVwYWlyIHN0
cmVhbSBwcm90ZWN0cy7igJ0gV2h5IGlzIHRoZSBTSE9VTEQgbm90IGEgTVVTVD8gV2hhdCBoYXBw
ZW5zIGlmIGl0IGlzIHZpb2xhdGVkPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUHJvcG9zZWQgY2hhbmdlOiAmbmJzcDtBZ3JlZWQgdGhh
dCB0aGUgcmVxdWlyZW1lbnQgbWFrZXMgbW9yZSBzZW5zZSBhcyBhIE1VU1QuICZuYnNwO1dpbGwg
Y2hhbmdlIGFjY29yZGluZ2x5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgY29uY3VyIHdpdGggdGhl
IGNoYW5nZSwgYnV0IGl0IGlzIGEgbWF0ZXJpYWwgY2hhbmdlLiBQbGVhc2UgcG9pbnQgaXQgb3V0
IHRvIHRoZSBXRyBpbiBjYXNlIGFueW9uZSBvYmplY3RzLiAoSXQgbWF5IG5vdCBiZSBzYWZlIHRv
IGFzc3VtZSBwZW9wbGUgYXJlIHJlYWRpbmcgdGhpcyBub3RlIGluIHRoYXQgbGV2ZWwgb2YgZGV0
YWlsLCBlc3BlY2lhbGx5IG92ZXIgdGhlIGhvbGlkYXlzIDotKSkgVG8gYmUgY2xlYXIsDQogSSBk
b27igJl0IHdhbnQgdG8gYmxvY2sgcHJvZ3Jlc3Mgb2YgdGhlIGRyYWZ0IG92ZXIgaXQ7IGlmIGFu
eW9uZSBvYmplY3RzIHRoZXkgY2FuIGRvIHNvIGFzIHBhcnQgb2YgdGhlIElFVEYgbGFzdCBjYWxs
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b
Li4uXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8
YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqc0
LjIuMjogUGxlYXNlIGFkZCBhIHNob3J0IGV4cGxhbmF0aW9uIG9mIHdoeSB3ZSBuZWVkIHR3byBk
aWZmZXJlbnQgRkVDIHBhY2tldCBmb3JtYXRzLiAoTm90IGNvdW50aW5nIHRoZSByZXRyYW5zbWlz
c2lvbiBwYWNrZXQ7IHRoZSByZWFzb25pbmcgdGhlcmUgaXMgcHJldHR5IG9idmlvdXMuKTxvOnA+
PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUHJv
cG9zZWQgY2hhbmdlOiAmbmJzcDtBZGQgYWRkaXRpb25hbCBzZW50ZW5jZSB0byBmaXJzdCBwYXJh
Z3JhcGggb2YgU2VjLiA0LjIuMjogJm5ic3A7JnF1b3Q7VHdvIG9mIHRoZXNlIHZhcmlhbnRzIGFy
ZSBtZWFudCB0byBkZXNjcmliZSBkaWZmZXJlbnQgbWV0aG9kcyBmb3IgZGVyaXZpbmcgdGhlIHNv
dXJjZSBkYXRhIGZyb20gYSBzb3VyY2UgcGFja2V0IGZvciBhIHJlcGFpciBwYWNrZXQuICZuYnNw
O1RoZSB0aGlyZCB2YXJpYW50IGlzIGZvciBhIHN0cmFpZ2h0IHJldHJhbnNtaXNzaW9uDQogb2Yg
dGhlIHNvdXJjZSBwYWNrZXQu4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdOKAmXMgdXNlZnVs
LCBidXQgaXQgZG9lc27igJl0IGV4cGxhaW4gX3doeV8gd2UgbmVlZCB0d28gZGlmZmVyZW50IG1l
dGhvZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
Cjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7C
pzUuMS4xIChhbmQgc3Vic2VxdWVudCBtZWRpYSB0eXBlIGRlZmluaXRpb25zKSAtIFBsZWFzZSBj
b25zaWRlciB1c2luZyB0aGUgSUVTRyAoPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmll
c2dAaWV0Zi5vcmc8L2E+KSBhcyB0aGUgY29udGFjdCBmb3IgZnVydGhlciBpbmZvcm1hdGlvbi4g
V29ya2luZyBncm91cHMgY29tZSBhbmQgZ28sIGFuZCBhdXRob3JzIGNoYW5nZSBqb2JzLiBCdXQg
c29tZW9uZQ0KIG9uIHRoZSBJRVNHIHNob3VsZCAoaG9wZWZ1bGx5KSBhbHdheXMgYmUgYWJsZSB0
byBmaW5kIHRoZSByaWdodCBwZXJzb24sPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpURU5UQVRJVkUgcHJvcG9zZWQgY2hhbmdlOiAmbmJz
cDtJIGFtIGhhcHB5IHRvIHN3YXAgb3V0IFZhcnVuJ3MgZW1haWwgZm9yIElFU0csIGJ1dCB0aGlz
IGRvZXMgbm90IHNlZW0gdG8gYmUgYSB3aWRlc3ByZWFkIHByYWN0aWNlIGV2ZW4gZm9yIHJlY2Vu
dGx5LXB1Ymxpc2hlZCBSRkMncy4gJm5ic3A7Q2FuIHlvdSBjb25maXJtIHRoYXQgdGhpcyBpcyBu
b3cgYmVjb21pbmcgYSBiZXN0IHByYWN0aWNlIGZvciBjb250YWN0IGluZm8gcmVnYXJkaW5nIHJl
Z2lzdHJpZXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzIGJlZW4gY29tbW9uIG9mIGxhdGUu
IFRoZSByZWFzb25pbmcgaXMgdGhhdCB0aGUgSUVTRyBlbWFpbCBhZGRyZXNzIGlzIHRoZSBsZWFz
dCBsaWtlbHkgdG8gY2hhbmdlIG9mIGFueSBjb250YWN0IHdlIG1pZ2h0IGdpdmUuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIENoYW5nZSBjb250cm9s
OiAmbmJzcDtJbiA1LjEuMSwgc2hvdWxkbuKAmXQgdGhhdCBiZSB0aGUgUEFZTE9BRCB3b3JraW5n
IGdyb3VwIChvciBpdOKAmXMgc3VjY2Vzc29yIGFzIGRlbGVnYXRlZCBieSB0aGUgSUVTRy4uLik8
bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4N
ClByb3Bvc2VkIGNoYW5nZTogJm5ic3A7Q2hhbmdlIHRvICZxdW90O0lFVEYgQXVkaW8vVmlkZW8g
UGF5bG9hZHMgVHJhbnNwb3J0IFBheWxvYWRzIFdvcmtpbmcgR3JvdXDigJ08bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JIHN1Z2dlc3QgYWRkaW5nIOKAnC4uLiBvciBpdOKAmXMgc3VjY2Vzc29yIGFzIGRl
bGVnYXRlZCBieSB0aGUgSUVTRy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+LSBBcmUgdGhlc2UgcmVnaXN0cmF0aW9ucyByZWFsbHkgaW50ZW5kZWQg
dG8gYmUgcHJvdmlzaW9uYWw/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQpBdCB0aGlzIHBvaW50LCBuby48YnI+DQo8YnI+DQpQcm9wb3Nl
ZCBjaGFuZ2U6ICZuYnNwO0VsaW1pbmF0ZSBtZW50aW9uIG9mIHByb3Zpc2lvbmFsIHJlZ2lzdHJh
dGlvbiBmb3IgYWxsIG1lZGlhIHR5cGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUuIEhv
d2V2ZXIgdGhpcyBpcyBhbm90aGVyIG1hdGVyaWFsIGNoYW5nZSB0aGF0IHNob3VsZCBiZSBwb2lu
dGVkIG91dCB0byB0aGUgV0cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj7CpzUuMi4xLCBsYXN0IGJ1bGxldDogJnF1b3Q7QW55IHVua25vd24gb3B0aW9u
IGluIHRoZSBvZmZlciBNVVNUIGJlIGlnbm9yZWQgYW5kIGRlbGV0ZWQgZnJvbSB0aGUgYW5zd2Vy
LuKAnTogSXMgdGhhdCBhIGEgbmV3IHJlcXVpcmVtZW50IHNwZWNpZmljIHRvIGZsZXgtZmVjLCBv
ciBqdXN0IGEgbm9ybWFsIG9mZmVyL2Fuc3dlciByZXF1aXJlbWVudD88bzpwPjwvbzpwPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClJGQyAzMjY0IFNlY3Rp
b24gNiBzdGF0ZXM8YnI+DQonRm9yIGVhY2ggJnF1b3Q7bT0mcXVvdDsgbGluZSBpbiB0aGUgb2Zm
ZXIsIHRoZXJlIE1VU1QgYmUgYSBjb3JyZXNwb25kaW5nICZxdW90O209JnF1b3Q7IGxpbmUgaW4g
dGhlIGFuc3dlci4gJm5ic3A7VGhlIGFuc3dlciBNVVNUIGNvbnRhaW4gZXhhY3RseSB0aGUgc2Ft
ZSBudW1iZXIgb2YgJnF1b3Q7bT0mcXVvdDsgbGluZXMgYXMgdGhlIG9mZmVyLiAmbmJzcDtUaGlz
IGFsbG93cyBmb3Igc3RyZWFtcyB0byBiZSBtYXRjaGVkIHVwIGJhc2VkIG9uIHRoZWlyIG9yZGVy
LiAmbmJzcDtUaGlzIGltcGxpZXMgdGhhdCBpZiB0aGUgb2ZmZXINCiBjb250YWluZWQgemVybyAm
cXVvdDttPSZxdW90OyBsaW5lcywgdGhlIGFuc3dlciBNVVNUIGNvbnRhaW4gemVybyAmcXVvdDtt
PSZxdW90OyBsaW5lcy4nPGJyPg0KPGJyPg0KSSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgbm9ybWFs
IG9mZmVyL2Fuc3dlci4gJm5ic3A7SXQgaXMgc3BlY2lmaWMgdG8gRkxFWCBGRUMuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+T2theS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Wy4uLl08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g4oCcSW4gYSBuZXR3b3JrLWZyaWVuZGx5IGltcGxlbWVu
dGF0aW9u4oCdOiBEbyB5b3UgZXhwZWN0IHRvIHNlZSBuZXR3b3JrLXVuZnJpZW5kbHkgaW1wbGVt
ZW50YXRpb25zPyBJcyB0aGF0IG9rYXk/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIGRvbid0IHZpZXcgJnF1b3Q7bmV0d29yay1mcmll
bmRseSZxdW90OyBhcyBiZWluZyBhIHN0YXRpYyBjb25kaXRpb24uICZuYnNwO1RoZXJlIGFyZSBz
Y2VuYXJpb3Mgd2hlcmUgYW4gRkVDIHRyYW5zbWl0dGVyL3JlY2VpdmVyIHBhaXIgaGF2ZSBuZWdv
dGlhdGVkIGEgY29ubmVjdGlvbiB3aGljaCBpcyBuZXR3b3JrLWZyaWVuZGx5IGZvciBvbmUgYXBw
bGljYXRpb24sIGJ1dCBtYXkgbm90IGJlIGZvciBhIGRpZmZlcmVudCBhcHBsaWNhdGlvbi4gJm5i
c3A7VGhlcmUgd2FzIGEgZGlzY3Vzc2lvbg0KIGFib3V0IHdoZW4gRkVDIGlzIGFwcHJvcHJpYXRl
IGFuZCB3aGVuIGl0IGlzIG5vdCBvbiB0aGUgV2ViUlRDIG1haWxpbmcgbGlzdHMgLSBzZWUNCjxh
IGhyZWY9Imh0dHBzOi8vbGlzdHMudzMub3JnL0FyY2hpdmVzL1B1YmxpYy9wdWJsaWMtd2VicnRj
LzIwMThOb3YvMDE1Ni5odG1sIj5odHRwczovL2xpc3RzLnczLm9yZy9BcmNoaXZlcy9QdWJsaWMv
cHVibGljLXdlYnJ0Yy8yMDE4Tm92LzAxNTYuaHRtbDwvYT4uICZuYnNwOyZuYnNwOyZxdW90O05l
dHdvcmstdW5mcmllbmRseSZxdW90OyBpbXBsZW1lbnRhdGlvbnMgY291bGQgY29uY2VpdmFibHkg
b2NjdXIgd2hlbiBhbiBGRUMgc2Vzc2lvbiBoYXMgYmVlbiBuZWdvdGlhdGVkIGJldHdlZW4NCiBl
bmRwb2ludHMsIGJ1dCBuZWl0aGVyIGVuZHBvaW50IGhhcyBhc3Nlc3NlZCB0cmFuc21pc3Npb24g
Y29uZGl0aW9ucy4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMgdGhhdCBhIHJlYXNvbmFibHkgaW1w
bGVtZW50YXRpb24/IEl0IHNvdW5kcyBsaWtlIGEgYnVnIHRvIG1lLiAoSSBwcm9iYWJseSBjb3Vs
ZCBoYXZlIHBocmFzZWQgbXkgcXVlc3Rpb24gYmV0dGVyIGFzIOKAnCBhcmUgbmV0d29yay11bmZy
aWVuZGx5IGltcGxlbWVudGF0aW9ucyBldmVyIGFjY2VwdGFibGXigJ0uKTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBzaG9ydCwgSSB0aGlu
ayB0aGUgdGV4dCBpcyBmaW5lIGFzIGlzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRp
c2FncmVlLiDigJxOZXR3b3JrLWZyaWVuZGx54oCdIGlzIGEgY29uZGl0aW9uIHRoYXQgdHJpZ2dl
cnMgYSBTSE9VTEQuIEkgdGhpbmsgdGhlcmXigJlzIGEgaGlnaCBjaGFuY2UgeW91IHdpbGwgc2Vl
IGRpZmZlcmVudCBpbXBsZW1lbnRvcnMgaW50ZXJwcmV0IHRoYXQgY29uZGl0aW9uIGRpZmZlcmVu
dGx5LiBJZiB0aGUgaW50ZW50IGlzIHRvIGdpdmUgbm9ybWF0aXZlIGd1aWRhbmNlLCB0aGVyZSBu
ZWVkcyB0byBiZQ0KIGVub3VnaCBpbmZvcm1hdGlvbiB0byBhdm9pZCB0aGF0LiBPVE9ILCBpZiB0
aGUgaW50ZW50IGlzIHRvIHBvaW50IG91dCB0aGluZ3MgYW4gaW1wbGVtZW50ZXIgbmVlZHMgdG8g
dGhpbmsgYWJvdXQsIHRoZW4gdGhlIG5vcm1hdGl2ZSBTSE9VTEQgbWF5IG5vdCBiZSBhcHByb3By
aWF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K
PGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPsKn
OSwgbGFzdCBwYXJhZ3JhcGg6IFdoYXQgYXJlIHRoZSBzZWN1cml0eSBpbXBsaWNhdGlvbnMgb2Yg
dW51c2VkIHNvdXJjZS1idWZmZXJzPyBJcyB0aGlzIGEgcG90ZW50aWFsIERvUyB2ZWN0b3I/PG86
cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJ
dCBjb3VsZCBiZS4gJm5ic3A7VW51c2VkIHNvdXJjZSBidWZmZXJzIGNvbWJpbmVkIHdpdGggcG90
ZW50aWFsbHkgbGFyZ2UgcGFja2V0IHNpemUgKGUuZy4gZm9yIGJ1bmRsZWQgcHJvdGVjdGlvbikg
Y291bGQgZXZlbnR1YWxseSByZXN1bHQgaW4gYSBsYWNrIG9mIHJlc291cmNlcyAoZS5nLiBtZW1v
cnkpIGluIGFuIGVuZHBvaW50Ljxicj4NCjxicj4NClByb3Bvc2VkIGFkZGl0aW9uYWwgY2xhcmlm
eWluZyB0ZXh0OiBGb2xsb3dpbmcgJm5ic3A7JnF1b3Q7R2l2ZW4gdGhhdCBGTEVYIEZFQyBlbmFi
bGVzIHRoZSBwcm90ZWN0aW9uIG9mIG11bHRpcGxlIHNvdXJjZSBzdHJlYW1zLCB0aGVyZSBleGlz
dHMgdGhlIHBvc3NpYmlsaXR5IHRoYXQgbXVsdGlwbGUgc291cmNlIGJ1ZmZlcnMgbWF5IGJlIGNy
ZWF0ZWQgdGhhdCBtYXkgbm90IGJlIHVzZWQmcXVvdDsgYWRkICZuYnNwOyZxdW90O0FuIGF0dGFj
a2VyIGNvdWxkIGxldmVyYWdlIHVudXNlZCBzb3VyY2UNCiBidWZmZXJzIHRvIGFzIGEgbWVhbnMg
b2Ygb2NjdXB5aW5nIG1lbW9yeSBpbiBhIEZMRVggRkVDIGVuZHBvaW50LuKAnTxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPldvcmtzIGZvciBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy4uLl08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPi0gMm5kIHBhcmFncmFwaDogcy9SZWR1bmFkbmN5L1JlZHVuZGFu
Y3nigJ08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pjxicj4NClByb3Bvc2VkIGNoYW5nZTogJm5ic3A7Jm5ic3A7JnF1b3Q7UmVkdW5hZG5jeSZxdW90
OyBjaGFuZ2VkIHRvICZxdW90O1JlZHVuZGFuY3kmcXVvdDsuICZuYnNwO1RoYW5rIHlvdSBmb3Ig
Y2F0Y2hpbmcgdGhpcy48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+wqcxLjEuMTogLSBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGRlc2NyaWJl
IHdoYXQgTCBhbmQgRCByZXByZXNlbnQgaGVyZSwgb3IgYXQgbGVhc3QgZ2l2ZSBhIGZvcndhcmQg
cmVmZXJlbmNlIHRvIHRoZSBkZWZpbml0aW9uLiAoSSBub3RlIHRoYXQgYSBsb3Qgb2YgdGV4dCBn
b2VzIGJ5IGJlZm9yZSB5b3UgZ2V0IHRvIHRoZSAmbmJzcDtkZWZpbml0aW9ucyBvciB0aGUgMjEx
OSBib2lsZXJwbGF0ZS4pPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQpDdXJyZW50IHRleHQgc3RhdGVzOiAmbmJzcDsmcXVvdDsgQ29uc2lk
ZXIgYSBncm91cCBvZiBEIHggTCBzb3VyY2UgcGFja2V0cyB0aGF0IGhhdmUgc2VxdWVuY2UgbnVt
YmVycyBzdGFydGluZyBmcm9tIDEgcnVubmluZyB0byBEIHggTCwgYW5kIGEgcmVwYWlyIHBhY2tl
dCBpcyBnZW5lcmF0ZWQgYnkgYXBwbHlpbmcgdGhlIFhPUiBvcGVyYXRpb24gdG8gZXZlcnkgTCBj
b25zZWN1dGl2ZSBwYWNrZXRzIGFzIHNrZXRjaGVkIGluIEZpZ3VyZSAzLiZxdW90Ozxicj4NCjxi
cj4NCkkgZG9uJ3QgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIGZ1cnRoZXIgZGVmaW5pdGlvbiByZXF1
aXJlZC4gJm5ic3A7SG93ZXZlciwgYW4gYWRkaXRpb24gc2VudGVuY2UgY291bGQgZm9sbG93IHRo
ZSBhYm92ZSBkZXNjcmlwdGlvbiB0byBjbGFyaWZ5Lg0KPGJyPg0KPGJyPg0KUHJvcG9zZWQgdGV4
dDogJm5ic3A7JnF1b3Q7SW4gZ2VuZXJhbCwgRCBhbmQgTCByZXByZXNlbnQgdmFsdWVzIHRoYXQg
ZGVzY3JpYmUgaG93IHBhY2tldHMgYXJlIGdyb3VwZWQgdG9nZXRoZXIgZm9yIHBhcml0eSBjb2Rl
IGdlbmVyYXRpb24gd2hlbiBpbnRlcmxlYXZpbmcgYWxsIEQgeCBMIHNvdXJjZSBwYWNrZXRzLuKA
nTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXTigJlzIGtpbmQgb2YgY2lyY3VsYXIgZXhwbGFuYXRp
b24uIEkgd2FzIGp1c3QgbG9va2luZyBmb3Igc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiDi
gJgg4oCcROKAnSBhbmQg4oCcTOKAnSByZXByZXNlbnQgdGhlIGRlcHRoIGFuZCBsZW5ndGgsIHJl
c3BlY3RpdmVseeKAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Wy4uLl08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj7CpzQuMi4yLCBwYXJhZ3JhcGggYWZ0ZXIgRmlndXJlIDEwOiBUaGUg
dGV4dCBzZWVtcyB0byBiZSBzdWdnZXN0IHRoZXJlIGlzIG9uZSBzb3VyY2UgcGFja2V0IHByb3Rl
Y3RlZCBieSBhIGdpdmVuIHJlcGFpciBwYWNrZXQuIElJVUMsIHRoYXTigJlzIG5vdCB0aGUgY2Fz
ZTsgYSBnaXZlbiBGRUMgcGFja2V0IHByb3RlY3RzIHNldmVyYWwgc291cmNlIHBhY2tldHMsIGRv
ZXNu4oCZdCBpdD88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NClRoZSB0ZXh0IHJlYWRzIGluIHBhcnQgJnF1b3Q7Li4uIGluY2x1ZGVzIHJl
cGFpciBvZiBldmVyeXRoaW5nIGZvbGxvd2luZyB0aGUgZml4ZWQgMTItYnl0ZSBSVFAgaGVhZGVy
IG9mIHRoZSBzb3VyY2UgcGFja2V0IC4uLiZxdW90Oy4gJm5ic3A7PGJyPg0KPGJyPg0KJnF1b3Q7
Li4uIGV2ZXJ5dGhpbmcgZm9sbG93aW5nIC4uLiZxdW90OyBpbXBsaWVzIG1vcmUgdGhhbiBqdXN0
IGEgc2luZ2xlIHNvdXJjZSBSVFAgcGFja2V0LiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5M
ZXTigJlzIHNheSBmb3IgYXJndW1lbnQgdGhhdCB0aGUgcmVwYWlyIHBhY2tldCBwcm90ZWN0cyAy
IHNvdXJjZSBwYWNrZXRzLiBJcyB0aGUgMTItYnl0ZSBSVFAgaGVhZGVyIG9mIHRoZSAybmQgcGFj
a2V0IHByb3RlY3RlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+KEV2ZW4gaWYgdGhlIGFuc3dlciBpcyB5ZXMsIGl0IHdvdWxkIGJlIGhlbHBm
dWwgdG8gc2F5ICZxdW90OyAuLi4gYW5kIHN1YnNlcXVlbnQgcGFja2V0cy4uLiZxdW90Oyk8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy4uLl08
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K
PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn
aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7C
pzUuMi4yLCBmaXJzdCBwYXJhZ3JhcGg6IElzIHRoZXJlIGEgcmVhc29uIHRvIGNpdGUgdGhlIG9i
c29sZXRlIFJGQyAyMzI2PzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpUaGlzIGFsc28g
Y2FtZSB1cCBhcyBwYXJ0IG9mIHRoZSBJLi1ELiBuaXRzLiAmbmJzcDtJIGRlY2lkZWQgdG8gbGVh
dmUgdGhlIDIzMjYgcmVmZXJlbmNlIGluIGJlY2F1c2UgSSBkaWQgbm90IHdhbnQgdG8gaW1wbHkg
dGhhdCBGTEVYIEZFQyBjYW5ub3QgYmUgdXNlZCBmb3IgUlRTUCAxLjAsIGFuZCBSVFNQIDIuMCBp
cyBub3QgYmFja3dhcmRzLWNvbXBhdGlibGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdnZXN0
IGFkZGluZyBhIGZldyB3b3JkcyB0byBleHBsYWluIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsuLi5dPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N
CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7CpzksIGxhc3QgcGFyYWdy
YXBoOiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgaW50ZW50IG9mIHRoZSBsYXN0IHNlbnRlbmNl
LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy
Pg0KT3JpZ2luYWxseSBzdWdnZXN0ZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly9tYWlsYXJjaGl2ZS5p
ZXRmLm9yZy9hcmNoL21zZy9wYXlsb2FkL0FJSHc1RFNBQkVKTGE2bFNPTHJ5TGRJMGVCayI+DQpo
dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3BheWxvYWQvQUlIdzVEU0FCRUpM
YTZsU09McnlMZEkwZUJrPC9hPi4gJm5ic3A7VGhlIGFwcGxpY2F0aW9uIHNvdXJjZSBkYXRhIG1h
eSBub3QgYmUgcGVyZmVjdGx5IG1hdGNoZWQgd2l0aCBGTEVYIEZFQyBzb3VyY2UgcGFydGl0aW9u
aW5nLiAmbmJzcDtJZiB0aGlzIGlzIHRoZSBjYXNlLCB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IGZv
ciB1bnByb3RlY3RlZCBzb3VyY2UgZGF0YSBpZiwgZm9yIGluc3RhbmNlLA0KIHRoZSBGTEVYIEZF
QyBpbXBsZW1lbnRhdGlvbiBkaXNjYXJkcyBkYXRhIHRoYXQgZG9lcyBub3QgZml0IHBlcmZlY3Rs
eSBpbnRvIGl0cyBzb3VyY2UgcHJvY2Vzc2luZyByZXF1aXJlbWVudHMuPG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+VGhhdCBleHBsYW5hdGlvbiBpcyBtb3JlIGNsZWFyIHRoYW4gdGhlIHRleHQgaW4gdGhl
IGRyYWZ0LiBJIHN1Z2dlc3QgaW5jbHVkaW5nIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Wy4uLl08bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_0341aad5c46241edbba503e834f0d098NASANEXM01Cnaqualcommco_--


From nobody Sat Dec 29 22:36:24 2018
Return-Path: <session-request@ietf.org>
X-Original-To: payload@ietf.org
Delivered-To: payload@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DC4130DE0; Sat, 29 Dec 2018 22:36:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool <session-request@ietf.org>
To: <session-request@ietf.org>
Cc: ron.even.tlv@gmail.com, ben@nostrum.com, payload-chairs@ietf.org, payload@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154615178228.11728.16756543412153643208.idtracker@ietfa.amsl.com>
Date: Sat, 29 Dec 2018 22:36:22 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/q-85htqvk3My4-H3ijrCxP8ZyI8>
Subject: [payload] payload - Not having a session at IETF 104
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Dec 2018 06:36:22 -0000

Roni Even, a chair of the payload working group, indicated that the payload working group does not plan to hold a session at IETF 104.

This message was generated and sent by the IETF Meeting Session Request Tool.


